В то время как @marc_s правильно в его предостережениях, есть бесспорные ситуации, в которых реляционная модель достаточно просто не гибкая.Уже довольно много лет я работаю с базой данных, которая по большей части прямо-реляционная, но имеет небольшую часть EAV.Это связано с тем, что пользователи могут изобретать новые свойства в любое время для целей наблюдения в ходе испытаний.
По общему признанию, это неудобно по отношению к запросам и отчетам, если назвать несколько, но никакой другой стратегии здесь будет недостаточно.Мы используем хранимые процедуры с T-Sql pivot, чтобы предложить уплощенные структуры данных для отчетов и сетки с динамическими столбцами для отображения.Когда инфраструктура стоит, она становится довольно удобной.
Мы никогда не рассматривали возможность использования данных XML, потому что их там еще не было, и, кроме общих ограничений, у нас есть некоторые недостатки в нашем контексте:
- Данные EAV сильно запрашиваются.Команда разработчиков нуждается не только в стандартных знаниях SQL из-за специального синтаксиса.Индексирование возможно, но «с поддержанием индекса во время модификации данных связаны затраты ( согласно MSDN ).
- Тип данных XML гораздо менее доступен, чем обычные таблицы и поля, когда онприходит к обработке данных и составлению отчетов.
- Вряд ли когда-либо пользователи извлекают все значения атрибутов сущности, но в любом случае весь XML должен был бы быть сокращен.Тип данных XML (пока) не поддерживается Entity Framework.
Итак, в заключение я хотел бы сделать дизайн максимально реляционным, но EAV там, где это необходимо.На аукционе может быть несколько фиксированных полей и EAV для гибких данных.