【发布时间】:2009-01-13 18:25:45
【问题描述】:
工作流应用程序的数据模型应该是什么?目前,我们在 SQL Server 2000 中使用基于实体属性值的模型,用户能够创建动态表单(在 asp.net 上),但随着数据的增长,性能正在下降,难以生成报告,如果太多,情况会更糟用户同时查询数据(EAV)。
【问题讨论】:
标签: sql-server database database-design entity-attribute-value
工作流应用程序的数据模型应该是什么?目前,我们在 SQL Server 2000 中使用基于实体属性值的模型,用户能够创建动态表单(在 asp.net 上),但随着数据的增长,性能正在下降,难以生成报告,如果太多,情况会更糟用户同时查询数据(EAV)。
【问题讨论】:
标签: sql-server database database-design entity-attribute-value
您可能已经意识到,EAV 模型的问题在于表会变得非常大,而查询会很快变得非常复杂。例如,基于 EAV 的查询通常需要大量子查询才能获取相同的数据,如果您使用的是更传统的结构化表,则选择这些数据很容易。
不幸的是,要迁移到传统结构的关系模型是相当困难的同时让旧的形式可以修改。
因此,我的建议:考虑关闭对已建立的表单的更改,并将其数据移动到标准的规范化表中。例如,如果您有一组不太可能更改的运输表格(或者您可以通过更改应用程序来管理其更改,因为它很少发生),那么您可以创建一个固定表,然后将现有数据复制出您的 EAV 表。这将 A) 提高您进行报告的能力,B) 减少现有 EAV 表中的数据量和 C) 提高您支持并发用户的能力/提高性能,因为您可以在数据中构建更合适的索引。
简而言之,将基于 EAV 的动态系统视为收集用户需求的一种方式(他们通过构建表单来告诉您),而不是永久存储。随着表格演变为最终形式,您可以转换为固定表格以获得上述好处。
最后一件事。如果所有这些都不可能,您是否考虑过将您的 EAV 表分割成多个特定类别的表?例如,将所有运输表格放在一张表中,将人员表格放在一张表中,等等。它不会解决查询结构问题(需要子查询),但有助于缩小表格并提高性能。
我希望这会有所帮助 - 我对你的困境表示同情,因为我自己也遇到过类似的情况!
【讨论】:
通常,当您的数据库架构变得非常大并且多个用户尝试以多种不同方式访问相同信息时,应用Data Warehousing 以减少数据库服务器上的主要负载。与您很可能使用规范化来保持数据完整性的传统架构不同,数据仓库针对速度进行了优化,并且存储了多个数据副本。
【讨论】:
尝试使用数据的关系模型。它有效。
【讨论】: