通用数据库设计方法
我面对客户的应用程序如下所示：
- 它允许最终用户输入“材料”。
- 对于这些材料，他们可以附加任意数量的“属性”。
- 属性可以具有任何类型的值：decimal、int、dateTime 和 varchar（长度从 5 个字符到大块文本不等），
本质上，架构如下所示：
材料
MaterialID int not null PK
MaterialName varchar(100) not null
属性
属性ID
PropertyName varchar(100)
材质属性
材质ID
属性ID
PropertyValue varchar(3000)
该应用程序的一个基本功能是搜索功能： 最终用户可以通过输入以下查询来搜索材料：
- [property] InspectionDate > [DateTimeValue]
- [property] serialNr = 35465488
猜猜它在包含近 200 万条记录的 MaterialsProperties 表中的表现如何。
数据库最初是在 SQL Server 2000 下创建的，后来迁移到 SQL Server 2005，
如何才能做得更好？
An application that I'm facing at a customer, looks like this:
- it allows end users to enter "materials".
- To those materials, they can append any number of "properties".
- Properties can have a any value of type: decimal, int, dateTime and varchar (length varying from 5 characters to large chunks of text),
Essentially, the Schema looks like this:
Materials
MaterialID int not null PK
MaterialName varchar(100) not null
Properties
PropertyID
PropertyName varchar(100)
MaterialsProperties
MaterialID
PropertyID
PropertyValue varchar(3000)
An essential feature of the application is the search functionality:
end users can search materials by entering queries like:
- [property] inspectionDate > [DateTimeValue]
- [property] serialNr = 35465488
Guess how this performs over the MaterialsProperties-table with nearly 2 million records in it.
Database was initially created under SQL Server 2000 and later on migrated to SQL Server 2005
How can this be done better?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以考虑按类型将MaterialsProperties 表分隔为
IntMaterialProperties、CharMaterialProperties等。这将：您还可以向
Properties引入一个Type列，您可以使用该列来确定要查询哪个MaterialProperties表。 该列还可用于验证用户输入的类型是否正确，从而无需查询给定的“错误”输入。You could consider separating your MaterialsProperties table by typel e.g. into
IntMaterialProperties,CharMaterialProperties, etc. This would:You could also introduce a
Typecolumn toProperties, which you could use to determine whichMaterialPropertiestable to query. The column could also be used to validate the user's input is of the correct type, eliminating the need to query given "bad" input.