Possibili vantaggi della memorizzazione di più valori in un campo di una riga anziché come righe separate

Durante la nostra ultima riunione settimanale, una persona che non ha esperienza in amministrazione dei database ha sollevato questa domanda:

"Ci sarebbe uno scenario che giustifica l'archiviazione dei dati in linea (stringa) anziché diverse righe?"

Supponiamo che un tavolo chiamato countryStatesdove vogliamo memorizzare gli stati di un paese; Userò gli Stati Uniti per questo esempio e non elencherò tutti gli Stati per motivi di pigrizia.

Lì avremmo due colonne; uno ha chiamato Countrye l'altro ha chiamato States. Come discusso qui , e proposto dalla risposta di @srutzky , PKsarà il codice definito da ISO 3166-1 alpha-3 .

La nostra tabella sarebbe simile a questa:

+---------+-----------------------+-------------------------------------------------------+
| Country | States                | StateName                                             |
+---------+-----------------------+-------------------------------------------------------+
| USA     | AL, CA, FL,OH, NY, WY | Alabama, California, Florida, Ohio, New York, Wyoming |
+---------+-----------------------+-------------------------------------------------------+

Quando ha posto la stessa domanda a un amico sviluppatore, ha detto che dal punto di vista delle dimensioni del traffico dati, questo potrebbe essere utile, ma non se dobbiamo manipolare questi dati. In questo caso dovrebbe esserci un'intelligence sul codice dell'applicazione che potrebbe trasformare questa stringa in un elenco (diciamo che il software che ha accesso a questa tabella deve creare una casella combinata).

Abbiamo concluso che questo modello non è molto utile, ma ho avuto il sospetto che potrebbe esserci un modo per renderlo utile.

Quello che vorrei chiedere è se qualcuno di voi ha già visto, sentito o fatto qualcosa del genere in un modo che funziona davvero .

Per cominciare, l'attuale titolo della domanda che si riferisce alla "memorizzazione di dati come stringa anziché come colonne" è un po 'confuso. Quando si parla di archiviare i dati come stringhe anziché qualcos'altro, ciò di solito si riferisce alla serializzazione di tutto in un formato stringa anziché in un tipo di dati appropriato / forte (ad es. INTO DATETIME). Ma se si chiede di archiviare i dati come valori multipli in un singolo campo rispetto a righe separate, è un po 'diverso. E per essere onesti, mentre la concatenazione dei valori viene eseguita più facilmente con le stringhe, può anche essere eseguita con INTe BINARYtipi, sia mediante mascheratura di bit sia riservando in modo simile determinate posizioni per avere significati diversi. Dal momento che la seconda interpretazione è ciò che viene effettivamente chiesto, basato sul testo della domanda, affrontiamolo.

In una parola: No. Se stai memorizzando punti di dati effettivi, causerà solo dolore (in termini di codice e prestazioni) in quanto non è una complicazione inutile. Se si tratta di un valore che verrà sempre e solo archiviato come singola unità, aggiornato come singola unità e mai smontato all'interno del database, ciò potrebbe andare bene poiché è quasi analogo alla memorizzazione di un'immagine o PDF. Altrimenti, qualsiasi tentativo di analizzare i dati invaliderà utilizzando qualsiasi indice (ad es. Utilizzando LIKE '%something%', o CHARINDEX, o PATINDEX, o SUBSTRING, ecc.).

Se hai bisogno di memorizzare valori separati in un singolo campo di una singola riga, allora ci sono mezzi più appropriati per farlo: XML o JSON. Questi sono formati analizzabili ( XML / JSON ) e XML può anche essere indicizzato . Ma idealmente questi dati verrebbero archiviati in campi correttamente digitati in modo che possano essere veramente utili.

E, per favore, non dimenticare che lo scopo di un RDBMS è di archiviare i dati in modo tale che possano essere recuperati e manipolati nel modo più efficiente possibile, entro i vincoli imposti dalla conformità ACID . Il recupero di valori concatenati è abbastanza grave a causa della necessità di analizzare prima i valori e questo non è indicizzabile. Ma manipolare spesso significa sostituire l'intero BLOB solo per aggiornarne una parte (supponendo che non esista un modello da usare con una REPLACEfunzione). Il tipo di dati XML consente almeno il DML XML per aggiornamenti semplicistici, sebbene questi non siano ancora veloci come un semplice aggiornamento di dati correttamente modellati.

Inoltre, dato uno scenario come quello mostrato nella domanda precedente, concatenando tutti gli StateCodes insieme, non si sarebbe in grado di chiave esterna (in entrambe le direzioni) quei valori.

E se i requisiti aziendali cambiassero nel tempo e fosse necessario tenere traccia delle proprietà aggiuntive di questi articoli? In termini di "stati", che dire delle capitali, della popolazione, di un ordinamento o di qualcos'altro? Memorizzato correttamente come righe è possibile aggiungere più colonne per proprietà aggiuntive. Certo, puoi avere più livelli di dati analizzabili, come |StateCode,Capital,Population |StateCode,Capital,Populate|...ma spero che chiunque possa vedere il problema crescere esponenzialmente senza controllo. Naturalmente, questo particolare problema è piuttosto facilmente risolto con i formati XML e JSON, e questo è il loro valore come menzionato sopra. Ma si sarebbe ancora bisogno di una molto buona ragione per utilizzare uno di questi come un mezzo iniziali di modellazione in quanto né potrà mai essere il più efficiente utilizzando i campi discreti in file separati.

In realtà ho usato qualcosa del genere per uno scopo molto limitato. Abbiamo creato una tabella di intestazioni per i file di output. Sono stati appositamente costruiti e per lo più erano solo le intestazioni di colonna ma non del tutto. Quindi i dati sembravano qualcosa del genere

OutputType   OutputHeader
PersonalData Name|Address|City|State|Zip
JobInfo      Name|JobName|JobTitle

In sostanza sembrava che fosse un elenco delimitato. E in un certo senso lo era. Ma per i nostri scopi era un'unica lunga stringa.

Questo è il trucco qui. Se non hai mai intenzione di analizzare l'elenco, vale la pena salvarlo. Se tuttavia è necessario o addirittura necessario analizzare l'elenco, vale la pena dedicare spazio e tempo extra per suddividerlo e salvarlo in righe separate.

L'ho usato una volta con un tavolo piuttosto piccolo, ad esempio:

CREATE TABLE t1 (
  ID number,
  some_feature   varchar2(100),
  valid_channels  varchar2(100));

CREATE TABLE channel_def (
  channel varchar2(100));

E quindi archiviare i valori CRM,SMS,SELF-CAREin valid_channel.

L'intera tabella ha qualcosa come 10 record. valid_channelcontiene valori che dovrebbero effettivamente essere in una tabella di collegamento che descrive la relazione molti-a-molti. Il tavolo t1non verrà utilizzato intensamente, quindi abbiamo appena deciso di percorrere questa strada. Alcuni politici sono stati coinvolti in questa decisione, però (vedi sotto).

Ma in generale lo evito, non è 3NF.

Il posto in cui lavoro attualmente ha dozzine di tali colonne dappertutto. La loro giustificazione è che semplifica le loro query: invece di unire tre tabelle usando la tabella di collegamento possono usare direttamente la tabella di definizione LIKE. Per esempio

SELECT * 
  FROM t1 
 INNER JOIN channel_def cd
    ON ','||t1.valid_channels||',' LIKE '%,'||cd.channel||',%';

Horrible + su Oracle disabilita l'uso dell'indice a causa dell'avvio '%,'.

Questo è stato fatto qui su SE. Come scrive Marc Gravell :

... Dopo qualche riflessione e considerazione, abbiamo optato per una rappresentazione naturale delimitata da pipe (bar), con pipe iniziali / finali, quindi “.net c #” diventa semplicemente “| .net | c # |”. Questo ha delle virtù:

• molto semplice da analizzare
• l'aggiornamento in blocco e la rimozione dei tag possono essere effettuati con una semplice sostituzione (inclusi i tubi, per evitare la sostituzione di corrispondenze a metà tag)
• ...

Questo "nuovo formato" è stato il passo successivo rispetto al "vecchio formato" che era un po 'diverso ed è stato scelto per utilizzare la funzionalità di ricerca full-text di SQL Server, quindi alcuni dei vantaggi non sono rilevanti se lo si fa da zero.

Presumibilmente non hanno completamente normalizzato la cosa sia per la quantità di lavoro che per le prestazioni.

Bene, un possibile vantaggio principale dell'utilizzo delle stringhe e di altri tipi di dati è l'invio da SQL Server a C #, C, C ++ (ecc.) Utilizzando SQLCLR quando potrebbero essere necessarie prestazioni eccezionali. Potresti persino creare una vista o una procedura memorizzata per rappresentare i dati relazionali in modo non relazionale, come hai fatto nell'esempio sopra per questo scopo.

Vedi questo esempio:

http://aboutsqlserver.com/2013/07/22/clr-vs-t-sql-performance-considerations/

per Wikipedia: SQL CLR o SQLCLR (SQL Common Language Runtime) è la tecnologia per l'hosting del motore di runtime di linguaggio comune Microsoft .NET all'interno di SQL Server. SQLCLR consente al codice gestito di essere ospitato ed eseguito nell'ambiente Microsoft SQL Server.

A mio avviso, la risposta sarebbe no. Non ho usato questo approccio e lo eviterei: non riesco a pensare a un motivo per cui seguirei questa strada. Ti stai inclinando verso il mondo di JSON / NoSQL con un array.

Avevamo scelte di progettazione simili in un ruolo precedente in base al quale il team di architetti voleva avere un campo "Dati" che era stato delimitato e quindi convertito in binario. Alla fine non abbiamo seguito questa strada per alcuni motivi.

Se dovessi unirti a questo tipo di dati, sarebbe una brutta esperienza. Anche l'aggiornamento di singoli elementi della stringa sarebbe sgradevole.