我已经接管了一个项目的开发，该项目的用户表包含超过 30 列。糟糕的是，对列的更改和添加不断发生。
这是不对的。
我是否应该推动将额外的字段作为值移动到第二个表中并创建存储这些列名的第三个表？
user
id
email
user_field
id
name
user_value
id
user_field_id
user_id
value
【问题讨论】：
标签： mysql database-design entity-attribute-value
不要不要走关键/价值路线。 SQL 不是为处理它而设计的，它会使从数据库中获取实际数据成为一种自我折磨的练习。 （示例：索引不能很好地工作。当您必须加入只是为了获取要加入的数据时，加入会很有趣。它会继续。）
只要将数据标准化到合适的水平，您就不会拥有太多列。
编辑：需要明确的是，有些问题只能通过键/值路由来解决。 “列太多”不是其中之一。
【讨论】：
很难说有多少就是太多。这真的很主观。我认为你应该问的问题不是“列太多了吗？”，而是“这些列属于这里吗？”我的意思是，如果用户表中的列不一定是用户的属性，那么它们可能不属于。例如，如果您有一堆汇总用户地址的列，那么也许您将这些列拉到地址表中，并在用户中添加一个 FK。
如果可能，我会避免使用键/值表。这似乎是一种使事物可扩展的简单方法，但从长远来看，这确实是一种痛苦。如果您发现您的模式变化非常一致，您可能需要考虑实施某种更改控制来审核仅对那些必要的更改进行更改，或者转向另一种更好地支持无模式存储的技术，例如 NoSQL 和 MongoDB 或沙发数据库。
【讨论】：
这通常被称为 EAV，这是否适合您的数据库取决于很多因素：
http://en.wikipedia.org/wiki/Entity-attribute-value_model
http://karwin.blogspot.com/2009/05/eav-fail.html
http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back
太多的列并不是其中之一。
【讨论】：
如果表格的更改和添加准确地反映了您的业务需求的变化，那么它们并不是一件坏事。
【讨论】：
如果更改和添加是持续的，那么也许您需要坐下来更好地定义需求。现在我不能说 30 列是否太多，因为这取决于它们的宽度以及是否应该将它们移到相关表中。例如，如果您有诸如 phone1、phone2、phone 3 之类的字段，则您需要将其拆分为 user_phone 的相关表。或者，如果您的所有列都很宽（并且您的整体表宽度比数据库存储数据的页面更宽）并且有些不是您的查询经常需要的，那么它们在具有一对一的相关表中可能会更好一种关系。除非您遇到实际的性能问题，否则我可能不会这样做。
但是，在所有可能的选择中，您描述的 EAV 模型从可维护性和性能角度来看都是最差的。很难针对此模型编写体面的查询。
【讨论】：
这真的取决于你想要做什么。
【讨论】：