Est-il acceptable d'utiliser une colonne XML pour stocker des données supplémentaires?

Question

Si cela est correct et recommandé d'utiliser une colonne xml pour stocker toutes les données supplémentaires que l'interface utilisateur peut fournir?

Par exemple, supposons une table d'employés

CREATE TABLE Employee 
(
    EmployeeId int not null, 
    Name nvarchar(300) not null, 
    Phone varchar(30) null, 
    Email varchar(320) null, 
    Address nvarchar(max) null, 
    Data xml null 
) 

Data pourrait contient de nombreuses valeurs comme les numéros de téléphone supplémentaires, des commentaires ...

Nous nous attendons à ce que tous nos clients demandera des différents domaines Employee , et nous ne voulons pas jouer avec la structure de base de données chaque fois qu'ils pensent à un nouveau champ à ajouter.

Nous nous attendons les données stockées dans la colonne XML à des données peu fréquentés. En plus d'être visible tout en parcourant la liste des employés, les données peuvent avoir besoin d'être imprimées. Nous avons donc besoin de stocker le type de données le long des données (un peu comme un jeu de données est sérialisation ses données)

Est-ce est une bonne approche pour stocker des données supplémentaires inconnus?

Edité a donné un meilleur exemple

Mise à jour Je ne l'ai pas choisi encore une réponse parce que je discute avec mon équipe de l'approche différente les gars proposées.

Answer 1

Vous pouvez le faire comme ceci:

[EmployeeField] 
----------------------------------------------------- 
EmployeeID EmployeeFieldName EmployeeFieldValue 

Il est en fait la même approche d'adhésion .NET utilise pour les profils utilisateur avec des champs dynamiques. De nombreuses applications métier utilisent la même approche pour stocker des entrées dynamiques spécifiques aux clients.

décomptées au commentaire de Spencer Ruport, cette approche est connue sous le nom Entity-Attribute-Value model (EAV).

Answer 2

Dépend de ce que sont les données. S'il n'est pas facile de modéliser dans une structure relationnelle, alors ce que vous proposez (c'est vraiment juste un Serialized LOB) est OK.

Answer 3

Vous se couper les genoux à l'aide d'un modèle de base de données relationnelle pour cela. Les bases de données relationnelles sont construites autour de l'idée d'une structure statique de données et de pouvoir interroger facilement et rapidement. Même l'adoption d'une structure EAV en tant que «Nouveau en ville» va à l'encontre de ce principe, même s'il est sans doute préférable à un simple vidage de données XML dans la colonne. Si customer est une curiosité et le reste de vos données est OK, alors il est probablement bien de le faire, mais je voudrais certainement aller avec l'approche EAV. Si la plupart de vos tableaux se présentent de cette manière, il est temps de repenser votre approche du stockage de données.

Answer 4

Une colonne XML est un format très flexible, mais aussi très mauvais pour la recherche. L'utilisateur "Nouveau dans la ville" vous dirige vers une autre solution standard, moins flexible mais avec la possibilité de sélectionner et de rejoindre les attributs supplémentaires.

Answer 5

Personnellement, je préfère ajouter des données inconnues supplémentaires dans un tableau distinct. Cela vous permet d'autoriser un nombre infini d'options (il suffit d'avoir des colonnes ID, Nom, Type (? - facultatif) et Données), mais offre l'avantage supplémentaire de permettre des mises à jour/suppressions sélectives.

Si vous le faites en tant que blob de données unique, chaque fois que vous modifiez une seule partie des données auxiliaires, vous devrez remplacer le champ de données entier.

Answer 6

Si vous souhaitez utiliser les données dans une requête, je ne recommanderais pas de le mettre dans un champ xml. Oui, il existe des moyens d'interroger des données à partir de champs XML, mais je ne les ai pas trouvés efficaces.

Answer 7

Oui, c'est OK. Que ce soit recommandé dépend fortement de votre situation spécifique. Nous faisons quelque chose de similaire en utilisant Oracle et la flexibilité est excellente, mais notre framework web personnalisé (servlet Java qui produit des pages web/applications basées sur des modules écrits en XML) utilise beaucoup de XML et nous avons des systèmes spécifiques pour stocker les données une seule colonne XML donc mon opinion et mon expérience sont basées sur des scénarios où c'est pratique. Par exemple (et je sais que cela peut sembler aberrant pour les gens), si vous recherchez des données à l'intérieur de votre fichier XML, cela peut poser un problème car vous exécutez XPaths et extrayez les données du XML sur chaque ligne. temps que vous recherchez est un coup de performance massive. Nous avons un système en place similaire aux vues matérialisées qui utilise des déclencheurs et une requête stockée. Chaque fois qu'une rangée dans la basetable (contenant la colonne XML) est modifiée, les déclencheurs se déclenchent, votre requête est exécutée et extrait les données du XML et les insère dans une table relationnelle qui à son tour a une vue sur elle pour vous assurer Ne modifiez pas les données relationnelles (puisque cela ne reflète pas dans le XML). Pour les besoins de quelque chose comme un grand nombre de formulaires basés sur le Web effectuant des opérations CRUD où le schéma et donc le modèle de données peuvent souvent changer, c'est fantastique. Cela signifie que vous pouvez extraire votre fragment XML et avoir instantanément le modèle sous-jacent pour votre page et l'enregistrer est aussi simple que coller simplement le fragment XML. Pour un accès rapide en lecture seule, nous avons un accès instantané à une vue relationnelle du XML .

Answer 8

Je suppose que vous devrez également interroger et rechercher des attributs d'employé dans le XML.

Cela peut être OK si vous utilisez un schéma XML et créez les index XML nécessaires. Vous pouvez également utiliser un modèle relationnel EAV et sera probablement plus performant. Si vous souhaitez mettre en œuvre un modèle EAV, le livre blanc écrit par l'équipe de conseil clientèle SQL traite des pièges courants et des problèmes liés aux modèles EAV mal conçus.

En note, stocker uniquement ID et NAME pour une entité aussi riche en attributs qu'un employé sonne comme si vous étiez vraiment en train d'abandonner la balle en deçà du but. Vous devriez au moins ajouter les attributs communs que vous attendez de votre majorité de clients et ne compter que sur des modèles extensibles (XML ou EAV) pour les attributs supplémentaires que vous ne pouvez pas voir.

Mise à jour

Puisque nous y sommes, voici les livres blancs-SQL CAT sur les meilleures pratiques XML aussi:

• XML Best Practices for Microsoft SQL Server 2005
• Performance Optimizations for the XML Data Type in SQL Server 2005

Answer 9

Oui , à condition que les données supplémentaires ne "lient" à aucune autre table, et que vous n'avez pas besoin h là-dessus. Si vous avez plus d'un utilisateur qui édite différentes parties du données supplémentaires pour le même employé, alors réfléchissez bien à votre conception.Par conséquent, si vos données supplémentaires ne sont que des champs "notes" et que vous avez des en-têtes prédéfinis par client, alors c'est OK.

Il n'y a aucun avantage à placer ces données supplémentaires dans une table [EmployeeField], car cela rend le code d'accès aux données plus complexe sans vous permettre de tirer parti de la puissance de la base de données. Plutôt que de stocker le type avec chaque donnée, je pense que vous devriez avoir une table de méta-données qui stocke le type, le nom et le "nom d'affichage" de chaque bit de données supplémentaires qu'un client donné souhaite avoir. Vous devrez peut-être également stocker la disposition de formulaire que le client souhaite utiliser pour entrer les données supplémentaires.