Scenario
假设用户是一名推销员。用户模型有许多 log_entries 用作销售数据的每日日志。用户还具有允许他们选择在其 log_entry 表单中可见的字段的首选项。因此，如果他们选择菠萝、香蕉和葡萄……这些就是表单中的字段。如果这些选择发生变化，数据不会丢失......只是在表单中不可见。
现在，假设用户刚刚选择了蔓越莓销售帐户，但蔓越莓并不是其用户偏好表单中的可选属性。他们需要能够创建该“类别”。现在，菠萝季节已经结束，因此他们登录到偏好设置并取消选中菠萝框并选中草莓框。现在，当他们在日志中输入数据时，将会有一个草莓的数据字段，但不会有菠萝。菠萝数据并没有消失……只是没有显示出来。
这种情况带来了一些挑战。其中之一是，作为一名开发人员，我不提前知道数据库列名称，因为用户可以动态创建新的“类别”（我可以要求用户与我联系以根据需要添加更多内容，但是......）。而且，当用户创建新类别时……log_entries 表不会有一列来表示该新数据。
如何管理动态数据库列？ postgres hstore 可以处理这个问题吗？
一行是基于日期属于用户的条目。每列保存特定于某个属性的数据（例如......一列可以标题为“草莓”，它将保存当天售出的单位数）
通常的方法是：
See:
- 数据库设计 - 我应该使用 30 列还是 1 列且所有数据都采用 JSON/XML 形式？
- https://dba.stackexchange.com/q/27057/7788
整个“使列可供其他用户使用”只需要您保留一个“自定义键”表，每当用户定义以前未使用的键时就将其添加到该表中。
使用动态 DDL 添加列一开始听起来很合理，但是可以存储的列数以及行的“宽度”是有限的。随着添加更多列，扫描表的性能会变得更差，尽管大多数为空的“稀疏”列相对便宜。添加列需要独占锁，这在繁忙的系统上可能需要一些时间，但如果未将其定义为，则添加列本身会非常快NOT NULL DEFAULT ...。一开始它会很有效，但我怀疑你以后会后悔这样做的。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
