数据库设计 - 一个表中有许多字段,许多表中有一个字段或抽象表?
问题描述:
我必须设计一个模式来存储具有许多属性但很少共同的对象。数据库设计 - 一个表中有许多字段,许多表中有一个字段或抽象表?
我在这里找到了一些解决方案,但我仍然不相信要做的最好的事情。我看到这样做的四种方式:
许多领域- 一个表:这可能会导致许多
NULL
值,以及一个很难的时候,需要来添加一些属性或modifiy一些数据类型。 - 为每个属性创建一个新表:这使得添加和更新列变得容易,并且保留了搜索功能,尽管每个
SELECT
都会导致很多JOIN
。 - 创建一个表中的每个物业类型,例如:标签,数量,间隔等我不知道在这种情况下,如果我需要区分浮动,小数,整数等
- 创建抽象表(我在这里读取它称为Observation Pattern),它存储属性名称和数据类型。
我应该遵循哪些标准,我应该回答哪些问题以在这些解决方案之间进行选择?
感谢
答
这取决于你需要怎样处理属性。如果这些属性只是间接利益,那么4是一个非常灵活和紧凑的解决方案。间接利益是什么意思?如果您需要检索并显示属性中的信息,这是间接的。如果您需要使用属性进行计算或详细操作,那么这更直接。换句话说,如果您可能在属性上使用的唯一方法是“.ToString()”,那么您可以使用4.该模式具有显着的优势,允许您在不更改数据库的情况下添加新的属性类型模式,因为这些只是插入到属性类型表中的新行。
如果另一方面,不同的属性类型需要依赖于它们的数据类型进行操作,那么将不同类型的属性存储在一个字段中将是一种痛苦。如果是这种情况,你可以做3.,但这也是一个问题,因为它需要你知道要去哪个表来获取特定类型的值。这不是一个不可逾越的问题,但它也不优雅。
而不是3你可以尝试一种混合aproach,其中你的单个属性表有多个列,每个数据类型一个,最好是另一列 - 可能是一个计算列 - 充当“ToString”。通过这种方式,您的间接使用可以转到简单且可预测的位置,只有您的更多参与应用程序需要担心要为特定属性类型选择哪个列。
答
我要说的是,这取决于你所使用的ORM技术和你的对象的序列化能力。
一般来说,我更喜欢抽象和灵活性。
您是否考虑过使用[文档数据库](http://en.wikipedia.org/wiki/Document-oriented_database)而不是关系数据库? – Oded 2011-04-23 18:58:06
“这取决于”。除非有*证明需要*去其他路由之一(将* volatile *用户定义的字典映射到表列上,否则我会留在#1中作为“开发人员控制的模式”),通常是#1的输出,但考虑稀疏列等)。应该注意“亲吻”和“只做谨慎的事”。 – 2011-04-23 19:02:16