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 )

想知道我需要注意的路上是否有任何问题？

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

特别感谢任何关于在Sql Server compact 4中使用DDL的建议

Answer 1

我所看到的一种技术是使用一种“硬编码”的EAV模式。不要挂断！它适用于您正在讨论的数据集大小并且实际上没有使用EAV - 它只是EAV-esque。

我们的想法是拥有一组表来存储这些自定义属性，并在其上添加一些触发器（如下所述）。自定义属性表集存储有关属性的元数据（它所使用的表，数据类型，约束等）。你可以非常喜欢这个，但我没有必要。

元数据表上的触发器用于重新生成将base + extension汇总到DB中的第一类对象的视图。因此，您有一个包含两者的员工视图，而不是表人员+员工扩展表。将新值拖放到自定义属性表中时，触发器将重新滚动视图并包含新内容。如果你想坚持下去，你也可以让触发器重写存储过程。根据您的中间层代码的结构，您仍然会被迫重新编码，但是如果您应用读取数据的规则，则无论如何都是如此。

在测试中，我发现对于你所谈论的相对较小的记录数，性能稍慢但遵循大致相同的降级模式（记录数量的2倍，慢速约2倍）。

- 编辑 -

我是如何看待它完成的，你有一个代表你的第一类对象的表，所以有一行代表'person'，一行代表'employee'等等。我们称之为FCO。然后你有一个辅助表，它存储了代表FCO的表。我们称之为Srcs ..对于人来说，会有一行，即人员表。对于Employee，将有两行，person表和Employee扩展。还有一个名为Attribs的第三个表，它存储构成FCO的表中的列。为简单起见，我们会说员工有ID，姓名和地址，而员工有雇用日期和部门，显然PersonID会回到Person表。因此，FCO表中的2行（人员和员工），Src表中的3行，Attrib中的8行。

视图，我们称之为vw_Employee，从两个表中选择PersonID，Name，Address，Hire Date，Department。它由SQL存储过程构建，我们将其称为OnMetadataChange。

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

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

如果您愿意我可以在那里抛出一些示例SQL。

Answer 2

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

1）有一个存储序列化自定义字段的列，其格式为mst方便。例如，此列可以存储xml。好处是你可以使用SQL Server Compact并且撤回记录是微不足道的。缺点是您总是需要拉/推整个xml blob来进行更新，并且很难在任何自定义字段上查询。

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

3）使用无架构数据库，如MongoDB或CouchDB。这些数据库都是关于存储无模式数据的，因此您的自定义字段与任何其他字段没有区别。因此，您可以索引和查询自定义字段。好处是自定义数据非常容易使用，缺点是你需要花一些时间重新思考如何存储数据以适应他们的模型。

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

高性能自定义用户字段

2 个答案: