数据库设计 - 一个包含许多字段的表,包含一个字段的许多表或抽象表?

时间:2011-04-23 18:52:07

标签: design-patterns database-design orm custom-fields

我必须设计一个模式来存储具有许多属性但很少有共同点的对象。

我在这里找到了一些解决方案,但我仍然不相信最好的办法。我看到了四种方法:

  1. 一个包含许多字段的表:这可能会导致许多NULL值,并且需要添加一些属性或修改某些数据类型时很难。
  2. 为每个属性创建一个新表格:这样可以轻松添加和更新列,并保留搜索功能,但每个SELECT会产生大量JOIN
  3. 为属性的每个类型创建一个表,例如:标签,数量,间隔等。在这种情况下,我不确定是否需要区分浮点数,小数,整数等。
  4. 创建抽象表(我在这里读它称为观察模式),它存储属性名称和数据类型。
  5. 我应该遵循哪些标准,我应该回答哪些问题来选择这些解决方案?

    由于

2 个答案:

答案 0 :(得分:1)

我想说这取决于您使用的ORM技术以及对象的序列化功能。

一般来说,我更喜欢抽象和灵活性。

答案 1 :(得分:0)

这取决于您需要对属性执行的操作。如果这些属性只是间接利益,那么4是一个非常灵活和紧凑的解决方案。间接利益是什么意思?如果需要检索并显示属性中的信息,则这是间接的。如果您需要使用属性进行计算或详细操作,那么这更直接。换句话说,如果您可能在属性上使用的唯一方法是“.ToString()”,那么您就可以使用4.此模式具有允许您在不更改数据库的情况下添加新属性类型的显着优势schema,因为这些只是在您的属性类型表中插入新行。

另一方面,如果需要以依赖于其数据类型的方式操纵不同的属性类型,那么将不同类型的属性存储在一个字段中将是一件痛苦的事。如果是这种情况你可以做3.,但这也是一个问题,因为它需要你知道去哪个表来获得特定类型的值。这不是一个不可逾越的问题,但也不优雅。

而不是3.您可以尝试一种混合方法,其中您的单个属性表有多个列,每个数据类型一个,最好是另一个列 - 可能是计算列 - 充当“ToString”。这样,您的间接使用可以转到简单,可预测的位置,只有您更多涉及的应用程序需要担心特定属性类型的列。

相关问题