2

我面对客户的应用程序如下所示：

  • 它允许最终用户输入“材料”。
  • 对于这些材料，它们可以附加任意数量的“属性”。
  • 属性可以有任何类型的值：decimal、int、dateTime 和 varchar（长度从 5 个字符到大块文本不等），

本质上，Schema 看起来像这样：

材料
MaterialID int not null PK
MaterialName varchar(100) not null

属性
PropertyID
PropertyName varchar(100)

MaterialsProperties
MaterialID
PropertyID
PropertyValue varchar(3000)

该应用程序的一个基本功能是搜索功能：最终用户可以通过输入以下查询来搜索材料：

  • [属性] 检查日期 > [日期时间值]
  • [属性] serialNr = 35465488

猜猜这在包含近 200 万条记录的 MaterialsProperties 表中的表现如何。

数据库最初是在 SQL Server 2000 下创建的，后来迁移到 SQL Server 2005

怎样才能做得更好？

4

2 回答 2

1

您可以考虑将您的 MaterialsProperties 表按类型分隔为IntMaterialProperties,CharMaterialProperties等。这将：

  • 对数据进行分区。
  • 允许对整数（或其他数字）类型的查找进行更快的查找。
  • 潜在地降低存储成本。

您还可以在 中引入一Type列Properties，您可以使用该列来确定MaterialProperties要查询的表。该列还可用于验证用户输入的类型是否正确，从而无需查询给定的“错误”输入。

于 2009-08-21T08:21:43.650 回答
0
  1. 由于用户可以输入他们自己的属性名称，我猜每个查询都将涉及对属性表的扫描（在您的示例中，我需要找到 [inspectionDate] 的属性 ID）。如果属性表很大，您的连接也需要很长时间。您可以通过非规范化和使用 propertyID 存储名称来尝试和优化。这将是 MaterialsProperties 表中的非规范化列。
  2. 您可以尝试将属性类型（int、char 等）添加到 materialsproperty 表并按类型对表进行分区。
  3. 查看用于查询优化的对象关系映射/实体属性值模型技术。
  4. 由于您已经拥有大量数据（200 万条记录），因此请进行一些数据挖掘，以查看是否存在许多材料的重复属性组。您可以将它们放在一个模式中，其余的作为 EAV 表。在这里查看详细信息：http ://portal.acm.org/citation.cfm?id=509015&dl=GUIDE&coll=GUIDE&CFID=49465839&CFTOKEN=33971901
于 2009-08-21T08:52:12.373 回答