подхода к проектированию баз данных общих

Question

Приложения, которое я столкнулся на клиенте, выглядит следующим образом:

• это позволяет конечным пользователям вводить «материалы».
• К этим материалам они могут добавлять любое количество «свойств».
• Свойство может иметь от любого значения типа: десятичный, INT, DATETIME и VARCHAR (длина колеблется от 5 символов до больших кусков текста),

По существу, схема выглядит следующим образом:

материалы
MaterialID Int не нулевой PK
MaterialName VARCHAR (100) NOT NULL

Свойства
PropertyID
PropertyName VARCHAR (100)

MaterialsProperties
MaterialID
PropertyID
PropertyValue VARCHAR (3000)

Существенной особенностью приложения является функция поиска: конечные пользователи может искать материалы, введя такие запросы, как:

• [свойство] inspectionDate> [DateTimeValue]
• [свойство] serialNr = 35465488

Угадайте, как это выполняет над MaterialsProperties столом с почти 2 миллиона записей в ней.

База данных была изначально создана под SQL Server 2000, а затем на мигрировали в SQL Server 2005

Как это можно сделать лучше?

Answer 1

1. Поскольку пользователи могут вводить свои собственные имена свойств, я предполагаю, что каждый запрос будет включать проверку таблицы свойств (в вашем примере мне нужно найти propertyid из [inspectDate]). Если таблица свойств велика, ваше соединение также займет много времени. Вы можете попробовать и оптимизировать, денормализируя и сохраняя имя с идентификатором propertyID. Это будет denaormalized колонка в таблице MaterialsProperties.
2. Вы можете попробовать добавить тип свойства (int, char и т. Д.) В таблицу materialproperty и разбить таблицу на тип.
3. Посмотрите на методы реляционного сопоставления объектов/сущности. Методы модели значений для оптимизации запросов.
4. Поскольку у вас уже есть много данных (2 миллиона записей), выполните некоторые интеллектуальные операции с данными, чтобы узнать, есть ли повторяющиеся группы свойств для многих материалов. Вы можете поместить их в одну схему, а остальные - в таблицу EAV. За дополнительной информацией обращайтесь: http://portal.acm.org/citation.cfm?id=509015&dl=GUIDE&coll=GUIDE&CFID=49465839&CFTOKEN=33971901

Answer 2

Вы можете рассмотреть возможность разделения таблицы MaterialsProperties на typel, например. в IntMaterialProperties, CharMaterialProperties и т.д. Это позволило бы:

• Partition ваши данные.
• Разрешить потенциально более быстрый поиск для целых (или других числовых) типов.
• Потенциально снизить затраты на хранение.

Вы также можете ввести Type столбец Properties, который вы могли бы использовать, чтобы определить, какие MaterialProperties таблицы для запроса. Столбец также может использоваться для проверки ввода пользователем правильного типа, что исключает необходимость запроса с учетом «плохого» ввода.