对于长期数据库可伸缩性而言，哪种方法更好:添加列或有键/值存储

Question

对于应用程序来说，目前的设置很少(5-10)，但将来会有更多的设置(最多100)，这将是更好的方法：

1. 每次引入新设置时都要向设置表中添加新列
2. 将设置表作为键/值存储

考虑到应用程序可能有数以百万计的实例(它们都运行在同一个db上，并使用相同的表进行设置)，DB可能会被分割。DB是关系型的，即MySQL或MySQL。

作为一个开发人员，我更喜欢第二个变体，这样我就可以在不更改DB模式和随意添加/删除设置的情况下扩展应用程序。据我所知，如果索引是聚集在应用程序实例上的，那么在单个表中拥有数百万条记录不应该是一个问题。我不知道有什么缺点吗？

第一个变体呢？有什么大好处吗？那么列的数量呢:表中的列是否有任何理论上的限制？如果我有一个有1000 (10,000,1000 )列的表，会发生什么呢？那会很慢吗？

Answer 1

选项2被称为"EAV“或实体-属性值。

• 非关系性
• 没有DB级别约束
• 需要扭曲来读取数据，除非有一个简单的列表。

但是，这取决于你所说的“设置”是什么意思。如果您有几个1000行不是对象，并且不需要约束，那么，是的，使用此模式。这就是Server对sys.configurations所做的事情

如果您试图拥有一个可以存储任何内容的“灵活模式”，那么干脆别。它会以眼泪结束。还请参见EAV在DBA.SE上的问题

请注意，“额外列”(选项1)允许您定义默认值和数据类型安全性，而“缺少行”(选项2)则要求将默认值存储在代码中，而且数据库中的所有内容都是字符串。

“视情况而定”

Answer 2

都不是。

相反，请执行以下操作：

A计划：

1. 决定哪些字段真正需要索引。不，您不需要所有字段的索引。
2. 在编程语言中，将其余的列和未来的列放在“散列”或“关联”数组中。法警把这个变成JSON。
3. 压缩JSON并将其存储到表的MEDIUMBLOB列中。
4. 添加新列(或有可选列，或取消推荐列等)

功能：

• 高效存储(压缩的blob比单独的列小得多)
• 不需要ALTER添加列。
• 搜索能力(记住，我让你把那些列排除在外)。

方案B: MariaDB 5.3+及其动态列：http://kb.askmonty.org/en/dynamic-columns