3

设想

假设用户是推销员。User 模型有许多 log_entries 用作销售数据的日常日志。用户还具有允许他们选择在其 log_entry 表单中可见的字段的首选项。所以，如果他们选择菠萝、香蕉和葡萄……这些就是表格中的字段。如果这些选择发生变化，数据不会丢失……只是在表单中不可见。现在，假设用户刚刚选择了蔓越莓销售帐户，但蔓越莓在他们的用户偏好表单中不是一个可选择的属性。他们需要能够创建那个“类别”。现在，菠萝季节结束了，所以他们登录到偏好设置并取消选中菠萝框并选中草莓框。现在，当他们在日志中输入数据时，将有一个草莓数据字段，但不是菠​​萝。

这种情况会带来一些挑战。一个是作为开发人员我不提前知道数据库列名称，因为用户可以动态创建新的“类别”（我可以要求用户联系我以根据需要添加更多，但是......）。而且，当用户创建一个新类别时...... log_entries 表不会有一个列来表示该新数据。

如何管理动态数据库列？postgres hstore 可以处理这个吗？

一行是基于日期的属于用户的条目。每列包含特定于属性的数据（例如......一列可以标题为“草莓”，它将包含当天售出的单位数量）

4

2 回答 2

4

通常的方法是：

  • EAV
  • hstore
  • XML
  • JSON

看：

整个“使列对其他用户可用”的事情只需要您保留一个“自定义键”表，每当用户定义以前未使用的键时您添加到该表中。

使用动态 DDL 添加列一开始听起来很合理，但是您可以存储多少列以及一行可以有多“宽”是有限制的。当您添加更多列时，扫描表的性能会变得更差，尽管大部分为空的“稀疏”列相对便宜。添加列需要独占锁，这在繁忙的系统上可能需要一些时间，但如果未将列定义为NOT NULL DEFAULT .... 一开始它会很好地工作，但我怀疑你以后会后悔这样做。

于 2013-06-09T23:52:35.460 回答
0

我最终没有使用 hstore，因为我认为这不是最好的解决方案。可能是……我只是不想花时间去摸索。我最终做的是改变我现有的 Preferences 模型并创建一些新模型。在 Preferences 模型中，我有一个字符串列，其中存储了引用模型的名称和模型项 id...然后在需要时将字符串常量化。

因此，如果用户想要在他们的偏好中包含水果，他们可以点击“添加更多水果”，如果他们想要的特定水果没有列出，他们可以添加它。当他们保存他们的偏好时，选定的水果 id 将被存储为一个整数，并且通过一个隐藏字段，引用的模型（在本例中为“水果”）将被存储为一个字符串。

然后，在用户偏好索引页面中，我有一个标题为水果的部分（如果用户有任何水果偏好）。该查询仅在 Preference 表中搜索与 current_user 匹配的用户、与“Fruit”匹配的 modelref，并使用未关联的存储 id 查找水果记录。

我可能没有很好地解释……但是，也许它会帮助其他想做类似事情的人。

于 2013-06-17T22:38:44.197 回答