两个表解决方案是在 Postgres 9.5 中实现标记的高性能且可扩展的解决方案吗？答案

【问题标题】：Is a two table solution a performant and scalable solution to implement tagging in Postgres 9.5?两个表解决方案是在 Postgres 9.5 中实现标记的高性能且可扩展的解决方案吗？
【发布时间】：2016-06-20 17:03:08
【问题描述】：

背景

我在一家房地产技术公司工作。一个即将到来的项目涉及构建功能以允许用户将标签/标签（复数）附加到 MLS 列表（房地产）。第二个要求是允许用户通过一个或多个标签进行搜索。我们不会处理跟踪计数或构建词云或类似的事情。

研究解决方案

我找到了this SO Q&A，并认为该解决方案非常简单，并尝试在下面调整一些想法。另外，我知道 JSONB 支持在 9.5 中要好得多，并且可能是一种可能性。如果您对此有任何见解，我也很乐意在回答中听到您的想法。

尝试的解决方案

表格：标签

列：ID、OwnerID、TagName、CreatedDate

表格：TaggedItems

列：ID、TagID（以上引用）、PropertyID、CreatedDate（可能是一些非规范化数据，以帮助呈现搜索结果；属性名称、原始列表等）

插入新标签应该很简单。搜索标签也应该很简单，因为用户将从可搜索的下拉列表中选择一个或多个标签，从而使我可以访问实际的 TagID，我可以使用它来查询TaggedItems 表。在显示列表的完整配置文件视图时，我可以使用它的 PropertyID 和 UserID 来查询我的表是否存在一个或多个要在视图中显示的标签。

编辑：可能值得注意的是，我们不会保留整个属性数据库，而是通过 API 合作伙伴访问它们；因此是两个表解决方案而不是 3。

【问题讨论】：

标签： sql database postgresql database-schema

【解决方案1】：

如果你想进行第 N 次标准化，你实际上会使用 3 个表。

1 物业/房源 2 个标签 3 两者之间的交叉引用

第 3 个表在其他 2 个表之间创建多对多关系。

在这种情况下，只有第三张表会同时携带 tagid 和属性。

是否也可以使用 2 个表，这取决于您作为一个小字符串的使用量有多大，不会使您的数据库过度膨胀。

我会说，当您需要进行查找和更多操作时，最好将标签分隔到单独的表中。否则，您必须有一个分隔列表，如果用户将分隔符注入到他们的标签值中会发生什么？另外，您打算如何搜索分隔列表？您将不断将其扩展为表格或使用正则表达式，并且正则表达式可能会给您带来误报，因为“some”将匹配“some”和“something”，具体取决于您编写代码的方式......

【讨论】：