J'ai plusieurs entités que j'ai besoin que des utilisateurs puissent ajouter des champs personnalisés à. p>
Si j'avais une entité appelée client avec des variables de base comme {Nom, Datefbirth, STACHTIED} et un autre appelé Store avec {nom} p>
Alors je voudrais que le propriétaire de ce magasin puisse se connecter et ajouter une nouvelle variable pour tous leurs clients appelé couleur préférée qui est une liste déroulante avec des options rouges, vertes ou bleues comme options. P>
Maintenant, j'ai examiné EAV et propose une solution qui ressemble à ceci p>
Attribut {StoreID, Nom, DataType}, Valeur {AttributeID, EntityName, EntityID, Valeur} P>
Je me demande existe une solution qui fonctionnera le mieux pour SQL Server 2008, en particulier étant donné que je voudrais pouvoir visualiser et interroger ces informations facilement. P>
J'ai entendu dire que vous pouvez interroger dans le type de données XML. Est-ce une meilleure façon d'aller? P>
Je voudrais également probablement que les utilisateurs puissent ajouter des champs personnalisés qui sont également des clés étrangères à un moment donné. P>
regardera cela toute la journée afin de poser des questions rapidement. p>
3 Réponses :
EAV en général est un anti-motif qui entraîne des performances et des étouffements bruts l'évolutivité. Maintenant, si vous décidez d'utiliser EAV, l'équipe consultative client SQL Server a publié un livre blanc avec des pièges et des problèmes communs et comment les éviter: Meilleures pratiques pour la modélisation des données sémantiques pour la performance et l'évolutivité . P>
Querifier un type de données XML est possible dans SQL, mais si votre XML n'a pas de schéma, alors la questionner, elle sera lente. S'il y a un schéma et que le schéma est EAV, il aura alors tous les problèmes de RAPATIONAL EAV plus certains de ses propres performances. Encore une fois, les bonnes personnes de l'équipe de chat ont publié quelques papiers blancs sur le sujet: XML meilleures pratiques pour Microsoft SQL Server 2005 et Optimisations de performance pour le XML Type de données dans SQL Server 2005 . Ils sont également valables pour SQL 2008. P>
J'utilise les fonctionnalités XML de SQL 2005/2008 pendant un moment. Je suis un peu à compter sur des colonnes XML.
Ce que vous voulez faire des sons comme le candidat parfait pour XML.
Par exemple, l'extrait suivant définit vos 2 entités (@customers et @stores), avec une colonne appelée «attrs» pouvant être étendue pour inclure davantage d'attributs.
J'espère que ça aide!
Excellentes réponses déjà. J'ajouterai uniquement la suggestion de maintenir des métadonnées pour les champs personnalisés également. Cela faciliterait une interface utilisateur de saisir plus facilement les champs personnalisés - vous seriez en mesure de limiter l'ensemble des champs personnalisés pour un client, par exemple, et de préciser que DateOfbirth doit être une date et que la ticket est censée correspondre à la ID d'un magasin réel. P>
Certaines de ces métadonnées pourraient être maintenues sous forme de schémas XML. J'ai vu cela fait, avec les schémas stockés dans la base de données et utilisé pour valider les champs personnalisés en cours d'entrée. Je ne sais pas si ces schémas peuvent également être utilisés pour saisir fortement les données XML. P>