我有几个实体“类型”,让我们称它们为A,B和C,它们共享一定数量的属性(大约10-15).我创建了一个名为ENTITIES的表,以及每个常用属性的列.
A,B,C也有一些(大多数)唯一属性(所有布尔值,可以是10到30左右).
我不确定在对表建模时遵循的最佳方法是什么：
>在ENTITIES表中为每个属性创建一个列,这意味着不共享该属性的实体类型将只具有空值.
>对每个实体类型的唯一属性使用单独的表,这有点难以管理.
>使用hstore列,每个实体都将在此列中存储其唯一标志.
> ???
我倾向于使用3,但我想知道是否有更好的解决方案.
从数据库设计的角度来看,最干净的风格可能是继承,就像@yieldsfalsehood在他的评论中所建议的那样.这是一个包含更多信息,代码和链接的示例：
Select (retrieve) all records from multiple schemas using Postgres
然而,Postgres中当前的继承实现有许多局限性.其中,您无法为所有继承表定义公共外键约束.仔细阅读the last chapter about caveats.
(3)hstore,json(第9.2页)/ jsonb(第9.4页)
很多不同或不断变化的属性集的一个很好的替代方案,特别是因为你甚至可以在列中的属性上有函数索引：
> unique index or constraint on hstore key
> Index for finding an element in a JSON array
> jsonb indexing in Postgres 9.4
EAV类型的存储有其自身的优点和缺点. This question on dba.SE提供了非常好的概述.
(1)一个包含大量列的表
这是一种简单,有种蛮力的选择.从您的描述来看,您最终会得到大约100列,其中大多数是布尔值,大多数时候大多数都是NULL.添加列entity_id以标记类型.每种类型实施约束对于许多列来说有点尴尬.我不会为太多可能不需要的约束而烦恼.
The maximum number of columns allowed is 1600.由于大多数列为NULL,因此适用此上限.只要你把它保持在100到200列,我就不用担心了.在Postgres(basically 1 bit per column,but it’s more complex than that.)中,NULL存储非常便宜.这只是每行10-20个字节.与人们可能假设的相反(！),在磁盘上最可能比hstore解决方案小得多.
虽然这样的桌子看起来对人眼来说是怪异的,但Postgres处理它并不是问题. RDBMSes专注于蛮力.您可以在基表的顶部定义一组视图(对于每种类型的实体),只包含感兴趣的列,并与适用的列一起使用.这就像继承的逆向方法.但是这样你就可以拥有通用索引和外键等等.我可能会这样做.
所有这一切,决定仍然是你的.这一切都取决于您的要求的细节.
