Approach to generic database design

Question

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

Answer 1

1. Since users can enter their own property names, i guess every query is going to involve a scan of the properties table (in your example i need to find the propertyid of [inspectionDate]). If the properties table is large, your join would also take a long time. You could try and optimize by denormalizing and storing name with propertyID. This would be a denaormalized column in the MaterialsProperties table.
2. You could try adding a property type (int, char etc) to the materialsproperty table and partition the table on the type.
3. Look at Object Relational Mapping/Entity Attribute Value Model techniques for query optimization.
4. Since you already have a lot of data (2 million records) do some data mining as see if there are repeating groups of properties for many materials. You can them put them in one schema and the rest as the EAV table. Look here for details: http://portal.acm.org/citation.cfm?id=509015&dl=GUIDE&coll=GUIDE&CFID=49465839&CFTOKEN=33971901

Answer 2

You could consider separating your MaterialsProperties table by typel e.g. into IntMaterialProperties, CharMaterialProperties, etc. This would:

• Partition your data.
• Allow for potentially faster look-ups for integer (or other numeric) type look-ups.
• Potentially reduce storage costs.

You could also introduce a Type column to Properties, which you could use to determine which MaterialProperties table 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.