數據庫表設計：規范化與否

Question

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

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

我不知道哪種解決方案有更多優勢。 我正在征求一些建議，因為這是數據庫設計中的常見問題。

解決方案1

1張桌子：

配置：

• ID
• 選項1
• 選項2
• 2選項
• 等等

解決方案＃2

2個表和1個RelationTable（請參見下文）

配置：

• ID

選項：

• ID
• 名稱
• 值

對我而言，這將是與聯接表的單向OneToMany關聯，還是與選項側的與ForeignKey的單向ManyToOne關聯。

問題是，是否有一個包含約10至20列的表 ，每個選項每個都有，最終，如果需要新的選項，則需要不時更改數據庫架構

要么

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

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

如果選項表中的條目超過1.000.000，則查詢配置及其相關選項的查詢時間可能會很高，對嗎（解決方案1）？ 查詢約20列的單個表的行是否是更好的選擇（解決方案1）？ 也許這也是一個標准。 任何解決方案都有缺點/優點/缺點嗎？

Answer 1

我會選擇解決方案2。 我還將在options表的應用程序中添加緩存層，該表將為每個請求的configuration_id創建一個json對象（數組，列表或您的語言支持的任何內容），並且所有選項都已被查詢，處理並可以使用。