Niestandardowe pola z SQL Server 2008

Question

Mam kilka elementów, które wymagają, aby użytkownicy mogli dodawać pola niestandardowe.

Gdybym miał podmiot o nazwie klienta ze zmiennych bazowych takich jak {nazwa, DateOfBirth, StoreId} a drugi o nazwie Sklep z {nazwa}

Następnie chciałbym go tak, że właściciel tego sklepu mogli zalogować i dodaj nową zmienną dla wszystkich swoich klientów nazywaną ulubionym kolorem, która jest opcją z czerwonymi, zielonymi lub niebieskim opcjami.

Teraz miałem przyjrzeć EAV i wymyślić rozwiązanie, które wygląda tak

Attribute {StoreId, nazwa, typ danych} Wartość {attributeId, EntityName, identyfikator podmiotu, Value}

Zastanawiam się, czy istnieje jakieś rozwiązanie, które będzie najlepiej działać w SQL Server 2008, szczególnie biorąc pod uwagę, że chcę mieć możliwość łatwego przeglądania i wysyłania zapytań o te informacje.

Słyszałem, że można wyszukiwać w typie danych xml. Czy to jest lepszy sposób na wyjazd?

Prawdopodobnie chcę też, aby użytkownicy mogli w pewnym momencie dodawać pola niestandardowe, które są obcymi kluczami.

Będę patrzył na to przez cały dzień, więc szybko zadam pytania.

Answer 1

Ogólnie EAV to anty-wzór, który powoduje obniżenie wydajności i dławi skalowalność. Teraz, jeśli zdecydujesz się na EAV, zespół doradców klienta SQL Server opublikował białą księgę zawierającą typowe pułapki i problemy oraz sposoby ich uniknięcia: Best Practices for Semantic Data Modeling for Performance and Scalability.

Zapytanie o typ danych XML jest możliwe w SQL, ale jeśli twój XML nie ma schematu, to zapytanie będzie wolne. Jeśli ma schemat, a schematem jest EAV, to będzie miał wszystkie problemy związane z relacyjną EAV i niektóre z nich dla wydajności XML. znowu dobrzy ludzie z zespołu CAT opublikowali kilka białych ksiąg na ten temat: XML Best Practices for Microsoft SQL Server 2005 i Performance Optimizations for the XML Data Type in SQL Server 2005. Obowiązują również dla SQL 2008.

Answer 2

Przez jakiś czas korzystałem z funkcji XML SQL 2005/2008. Doszedłem do tego, aby polegać na kolumnach XML całkiem sporo. Co chcesz zrobić brzmi jak idealny kandydat do XML. Na przykład poniższy fragment definiuje twoje 2 elementy (@customers i @stores), z kolumną o nazwie "attrs", którą można rozszerzyć, aby zawierała więcej atrybutów. Mam nadzieję, że to pomoże!

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); 

Answer 3

Doskonałe odpowiedzi już. Dodam tylko sugestię, że zachowujesz także metadane dla pól niestandardowych. Dzięki temu interfejs użytkownika do wprowadzania niestandardowych pól będzie łatwiejszy - na przykład możesz ograniczyć zbiór niestandardowych pól dla klienta i określić, że DateOfBirth ma być datą, a identyfikator StoreID ma być zgodny z Identyfikator rzeczywistego sklepu.

Niektóre z tych metadanych można zachować jako schematy XML. Widziałem, że to zrobione, ze schematami przechowywanymi w bazie danych i używane do sprawdzania danych wprowadzanych przez pola niestandardowe. Nie wiem, czy te schematy mogą być również używane do silnego wpisywania danych XML.