Quand utiliser le type de données XML

12

Je suis responsable de la création d'une base de données sur un projet. Nous avons des champs qui vont rarement avoir une valeur (1 sur 10 000 enregistrements) et j'essaie de trouver la meilleure façon de stocker cela dans la base de données.

Pour autant que je puisse voir, j'ai 3 options:

  1. Ajoutez une colonne dans le tableau pour chaque valeur supplémentaire
  2. Ajoutez une table liée qui fait référence à la table d'origine et n'a des enregistrements que là où nous devons stocker une valeur
  3. Utilisez le type de données XML dans la table d'origine et stockez toutes les valeurs dans celui-ci.

Y a-t-il d'autres options que je n'ai pas envisagées?

J'essaie de déterminer les avantages et les inconvénients de chaque méthode. Pour autant que je sache, 1 serait le plus facile et 2 prendrait le moins d'espace, mais j'ai du mal à trouver de nombreuses ressources pour 3.

sql-server-2008 xml Matthew Steeples
la source
1
Pour ajouter une diatribe personnelle contre l'abus xml dans une base de données, je répondrais directement à la question dans le titre et dirais un gros gros: JAMAIS! Pour le corps même de la question, je vais laisser les collègues vous aider, car vous avez déjà de très bonnes réponses :-). PS: vous pouvez en fait ignorer ma première phrase.
Marian
De combien de champs supplémentaires parlez-vous? Et ont-ils un sens à faire partie de la même entité?
Andrew Bickerton

Réponses:

12

Cela ressemble à ce dont vous avez besoin: des colonnes éparses et des index filtrés et choisissez l'option 1. Ce sont des fonctionnalités entièrement prises en charge et documentées pour exactement ce scénario.

Le moteur de base de données SQL Server utilise le mot clé SPARSE dans une définition de colonne pour optimiser le stockage des valeurs dans cette colonne. Par conséquent, lorsque la valeur de la colonne est NULL pour n'importe quelle ligne de la table, la valeur ne nécessite aucun stockage.

Je ne peux pas imaginer une solution XML performante dans ce scénario, elle aura un énorme surcoût de métadonnées redondantes et sera lente à interroger.

Gaius
la source
1
Je pense que les colonnes éparses sont ce que je recherche. Je m'attends à ce qu'une très petite quantité de données soit stockée dans probablement une poignée de colonnes sur certaines tables.
Matthew Steeples
Je ne sais pas si je lis bien, mais selon ce lien, les colonnes éparses sont fondamentalement une implémentation de base de données de ce que je cherchais de toute façon, n'est-ce pas? blog.sqlauthority.com/2008/07/14/…
Matthew Steeples
S'il est implémenté en interne comme ça (et je ne sais pas, c'est juste le blog de quelqu'un), vous n'aurez jamais à traiter ou à analyser le XML vous-même - il se comportera exactement comme un tableau normal avec (avec toutes les restrictions sur les types de données)
Gaius
5

  1. Une colonne nullable ne prend pas d' espace si elle est de longueur variable dans SQL Server. Le fait d'être NULL est stocké dans le bitmap NULL . Vous pouvez l'indexer si nécessaire avec des index filtrés afin d'ignorer les colonnes NULL.

  2. Ajoute de la complexité lorsque vous considérez le point 1.

  3. Non. Difficile à rechercher, à analyser, etc.: vous le regretterez plus tard

Cela dépend aussi de la taille: est-ce que ce sera char (1000) pour quelques milliards de lignes? Ou minuscule pour 100 000 lignes? Si ces derniers considèrent la complexité supplémentaire du point 2: cela n'en vaut pas la peine.

gbn
la source
Avez-vous une référence selon laquelle une colonne nullable qui est nulle ne prend pas d'espace. Je savais que si elle était nulle ou non était stockée dans le bitmap nul mais pensais pour les champs de longueur fixe que les données étaient toujours stockées dans la table. Le type de données que j'utiliserai pour la plupart de ces valeurs est l'argent (donc 8 octets)
Matthew Steeples
1
@Matthew Steeples: J'ai dit que la longueur variable ne prend pas déjà de place. Et pour référence sqlskills.com/BLOGS/PAUL/category/On-Disk-Structures.aspx#p41 Comment peuvent les lignes pour ces 8 octets?
gbn
Pour le moment, nous en sommes à 500 000 lignes, mais nous allons étendre (espérons-le) à un rythme d'environ 1 million par jour de semaine une fois que nous serons en direct.
Matthew Steeples
3

Avec SQL Server 2008, vous avez la possibilité supplémentaire d'utiliser des colonnes éparses, qui sont conçues spécifiquement pour la situation que vous avez mentionnée.

Ils ont l'avantage supplémentaire que vous pouvez les visualiser en tant qu'objet XML combiné à l'aide de XML COLUMN_SET ou les référencer individuellement et ils offrent une économie d'espace considérable.

Consultez l'article de blog suivant pour plus de détails: http://www.sqlskills.com/BLOGS/PAUL/post/SQL-Server-2008-Sparse-columns-and-XML-COLUMN_SET.aspx

Jeff
la source
-4

Une quatrième option: ne pas utiliser de tableaux. Les tableaux sont très mal adaptés à ce type de données (en fait, à tout type de données qui n'ont pas été ajustées de force sous forme de tableau). Utilisez simplement XML.

user1359
la source
3
-1 comme s'il est vrai que "ne pas utiliser de tables" est une option , la réponse est clairement énoncer une diatribe contre les structures de table et ne pas réellement soumettre une réponse utile.
Andrew Bickerton