Пользовательские поля с SQL Server 2008
База данных я сделал большую часть своей работы над используемым 'Y' / 'N' как булевские переменные. С той реализацией можно осуществить некоторые приемы как:
-
строки количества, которые верны:
ИЗБРАННАЯ СУММА (СЛУЧАЙ, КОГДА BOOLEAN_FLAG = 'Y' ТОГДА 1 ЕЩЕ 0) ОТ X -
При группировке строк, осуществите, "Если одна строка верна, то все - истинная" логика:
ВЫБОР МАКС (BOOLEAN_FLAG) ОТ Y
С другой стороны, используйте МИН для принуждения группирующейся лжи, если одна строка является ложью.
3 ответа
EAV в целом представляет собой антишаблон, который приводит к плохой производительности и ограничивает масштабируемость. Теперь, если вы решите использовать EAV, группа поддержки клиентов SQL Server опубликовала технический документ с описанием распространенных ошибок и проблем и способов их избежать: Лучшие практики моделирования семантических данных для повышения производительности и масштабируемости .
] Запрос типа данных XML возможен в SQL, но если ваш XML не имеет схемы, запрос к нему будет медленным. Если у него есть схема, и это схема EAV, тогда у него будут все проблемы реляционного EAV плюс некоторые свои собственные для производительности XML. И снова добрые люди из команды CAT опубликовали несколько официальных документов по этой теме: Лучшие практики XML для Microsoft SQL Server 2005 и Оптимизация производительности для типа данных XML в SQL Server 2005 . Они также действительны для SQL 2008.
Некоторое время я использовал функции XML SQL 2005/2008. Я стал довольно часто полагаться на столбцы XML. То, что вы хотите сделать, звучит как идеальный кандидат для XML. Например, следующий фрагмент определяет ваши 2 объекта (@customers и @stores) со столбцом под названием "attrs", который можно расширить, чтобы включить дополнительные атрибуты. Надеюсь, это поможет!
declare @customers as table ( id int, attrs xml);
INSERT INTO @customers VALUES
(1,'<Attrs Name="Peter" DateOfBirth="1996-01-25" StoreId="10" />'),
(2,'<Attrs Name="Smith" DateOfBirth="1993-05-02" StoreId="20" />')
;
declare @stores as table ( id int, attrs xml);
insert into @stores VALUES
(10, '<Attrs Name="Store1" />'),
(20, '<Attrs Name="Store2" />')
;
With c as (
select id as CustomerID,
attrs.value('(/Attrs[1])/@Name', 'nvarchar(100)') as Name,
attrs.value('(/Attrs[1])/@DateOfBirth', 'date') as DateOfBirth,
attrs.value('(/Attrs[1])/@StoreId', 'int') as StoreId
from @customers
), s as (
select id as StoreID,
attrs.value('(/Attrs[1])/@Name', 'nvarchar(100)') as Name
from @stores
)
select *
from c left outer join s on (c.StoreId=s.StoreID);
Отличные ответы уже. Я только добавлю предложение, чтобы вы также поддерживали метаданные для настраиваемых полей. Это упростит пользовательский интерфейс для ввода настраиваемых полей - например, вы сможете ограничить набор настраиваемых полей для клиента и указать, что DateOfBirth должен быть датой, а StoreID должен соответствовать ID фактического магазина.
Некоторые из этих метаданных могут поддерживаться как схемы XML. Я видел это со схемами, хранящимися в базе данных и используемыми для проверки вводимых настраиваемых полей.