高性能自定义用户字段
寻找自定义用户字段的示例/教程，而不是通过EAV
EAV由于诸如性能等各种原因将会出现问题
查看通过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 for Sql Server compact 4的建议
我见过的一种技术是使用一种“硬编码”的EAV模式。 不要挂断！ 它适用于您所讨论的数据集大小，并且实际上并未使用EAV - 它只是EAV类型的。
这个想法是有一组表来存储这些自定义属性，其中有一些触发器（如下所述）。 自定义属性表集存储关于属性的元数据（它随附的表，数据类型，约束等）。 你可以非常喜欢这个，但我并不需要。
元表上的触发器用于重新生成视图，将基础+扩展汇总到数据库中的第一类对象中。 因此，而不是表人+员工扩展表，您有一个员工视图，其中包括两个。 当您将新值放入自定义属性表中时，触发器将重新展开视图并包含新内容。 如果你想坚持下去，你也可以让触发器重写存储过程。 根据您的中间层代码的结构，您仍然会被迫重新编写一些代码，但是无论如何，如果您要应用读取数据的规则，情况就会如此。
在测试中，我发现对于您所谈论的相对较少的记录数来说，性能稍微慢一些，但大致遵循相同的降级模式（两倍的记录数，慢到两倍）。
- 编辑 -
我是如何看待它的，你有一张表格代表你的第一类对象，所以一行代表'人'，一行代表'员工'，等等。我们称之为FCO。 然后你有一个辅助表，它存储了代表FCO的表格。 我们称之为Srcs ..对于人来说，将会有一行，即人员表。 对于员工，将有两行，即人员表和员工扩展。 还有第三个表，名为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。 它由一个SQL存储过程构建，我们将其称为OnMetadataChange。
该SP被触发（通过触发或批处理），其目的是生成CREATE VIEW语句。 它将遍历每个First Class Object，收集哪些表构成视图的哪些字段，并基于此发出CREATE语句。 因此，OnMetadataChange为每个视图生成DROP和CREATE，它会生成一个动态SQL语句，该语句在FCO表中的每个条目中执行一次。 最好用触发器做到这一点，但不是必需的。 希望你的FCO定义不会经常改变，当他们这样做时，也可能会有代码发布。 您可以在那时运行您的OnMetadataChange SP。
最终结果是一个2层数据库。 这些视图构成了First Class Object层，这对于应用程序来说是有意义的。 该应用程序仅使用视图。 这些表格构成了“物理”层，应用程序不应关心这一层。 元表本质上是您在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都是免费的。
链接地址: http://www.djcxy.com/p/68629.html