Campi personalizzati con SQL Server 2008

Question

Ho diverse entità che richiedono agli utenti di aggiungere campi personalizzati.

Se avessi un'entità chiamata cliente con le variabili di base come {Nome, DateOfBirth, StoreID} e un altro chiamato Store con {nome}

Poi vorrei in modo che il proprietario di quel negozio potrebbe effettuare il login e aggiungi una nuova variabile per tutti i loro clienti chiamata colore preferito, che è un menu a discesa con il rosso, il verde o il blu come opzioni.

ora ho avuto uno sguardo al EAV e trovare una soluzione che assomiglia a questo

Attributo {StoreID, nome, tipo di dati}, valore {AttributeID, EntityName, EntityID, valore}

Mi chiedo se ci sia una soluzione che funzionerà al meglio per SQL Server 2008, soprattutto visto che voglio essere in grado di visualizzare e interrogare facilmente queste informazioni.

Ho sentito che è possibile eseguire una query all'interno del tipo di dati xml. E 'un modo migliore di andare?

Probabilmente vorrò anche che gli utenti possano aggiungere campi personalizzati che sono chiavi esterne a un certo punto.

Lo guarderà tutto il giorno e quindi farà domande rapidamente.

Answer 1

EAV in generale è un anti-pattern che si traduce in prestazioni lugubri e soffoca la scalabilità. Ora se si decide di utilizzare EAV, il team di consulenza clienti di SQL Server ha pubblicato un white paper con problemi e problemi comuni e su come evitarli: Best Practices for Semantic Data Modeling for Performance and Scalability.

La query su un tipo di dati XML è possibile in SQL, ma se il tuo XML non ha schema, la query sarà lenta. Se ha uno schema e lo schema è EAV, allora avrà tutti i problemi dell'EAV relazionale più alcuni dei suoi per le prestazioni XML. ancora una volta i bravi ragazzi del team CAT hanno pubblicato un paio di white paper sul tema: XML Best Practices for Microsoft SQL Server 2005 e Performance Optimizations for the XML Data Type in SQL Server 2005. Sono validi anche per SQL 2008.

Answer 2

Ho utilizzato le funzionalità XML di SQL 2005/2008 per un po '. Sono arrivato a contare su colonne XML un po '. Quello che vuoi fare sembra il candidato perfetto per XML. Ad esempio, il seguente snippet definisce le tue 2 entità (@clienti e @stores), con una colonna chiamata "attrs" che può essere espansa per includere più attributi. Spero che questo aiuti!

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

Già risposte eccellenti. Aggiungerò solo il suggerimento di mantenere i metadati per i campi personalizzati. Ciò renderebbe più semplice un'interfaccia utente per l'inserimento dei campi personalizzati: sarebbe possibile limitare l'insieme di campi personalizzati per un cliente, ad esempio, e specificare che DateOfBirth deve essere una data e che StoreID deve corrispondere a ID di un negozio reale.

Alcuni di questi metadati potrebbero essere gestiti come schemi XML. L'ho visto fare, con gli schemi memorizzati nel database, e usato per convalidare i campi personalizzati che vengono inseriti. Non so se questi schemi possano essere usati anche per scrivere con forza i dati XML.