高性能自定义用户字段

本文关键字：字段 用户 自定义 高性能 | 更新日期: 2023-09-27 18:31:39

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

高性能自定义用户字段

我见过的一种技术是使用一种"硬编码"EAV模式。 不要挂断电话！ 它与您所说的数据集大小配合得很好，实际上并没有使用 EAV - 它只是 EAV 式的。

这个想法是有一组表来存储这些自定义属性，并在其中有一些触发器（如下所述）。 自定义属性表集存储有关属性的元数据（它与哪个表、数据类型、约束等）。 你可以对此感到非常花哨，但我不需要。

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

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

--编辑--

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

视图（我们称之为 vw_Employee）从两个表中选择"人员 ID"、"姓名"、"地址"、"雇用日期"、"部门"。 它是由一个SQL存储过程构建的，我们将称之为OnMetadataChange。

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

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

如果你愿意，我可以抛出一些示例SQL。

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

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

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

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

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

相关文章：