高性能自定义用户字段

Question

寻找自定义用户字段的示例/教程，而不是通过EAV

由于性能等各种原因，EAV将会出现问题

• 有许多基础实体/表，每个实体/表有超过100000条记录
• 可能会有十几个属性
• 记录将显示在平面ui网格中，包括 自定义字段，因此将它们展平会在保持性能的同时成为一个问题

寻找通过DDL启用此功能，其中所有自定义字段都将进入匹配表，例如

<tablename>_custom_<userid>

并且所有用户属性都将映射到一列，并将其所有元数据存储在元数据表中

检索将更简单，而查询将只是

select  * 
from <tablename> A, tableName_custom_userid B 
where B.KeyField = A.KeyField --( perhaps using outer join, haven't gone that far yet )

想知道我是否需要了解一些陷阱？

当然，任何样本/指针都将有助于启动工作

特别要感谢有关将DDL用于Sql Server Compact 4的任何建议

Answer 1

我见过的一种技术是使用一种“硬编码” EAV模式。 不要挂断电话！ 它可以很好地处理您正在谈论的数据集大小，并且实际上并未使用EAV-只是EAV风格的。

想法是要有一组表在其中存储这些自定义属性，并在其上添加一些触发器（如下所述）。 定制属性表集存储有关该属性的元数据（它随带的表，数据类型，约束等）。 您可以对此非常满意，但是我没有这个需要。

元表上的触发器在那里可以重新生成视图，这些视图将基础和扩展汇总到数据库内的一流对象中。 因此，您有一个包含两者的雇员视图，而不是表人员+雇员扩展表。 当您将新值放入自定义属性表中时，触发器将重新滚动视图并包含新内容。 如果您想发疯，也可以使触发器也重新编写存储过程。 根据中间层代码的结构，您仍然会被迫重新编码一些代码，但是无论如何，如果您要应用读取数据的规则，情况都是如此。

在测试中，我发现对于您正在谈论的相对较少的记录数，性能会稍慢一些，但遵循大致相同的降级模式（记录数的2倍，慢的速度约2倍）。

-编辑-

我如何看待它，您有一个表代表您的一流对象，所以一行代表“人员”，一行代表“员工”，依此类推。我们将其称为FCO。 然后，您有一个辅助表，用于存储代表FCO的表。 我们将其称为Srcs。对于人员，将有一行，即人员表。 对于Employee，将有两行，人员表和Employee扩展。 第三个表称为Attribs，用于存储构成FCO的表中的列。 为简单起见，我们将说Employee具有ID，名称和地址，而Employee具有雇用日期和部门，显然，PersonID指的是Person表。 因此，FCO表（人员和员工）中有2行，Src表中有3行，Atribs中有8行。

该视图将其称为vw_Employee，从两个表中选择PersonID，姓名，地址，雇用日期，部门。 它由我们称为OnMetadataChange的SQL存储过程构建。

该SP被触发（通过触发器或批处理），其目的是生成CREATE VIEW语句。 它将遍历每个First Class Object，收集从哪些表构成视图的字段，并基于该字段发出CREATE语句。 因此OnMetadataChange为每个视图生成一个DROP和CREATE，它生成一个动态SQL语句，该语句在FCO表中的每个条目都执行一次。 最好使用触发器执行此操作，但这不是必需的。 希望您的FCO定义不会经常更改，并且当它们更改时，可能还会发布代码。 您可以在那时运行OnMetadataChange SP。

最终结果是一个2层数据库。 视图构成First Class Object层，这对于应用程序是有意义的。 该应用程序仅使用视图。 这些表构成了“物理”层，应用程序不需要关心这些层。 元表本质上是您在FCO层和物理层之间的映射。 设置它需要一些时间，但是它非常有效，并且为您提供了EAV的许多好处，同时还为您提供了3nf表的具体好处（可索引性等）。

如果您愿意，我可以在其中添加一些示例SQL。

Answer 2

您遇到的部分问题是，您试图将无模式的数据存储在SQL数据库中，这不是它的优势。 可以通过三种方法使您的生活更加轻松：

1）有一列存储序列化的自定义字段，使用最方便的任何格式。 例如，此列可以存储xml。 好处是可以使用SQL Server Compact并撤回记录是微不足道的。 缺点是您必须始终拉/推整个xml blob来进行更新，并且很难无法对任何自定义字段进行查询。

2）升级到SQL Server Express，并使用XML列。 这与第一个建议几乎相同，除了SQL Server的任何服务器就绪版本均具有对XML数据的本机支持。 这些列可以添加索引，并且数据中的字段可以在查询中使用。

3）使用无模式数据库，例如MongoDB或CouchDB。 这些数据库都是关于存储无模式数据的，因此您的自定义字段与任何其他字段都没有什么不同。 这样，您可以索引和查询自定义字段。 好处是定制数据非常易于使用，缺点是您必须花一些时间重新考虑如何存储数据以使其适合模型。

如果您不需要基于自定义字段进行查询，或者可以在业务逻辑中查询自定义字段，则第一个选项可以为您服务。 在任何其他情况下，我都会偏向功能比紧凑的功能更多的东西。 如果成本是决定性因素，则SQL Server Express和MongoDB都是免费的。