我已经接管了具有超过30列的用户表的项目的开发。不好的一面在于列的更改和添加不断发生。有多少个数据库表列太多?
这是不对的。
我是否应该将额外的字段作为值移动到第二个表中,并创建存储这些列名的第三个表?
user
id
email
user_field
id
name
user_value
id
user_field_id
user_id
value
我已经接管了具有超过30列的用户表的项目的开发。不好的一面在于列的更改和添加不断发生。有多少个数据库表列太多?
这是不对的。
我是否应该将额外的字段作为值移动到第二个表中,并创建存储这些列名的第三个表?
user
id
email
user_field
id
name
user_value
id
user_field_id
user_id
value
这真的取决于你想做什么。
很难说有多少是太多。这真的很主观。我认为你应该问的问题不是“是否有太多的专栏?”,而是“这些专栏是否属于这里?”我的意思是,如果用户表中有列不一定是用户的属性,那么它们可能不属于。例如,如果你有一堆总结用户地址的列,那么你可能会将这些地址列表放入一个带有FK的地址表中。
如果可能的话,我会避免使用键/值表。它可能看起来像一个简单的方法来使事物可扩展,但从长远来看这真的只是一个痛苦。如果您发现模式的变化非常一致,您可能需要考虑设置某种变更控制,以仅对必要变更进行审核,或者迁移到另一种更好地支持无模式存储的技术,如使用MongoDB的NoSQL或CouchDB的。
我怀疑是否在此应用程序大部分的东西是必要的。但是,再次,我只是一个雇佣的程序员。 – 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
列过多是不真的是其中之一。
如果表格中的更改和添加并不是一件坏事,它意味着它们能准确反映业务需求的变化。
如果变化和附加是连续的,那么也许你需要坐下来做更好的定义需求。现在我不能说30列是否会出现问题,因为它取决于它们的宽度以及是否应该将其移到相关表格中。一旦如果你有像phone1,phone2,phone 3这样的字段,你就有一团乱麻,需要将其分解到user_phone的相关表中。或者,如果所有列都很宽(并且您的整个表格宽度比数据库存储数据的页面宽),而且有些不是查询常用的那些列,那么在相关的表中可能会更好一些,一个关系。我可能不会这样做,除非你有实际的性能问题。
然而,所有可能的选择,您所描述的EAV模型是从maintainabilty和性能的角度来看,最糟糕的一个或两个。对这个模型写出体面的查询是非常困难的。
一句话,NO! – HLGEM 2010-12-17 22:30:05