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 回答