问数据库表设计:规范化与否

EN

Web (用于可定制的电子文章)应该通过web用户界面将用户生成的配置持久化到MySQL-数据库。

可用的选项是静态的，数量为10到20个不同的选项。

我想不出哪种解决方案有更多的优势。我想征求一些建议，因为这是数据库设计中常见的问题。

解决方案1

1表：

组合：

• id
• option1
• option2
• option3
• 等。

解决方案2

2个表和1个relationTable (见下文)

组合：

• id

选项：

• id
• 名字
• 价值

对于我来说，这将是一个带有连接表的单向OneToMany关联，还是与选项侧的一个foreignKey的单向ManyToOne关联并不重要。

问题是，如果需要新的选项，是否让一个表具有大约10到20列(每个选项对应于每个选项)，最终需要不时修改数据库模式。

或

对于关于的每一个配置条目都要有10到20个相关的选项条目。

配置表可以增长到每月大约2000个配置，=> 20000到每月40000个选项项。

查询配置及其相关选项的查询时间(如果options表的条目超过1.000.000 )可能很高，对吗(解决方案1)？查询具有大约20列的单个表的行(解决方案1)是一个更好的选择吗？也许这也是一个标准。任何解决方案都有缺点/利弊吗？