【发布时间】：2018-02-12 11:43:26
【问题描述】：
我需要在我的数据库中实现一个自定义字段，以便每个用户都可以将他想要的任何字段添加到他的表单/实体中。
用户应该能够按任何自定义字段过滤或/和排序他的数据。
我想使用 MySQL，因为我的其余数据非常适合 SQL。因此，除非您有一个好主意，否则 SQL 将优于 NoSQL。
我们想了几个解决方案：
JSON 字段 - 非常适合动态模式。可以过滤和排序。问题是它比普通列慢。 动态索引可以解决这个问题，但是动态添加索引风险太大。
键值表 - 一个简单的解决方案，但非常慢。您无法正确索引它，而且查询很糟糕。
静态占位符列 - 创建 N 列并将每个字段映射到其占位符。 - 在性能方面一个很好的解决方案，但它使数据库不可读并且它的列有限。
任何想法如何改进任何解决方案或任何新解决方案的想法？
【问题讨论】：
-
Postgres 允许对 JSON 字段进行索引；但是，我们不应该提出软件推荐，所以这只是一个观察。
-
MySQL 也是如此，但您是否建议动态添加索引？据我了解，添加索引是一个非常繁重的操作，它会锁定表
-
@GuySegev - 这是你要回答的问题。不建立索引的负担是什么？您说用户应该能够按这些列进行排序或过滤，这样做并不是免费的，但是通过适当的索引会更便宜。您面临的问题是
SQL中的S是Structured，这适用于数据和语言。适用于某些行而不适用于其他行的动态列的想法是对unstructured或partially structured数据的描述。 -
另一种选择是
EAV表；Entity（您要添加数据的实际行的键），Attribute（您要添加的列/属性/字段/数据的“名称”到那一行），Value（你要添加的那个，嗯，值）。您无需添加列，而是添加行。但它们在用于过滤或排序时也很慢。我怀疑没有好的答案，只有least worst，这在很大程度上取决于您的数据、用例、应用程序等。 -
@GuySegev - 已经很清楚了。我的 cmets 不是对您的问题的批评，它们是关于 SQL 是否适合您的用例的（或不是） 的观察。你可以让它发挥作用，但你需要做出权衡。这些权衡与您可能拥有多少不同的列有关（即，1000 个用户每个有 5 个定制列，每个用户有 5 个定制列与 5 个管理员用户创建 5 个由 1000 个其他用户共享的列）。它们与每个用户拥有多少数据有关（即，如果用户只查询自己的 100 行数据，你真的需要索引吗？）。等等。