有多少个数据库表列太多？

我已经接管了具有超过30列的用户表的项目的开发。不好的一面在于列的更改和添加不断发生。有多少个数据库表列太多？

这是不对的。

我是否应该将额外的字段作为值移动到第二个表中，并创建存储这些列名的第三个表？

user 
    id 
    email 

user_field 
    id 
    name 

user_value 
    id 
    user_field_id 
    user_id 
    value

来源

2010-12-16 Xeoncross

一句话，NO！ – HLGEM 2010-12-17 22:30:05

做不是去键/值路线。 SQL不是为了处理它而设计的，它会让你从数据库中获取实际的数据来进行自我折磨。（例子：索引不能很好地工作，当你不得不加入以获取你加入的数据时，联接很有意思）它继续。

只要数据被归一化为一个体面级别你没有太多的列。

编辑：要清楚，有一些问题只能通过键/值路线来解决。 “太多列”不是其中之一。

来源

2010-12-16 19:38:05 Donnie

+1。将字段名称放在一个单独的表格中会使您的工作变得非常困难。 – matt 2010-12-16 19:40:25

是的，我想努力使所有的值的请求将是一个痛苦，如果它们移动到其他表行。 – Xeoncross 2010-12-16 20:03:07

这真的取决于你想做什么。

来源

2010-12-16 19:37:34

很难说有多少是太多。这真的很主观。我认为你应该问的问题不是“是否有太多的专栏？”，而是“这些专栏是否属于这里？”我的意思是，如果用户表中有列不一定是用户的属性，那么它们可能不属于。例如，如果你有一堆总结用户地址的列，那么你可能会将这些地址列表放入一个带有FK的地址表中。

如果可能的话，我会避免使用键/值表。它可能看起来像一个简单的方法来使事物可扩展，但从长远来看这真的只是一个痛苦。如果您发现模式的变化非常一致，您可能需要考虑设置某种变更控制，以仅对必要变更进行审核，或者迁移到另一种更好地支持无模式存储的技术，如使用MongoDB的NoSQL或CouchDB的。

来源

2010-12-16 19:38:12 dustyburwell

我怀疑是否在此应用程序大部分的东西是必要的。但是，再次，我只是一个雇佣的程序员。 – Xeoncross 2010-12-16 20:03:56

这通常被称为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

列过多是不真的是其中之一。

来源

2010-12-16 19:38:37

如果表格中的更改和添加并不是一件坏事，它意味着它们能准确反映业务需求的变化。

来源

2010-12-17 00:54:52 sqlvogel

如果变化和附加是连续的，那么也许你需要坐下来做更好的定义需求。现在我不能说30列是否会出现问题，因为它取决于它们的宽度以及是否应该将其移到相关表格中。一旦如果你有像phone1，phone2，phone 3这样的字段，你就有一团乱麻，需要将其分解到user_phone的相关表中。或者，如果所有列都很宽（并且您的整个表格宽度比数据库存储数据的页面宽），而且有些不是查询常用的那些列，那么在相关的表中可能会更好一些，一个关系。我可能不会这样做，除非你有实际的性能问题。

然而，所有可能的选择，您所描述的EAV模型是从maintainabilty和性能的角度来看，最糟糕的一个或两个。对这个模型写出体面的查询是非常困难的。

来源

2010-12-17 22:36:17 HLGEM

有多少个数据库表列太多？

回答

相关问题