postgresql – 针对多列的hstore用例

概述我在决定使用哪种方法时遇到了一些麻烦. 我有几个实体“类型”,让我们称它们为A,B和C,它们共享一定数量的属性(大约10-15).我创建了一个名为ENTITIES的表,以及每个常用属性的列. A,B,C也有一些(大多数)唯一属性(所有布尔值,可以是10到30左右). 我不确定在对表建模时遵循的最佳方法是什么： >在ENTITIES表中为每个属性创建一个列,这意味着不共享该属性的实体类型将只具有空值 我在决定使用哪种方法时遇到了一些麻烦.

我有几个实体“类型”,让我们称它们为A,B和C,它们共享一定数量的属性(大约10-15).我创建了一个名为ENTITIES的表,以及每个常用属性的列.

A,B,C也有一些(大多数)唯一属性(所有布尔值,可以是10到30左右).
我不确定在对表建模时遵循的最佳方法是什么：

>在ENTITIES表中为每个属性创建一个列,这意味着不共享该属性的实体类型将只具有空值.
>对每个实体类型的唯一属性使用单独的表,这有点难以管理.
>使用hstore列,每个实体都将在此列中存储其唯一标志.
> ???

我倾向于使用3,但我想知道是否有更好的解决方案.

(4) Inheritance

从数据库设计的角度来看,最干净的风格可能是继承,就像@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专注于蛮力.您可以在基表的顶部定义一组视图(对于每种类型的实体),只包含感兴趣的列,并与适用的列一起使用.这就像继承的逆向方法.但是这样你就可以拥有通用索引和外键等等.我可能会这样做.

所有这一切,决定仍然是你的.这一切都取决于您的要求的细节.

总结

以上是内存溢出为你收集整理的postgresql – 针对多列的hstore用例全部内容，希望文章能够帮你解决postgresql – 针对多列的hstore用例所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。