我应该在更新的数据模型中使用hstore吗？

在我的遗留数据库（Postgres 9.1）中，我有几个包含各种文档的表格（假设它们是'父'表）。此外，存在与这些文件的各种参数的表：我应该在更新的数据模型中使用hstore吗？

create table params (
    kind integer, 
    docid integer, 
    parname text, 
    parvalue text, 
    constraint params_pk primary key (kind, docid, parname));

可以有许多（parname，parvalue）双为一个文档。由于种类指向不同的表，它不能用作外键。

由于params只用于打印文件，它一直运行良好多年。现在这个表格包含5百万行，并且数据也需要用于其他目的。所以现在是更新这个模型的时候了。

基本上params为文档插入一次并且很少更新。它们将作为一个整体来阅读（用于文档）。没有必要搜索特定的parname。

我有三个想法：

变A. 分解表根据父表和使用文档ID为外键PARAMS到几个表。

变式B 拆分表PARAMS如在变体A和存储（parname，parvalue）作为hstore。

变体C. 在每个父表中添加一个hstore字段并忘记其他表。

我对hstore没有经验。每个变体的缺点和优点是什么？你会选哪一个？难道hstore会让我感到奇怪吗？

来源

2014-05-12 Adam Piotrowski

我投第三个选项。表格越少，睡眠越好。

Hstore是为一级参数列表而发明的。它稳定，快速和简单，完全符合您的需求。前段时间我有类似的任务。我写了一个聚合更容易转换。

create or replace function hstore_add(hstore, text, text) 
returns hstore language plpgsql 
as $$ 
begin 
    return case 
     when $1 isnull then hstore($2, $3) 
     else $1 || hstore($2, $3) end; 
end $$; 

create aggregate hstore_agg (text, text) (
    sfunc = hstore_add, 
    stype = hstore 
);

我认为这可能会节省您的时间。

select kind, docid, hstore_agg(parname, parvalue) 
from params 
group by 1, 2 
order by 1, 2;

来源

2014-05-13 10:16:20 klin

完成！现在在开发环境中。这比我想象的要容易得多。谢谢大家，特别是klin节省了代码！ –

如果你说你需要用文档获取字段，那么非规范化的hstore变体会更好，因为服务器将能够从磁盘上的单个位置获取整个文档，而不是使用多个位置来索引连接与领域的文件。我用hstore看到的唯一问题是一种非常规的语法。使用JSON可能会更容易。 PostgreSQL 9.4将对(indexed) binary JSON有极好的支持。使用二进制JSON是由hstore作者，BTW recommended。

因此，一个计划可能是使用9.3中的json列，然后在9.4中将其转换为jsonb。

来源

2014-05-12 18:57:30 ArtemGr

对于简单的键/值对我认为hstore是比JSON更好的选择。 –

@a_horse_with_no_name技术上hstore没有比二进制JSON更好，使用JSON的客户端可能会重新使用现有的JSON库中受益。 – ArtemGr

我应该在更新的数据模型中使用hstore吗？

回答

相关问题