Quando utilizzare il tipo di dati XML

12

Sono responsabile della creazione di un database su un progetto. Abbiamo campi che raramente avranno un valore (1 su ogni 10.000 record) e sto cercando di trovare il modo migliore per archiviarlo nel database.

Per quanto posso vedere, ho 3 opzioni:

Aggiungi una colonna nella tabella per ogni valore extra
Aggiungi una tabella collegata che fa riferimento alla tabella originale e contiene record solo dove è necessario memorizzare un valore
Utilizzare il tipo di dati XML nella tabella originale e memorizzare tutti i valori in questo.

Ci sono altre opzioni che non ho considerato?

Sto cercando di capire i pro e i contro di ogni metodo. Per quanto ne so, 1 sarebbe il più semplice e 2 occuperebbe la minima quantità di spazio, ma faccio fatica a trovare molte risorse per 3.

sql-server-2008 xml

— Matthew Steeples
fonte

1

Per aggiungere un rant personale contro l'abuso di xml in un database risponderei direttamente alla domanda nel titolo e direi un grosso grasso: MAI! Per la vera questione della domanda, permetterò ai colleghi di aiutarti, perché hai già ottime risposte :-). PS: puoi davvero ignorare la mia prima frase.

— Mariano

Di quanti campi extra stai parlando? E hanno senso far parte della stessa Entità?

— Andrew Bickerton,

12

Suona come quello di cui hai bisogno sono colonne sparse e indici filtrati e vai con l'opzione 1. Queste sono funzioni completamente supportate e documentate esattamente per questo scenario.

Motore di database di SQL Server utilizza la parola chiave SPARSE in una definizione di colonna per ottimizzare la memorizzazione dei valori in quella colonna. Pertanto, quando il valore della colonna è NULL per qualsiasi riga della tabella, il valore non richiede memoria.

Non riesco a immaginare una soluzione XML che funzioni bene in questo scenario, avrà un enorme sovraccarico di metadati ridondanti e sarà lenta da interrogare.

— Caio
fonte

1

Penso che le colonne sparse siano ciò che sto cercando. Mi aspetto che una piccola quantità di dati venga archiviata in una manciata di colonne su alcune tabelle.

— Matthew Steeples,

Non sono sicuro se sto leggendo bene, ma secondo questo link le colonne sparse sono fondamentalmente un'implementazione del database di ciò che stavo cercando 3 comunque non sono? blog.sqlauthority.com/2008/07/14/…

— Matthew Steeples

Se è implementato internamente in quel modo (e non so che lo sia, è solo il blog di qualcuno), non dovrai mai gestire o analizzare l'XML da solo - si comporterà esattamente come una tabella normale con (con eventuali restrizioni su tipi di dati)

— Gaius

5

Una colonna nullable non occupa spazio se lunghezza variabile in SQL Server. Il fatto di essere NULL è memorizzato nella bitmap NULL . Se necessario, puoi indicizzarlo con indici filtrati in modo da ignorare le colonne NULL.
Aggiunge complessità se si considera il punto 1.
Non farlo. Difficile da cercare, analizzare ecc: te ne pentirai più tardi

Dipende anche dalle dimensioni: sarà char (1000) per qualche miliardo di righe? O piccolo per 100.000 file? Se quest'ultimo considera la complessità aggiunta del punto 2: non ne vale la pena.

— GBN
fonte

Hai un riferimento che una colonna nullable che è null non occupa spazio. Sapevo che se era nullo o meno era archiviato nella bitmap null ma pensavo che per i campi a lunghezza fissa i dati fossero ancora memorizzati nella tabella. Il tipo di dati che userò per la maggior parte di questi valori è denaro (quindi 8 byte)

— Matthew Steeples

1

@Matthew Steeples: ho detto che la lunghezza variabile non occupa già spazio. E per riferimento sqlskills.com/BLOGS/PAUL/category/On-Disk-Structures.aspx#p41 Come possono le righe per questi 8 byte?

— gbn

Al momento siamo a 500.000 righe ma ci saremo espandendo (si spera) ad una velocità di circa 1 milione al giorno feriale una volta che saremo vivi.

— Matthew Steeples,

3

Con SQL Server 2008 hai la possibilità aggiuntiva di utilizzare colonne sparse, progettate appositamente per la situazione menzionata.

Hanno il vantaggio aggiuntivo di poterli visualizzare come un oggetto XML combinato utilizzando XML COLUMN_SET o di consultarli singolarmente e offrono un enorme risparmio di spazio.

Consulta il seguente articolo di blog per maggiori dettagli: http://www.sqlskills.com/BLOGS/PAUL/post/SQL-Server-2008-Sparse-columns-and-XML-COLUMN_SET.aspx

— Jeff
fonte

-4

Una quarta opzione: non usare le tabelle. Le tabelle sono molto inadatte a questo tipo di dati (in realtà, a qualsiasi tipo di dati che non è stato adattato forzatamente in forma tabellare). Usa solo XML.

— user1359
fonte

3

-1 poiché mentre è vero che "non usare le tabelle" è un'opzione , la risposta indica chiaramente un rant contro le strutture delle tabelle e non sta effettivamente fornendo una risposta utile.

— Andrew Bickerton,