1

寻找自定义用户字段的示例/教程，而不是通过 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 的任何建议

4

2 回答 2

1

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

这个想法是有一组表来存储这些自定义属性，其中包含一些触发器（如下所述）。自定义属性表集存储有关属性的元数据（它使用的表、数据类型、约束等）。你可以很喜欢这个，但我没有必要。

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

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

-- 编辑 --

我是怎么看它的，你有一个代表你的第一类对象的表，所以一行代表“人”，一行代表“员工”，等等。我们称之为 FCO。然后你有一个辅助表来存储代表 FCO 的表。我们称它为 Srcs.. 对于 person，会有一行，即 person 表。对于 Employee，将有两行，即 person 表和 Employee 扩展。还有第三个表，称为 Attribs，它存储构成 FCO 的表中的列。为简单起见，我们会说 Employee 有 ID、Name 和 Address，Employee 有 Hire Date 和 Department，显然 PersonID 指的是 Person 表。因此，FCO 表中的 2 行（人员和员工），Src 表中的 3 行，Attribs 中的 8 行。

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

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

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

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

于 2012-04-24T18:22:03.633 回答
0

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

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

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

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

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

于 2012-04-27T21:26:02.250 回答