我的web應用程序允許用戶定義從1到30封電子郵件（可能是其他任何東西）。 以下哪個選項最好？MySQL列組織
1）...用的隔板，這樣存儲該數據只有一列內：
結構：
emails VARCHAR(1829)
2）...或保存使用不同的欄目，像這樣的數據：
結構：
email1 VARCHAR(60) email2 VARCHAR(60) email3 VARCHAR(60) [...] email30 VARCHAR(60)
預先感謝您。
取決於你將如何使用數據以及固定數量是多少。如果使用WHERE子句快速查詢第三個地址或過濾器是一個優勢：使用不同的字段;否則它可能不值得創建列的努力。
使數據庫中的數據仍具有多個用戶同時訪問的優點。
第二個是更好的選擇，沒有問題。如果你做第一個（逗號分隔），那麼它會否定使用RDBMS的優點（在這種情況下，你不能對你的電子郵件進行有效的查詢，因此它可能是一個平面文件）。
2號比1號好。
但是，你應該在哪裏你有一個foreign key一個單獨的電子郵件表格您的用戶記錄考慮讓normalized結構的另一種選擇。如果您想通過電子郵件搜索以找到用戶並將constraint確保沒有註冊重複的電子郵件 - 如果您想這樣做，這將允許您定義index。
兩者都不是很好的選擇。
選項1是一個不好的主意，因爲它使得通過電子郵件向用戶查找複雜而低效的任務。您需要在用戶記錄的電子郵件字段中執行全文搜索才能找到一封電子郵件。
選項2實際上是一個WORSE的想法，海事組織，因爲它使任何周圍的代碼寫一個巨大的痛苦。再次假設您需要查找所有具有值X的用戶。現在需要枚舉30列並檢查每列，以確定該值是否存在。痛苦！以這種方式
存儲數據 - 1或更多的數據的一些元件的 - 是在數據庫設計很常見的，並且如先前亞當提到，最好是在大多數情況下，通過使用歸一化的數據結構解決。
正確的表結構，寫在MySQL，因爲這被標記爲這樣的，可能是這樣的：
用戶表：
CREATE TABLE user (
user_id int auto_increment,
...
PRIMARY KEY (user_id)
);
電子郵件表：
CREATE TABLE user_email (
user_id int,
email char(60) not null default '',
FOREIGN KEY (user_id) REFERENCES user (user_id) ON DELETE CASCADE
);
的FOREIGN KEY聲明是可選的 - 設計將在沒有它的情況下工作，但是，該行會導致數據庫強制關係。例如，如果您嘗試將記錄插入user_email且user_id爲10，則必須有對應的user記錄，其中user_id爲10，否則查詢將失敗。 ON DELETE CASCADE告訴數據庫，如果您從user表中刪除記錄，則與其關聯的所有user_email記錄也將被刪除（您可能希望或不希望發生此行爲）。
這種設計當然也意味着當您檢索用戶記錄時需要執行聯接。像這樣的查詢：
SELECT user.user_id, user_email.email FROM user LEFT JOIN user_email ON user.user_id = user_email.user_id WHERE <your where clause>;
將返回一行存儲在系統中的每個user_email地址。如果您有5個用戶，每個用戶有5個電子郵件地址，則上述查詢將返回25行。
根據您的應用程序，您可能想要爲每個用戶獲得一行，但仍可以訪問所有電子郵件。在這種情況下，你可以嘗試聚合函數一樣GROUP_CONCAT將每個用戶返回單行，請用逗號分隔的屬於該用戶的郵件列表：
SELECT user.user_id, GROUP_CONCAT(user_email.email) AS user_emails FROM user LEFT JOIN user_email ON user.user_id = user_email.user_id WHERE <your where clause> GROUP BY user.user_id;
同樣，根據您的應用程序，你可能希望向電子郵件列添加索引。
最後，在某些情況下，您不希望進行標準化的數據庫設計，並且帶有分隔文本的單列設計可能更合適，但這些情況很少。對於大多數正常的應用，這種標準化設計是一種方法，可以幫助它更好地執行和擴展。
我會強烈反對，第二個是一個很好的選擇，甚至可能不是比第一個更好的選擇。從應用程序設計的角度來看，甚至從性能的角度來看，爲一個值檢查30個不同的列是一場噩夢。 – futureal