hstore 相对于 PostgreSQL 的键/值表的好处？答案

【问题标题】：Benefits of hstore over a key/value table with PostgreSQL?hstore 相对于 PostgreSQL 的键/值表的好处？
【发布时间】：2019-10-28 21:23:57
【问题描述】：

在我们的一个应用程序中，我们需要有一些我们会定期更新的键/值对。

我们最初考虑的表格是这样的：

CREATE TABLE "KeyValue" (
    "Key"   TEXT UNIQUE,
    "Value" TEXT,
    PRIMARY KEY("Key")
);

这完全符合我们的需求。

但是在挖掘是否已经内置某些东西时，我发现了 hstore module，但我无法真正了解使用那个 hstore 代替我的老式桌子的好处。

此外，语法对我来说似乎有点奇怪，在查看示例时，我找不到一个简单的示例来解释如何创建一对（例如"StartDate": "2012/12/25"），请阅读它（例如"2012/12/25" )，然后更新它 ("StartDate": "2012/12/26")，并可能删除它。

有没有人可以解释使用hstore 方法相对于我刚刚在上面制作的传统表格的好处？

【问题讨论】：

如果要将动态键/值对附加到现有表，通常使用 hstore（或现代 Postgres 版本中的 jsonb）。如果您只有键/值对而与现有表没有关系，那么您的表可能更高效，因为您可以更新单个键而无需重写所有其他键
不相关，但是：avoid 那些可怕的带引号的标识符。

标签： postgresql hstore

【解决方案1】：

我以前通过 Hibernate/Java 使用过hstore。我这样做是因为每行映射的总大小很小，但是像你用行特定键值对描述它的表会有很多行。我可能弄错了，但我记得 hstore 可能最初是为小地图设计的，但在文档页面中不再提及。此外，我对 hstore 列的要求仅与行相关，为所有列值完成的任何“报告”仅用于开发。

不过，查看您的示例表，您似乎正在寻找 全局唯一 键，我认为 hstore 在每行有一个 hstore 时最有用。我认为您不应该使用 hstore 和一些索引来解决“全局唯一键”，尽管您可以这样做。

请注意，您链接到的 postgresql 版本不受支持，这是最新的 hstore documentation。它确实有实例化示例（SELECT 'a=>1,a=>2'::hstore; 或 hstore('c', '3')），the examples section 包含您询问的其余示例。

自从我上次在 postgresql 上开发或维护任何东西已经有一段时间了，但我记得，json 支持很快就出现了，看起来很有趣。如果您在 Value 列中存储了除不透明字符串之外的任何内容，则可能值得花时间查看 json 支持，因为它可以支持 the json datatypes with some limitations。

【讨论】：

感谢a horse with no name 将该文档链接修复为当前。显然，在接受对答案的编辑时，SO 没有乐观的并发检查:)