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

在我的遗留数据库（Postgres 9.1）中，我有几个包含各种文档的表（假设它们是“父”表）。 此外，还有一个表格，其中包含这些文档的各种参数：

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

一个文档可能有许多（parname、parvalue）对。 由于种类指向不同的表，因此不能将其用作外键

由于params仅用于打印文档，因此多年来一直运行良好。 现在，该表包含500万行，数据还需要用于其他目的。 因此，是时候更新这种模式了

基本上，一个文档的参数只插入一次，很少更新。它们将作为一个整体（对于一份文件）来阅读。不需要搜索特定的parname

我有三个想法：

变体A。 根据父表将表参数拆分为多个表，并使用docid作为外键

变体B。 将表参数拆分为变量A，并将（parname，parvalue）存储为hstore

变体C。 在每个父表中添加一个hstore字段，并忽略其他表

我没有使用hstore的经验。

---

每种变体的优缺点是什么？你会选择哪一个？hstore会不会让我感到奇怪？

如果您说需要获取文档中的字段，那么非规范化的hstore变体会更好，因为服务器将能够从磁盘上的单个位置获取整个文档，而不是使用多个位置来索引文档和字段。我在hstore中看到的唯一问题是有点非常规的语法。使用JSON可能更容易。PostgreSQL 9.4将提供对的出色支持。顺便说一句，hstore的作者使用二进制JSON

---

因此，一个计划可能是在9.3中使用

json

列，然后在9.4中将其转换为

jsonb

。

我投票支持第三个选项。桌子越少，睡眠越好

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;

---

对于简单的键/值对，我认为hstore比JSON更好。@从技术上讲，hstore没有二进制JSON好，有了JSON，客户端可能会从重用现有JSON库中受益。完成！在目前的开发环境中。这比我想象的要容易。谢谢大家，特别是klin的省时代码！