数据库表设计：是否规范化

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对象（数组，列表或任何您的语言支持的），并且已经查询，处理并准备使用所有选项。