數據庫表設計：是否規範化

Question

Web配置器（用於可定製的電子文章）應通過Web用戶界面將用戶生成的配置保存到MySQL數據庫。

可用的選項是靜態的，數量爲10到20個不同的選項。

我找不出哪個解決方案更具優勢。我正在尋求一些建議，因爲這是數據庫設計中的一個常見問題。

溶液＃1

1表：

配置：

選項2

選項3

• ID
• 選項1等

溶液＃2

2表和1 relationTable（見下文）

配置：

• ID

選項：

• ID
• 名
• 值

不要緊，對我來說，是否將與連接表或對期權的一側的外鍵單向多對一關聯一個unidirectinal一對多關聯。

的問題是，是否有一個表約10至20列，每次每個選項，最終需要從時間更改數據庫模式時，如果有新的選項是必需的

OR

有大約10至20相關的選項條目每個配置項。

配置表可能增長到每月約2000個配置=>每月20000到40000個選項條目。

查詢配置及其關聯選項的查詢時間，如果選項表超過1.000.000個條目可能很高，右（解決方案＃1）？查詢具有大約20列的單個表的行是否更好？（解決方案1）？ 也許這也是一個標準。 任何解決方案是否存在缺點/優缺點？

Answer 1

我會用解決方案＃2去。我還將爲應用程序添加緩存層options表，該表將爲每個configuration_id請求創建一個json對象（數組，列表或任何您的語言支持的），並且已經查詢，處理並準備使用所有選項。