我见过不少软件，尤其是 CRM 工具，它们允许用户定义自己的字段来捕获用户数据。它们还允许用户定义该字段的数据类型（文本、数字、日期等）。我想知道他们如何在应用程序和数据库层处理这件事。我可以想到以下方法：
我看到这种方法的问题是您无法查询数据库。所有数据的排序或过滤都必须在应用层完成。因此，我想知道必须有更好的解决方案。
【问题讨论】：
标签： java design-patterns database-design
使用一些 PIM 系统，正是因为这个原因，我才得以深入了解。
它们允许在运行时动态更改模型，而您实际上不需要重新启动。
我所看到的实现方式是您在实际数据库表之上有一个元模型。
因此，用户可以添加到应用程序中的字段并不是表中真正的新字段或完全是新表，而是已经添加到现有模型中。
所以，我看到这个实现的方式是你有表格
在您的上下文中，项目类型可以是潜在客户、机会、客户、提案、合同等。
项目将是每次的单独记录。
属性类型将描述属性的基本数据类型（归结为数据库类型）。
属性是项目类型的项目的属性类型的实际值。
作为上下文：在传统世界中，每个项目类型都有一个表格
其中任何一个的每个属性都是一个定义的列，每一行都是一个条目。
所以想象一下，您需要向客户添加我不知道的 twitter 句柄。
你是做什么的？
您扩展您的客户表以包括一个额外的推特句柄行。这意味着您需要更改所有使用客户的代码，因为您有一个附加属性。
在元模型世界中，对于相同的示例（向客户添加 twitter 句柄），您需要这样做：
您定义了一个属性类型文本的新属性“twitter 句柄”（可能只是作为 varchar(200) 处理 - 这取决于您想在此处进行多深）。
这被添加到项目类型表中，作为将项目类型“客户”链接到属性“推特句柄”（基本上只有两个 ID）的单独行。
在该模型中，有一个定义允许您为客户拥有 twitter 句柄。
现在在“items”表中，您为每个客户条目添加一个新行，为每个现有客户 ID 和“twitter handle”的属性 ID 添加另一个 ID 和一个包含实际值的值字段.
我已经对此做了很多简化，以此作为示例。您还需要考虑修订、关系、复杂数据类型等等。
底线是：您很少需要真正更改表，而是使用现有表中的附加行来定义附加数据字段。
这样做的缺点之一是您不能真正使用缓存机制，因为您在包含数百万条目的狭窄表上拥有非常通用的 SQL 语句。
一家公司使用混合模型，出于性能原因，他们将某些属性保留在实际表中。优点：非常快。缺点：扩展这意味着重新启动应用程序和扩展应用程序逻辑。 当然，这并不难（需要编辑 xml 文件），但您需要规划此类扩展。
另一家公司使用 ElasticSearch 包含某些字段以进行快速搜索访问，其中索引会随着记录的每次更改而更新，并且只会返回数据库进行更复杂的查询。非常快。缺点：DB 和 ElasticSearch 可能会不同步。再说一次，这不是什么大问题要修复，但您需要应用程序停机时间。
我希望这能回答你的问题？
【讨论】：