Come conservare i record con struttura variabile?

Question

Come conservare i record con struttura variabile?

#1 da (4 voti)
#2 da (2 voti)
#3 da (0 voti)

4

Abbiamo un vecchio sistema per gestire gli aggiustamenti dell'inventario che verranno rifatti. Esistono diversi tipi di motivi per effettuare una rettifica e ogni tipo richiede dati diversi da riempire. Alcuni richiedono solo il prodotto e la quantità, altri richiedono un ID documento, altri richiedono due prodotti per regolazione e così via.

Ora, nel sistema attuale, i dati sono memorizzati in una struttura di tabelle dei dettagli principali. Sebbene la tabella principale non rappresenti un problema importante, la tabella dei dettagli è stata originariamente progettata con tutti i possibili campi richiesti per i 5 tipi di regolazione originali. Quindi, molti record non usano tutti i campi. Tuttavia, con l'aumentare del numero di tipi di regolazione, è stato difficile adattare i dati richiesti per queste regolazioni alla struttura corrente, utilizzando i campi per uno scopo diverso per il quale sono stati progettati o memorizzando più di 1 valore per campo. Questo è il tipo di design errato che stiamo cercando di evitare con la nuova versione.

Ora, considerando che ci sono attualmente 15 diversi tipi di aggiustamenti e che questo numero può aumentare, quale sarebbe il modo più efficiente per archiviare questi dati in termini di accessibilità e prestazioni di lettura / scrittura? Tenendo presente che la maggior parte dell'elaborazione dei dati sarà effettuata nell'applicazione, abbiamo due possibili approcci:

Per avere i dati principali come "normali" (cioè chiavi primarie e esterne) e il resto dei dati in un campo XML, avendo l'XML i dati richiesti in base al tipo di aggiustamento .
Per avere 1 tabella per tipo di aggiustamento, fai riferimento a tutte queste tabelle alla tabella principale e aggiungi tabelle come richiesto.
Qualsiasi altra opzione che non abbiamo ancora considerato

Il database è SQL Server 2008 RS e l'applicazione sarà su .NET (C #). Abbiamo già alcuni pro e contro per ogni opzione, ma è ancora da decidere se l'accesso al database sarà principalmente tramite EF o Stored Procedure (come il vecchio sistema), e sono consapevole che ogni modo può adattarsi in modo diverso a come i dati è memorizzato.

database-design

posta Josh Part 13.10.2015 - 16:46

fonte

3 risposte

Leggi altre domande sui tag database-design

Determina la gamma di frequenze più simile all'elenco di frequenze in ingresso Quando utilizzare Constructor e quando utilizzare Collection Initializer?

score 4 · Answer 1

Di solito vado con l'approccio a più tavoli.

Potresti scoprire, tuttavia, che in termini di prestazioni di lettura / scrittura il tuo attuale formato a tabella singola ha prestazioni migliori di entrambe le alternative.

Le colonne XML per i dati strutturati in un database relazionale sono, penso, cercando di fare lo stesso lavoro di tabelle e colonne. Prima di proseguire lungo questa rotta, considera i problemi che potresti incontrare quando in futuro dovrai modificare il formato dei dati.

score 2 · Answer 2

Suggerirei di mantenere la tabella principale come descritto e di avere una tabella per ogni tipo di aggiustamento. In mezzo, avere una tabella di collegamento con un FK alla tabella principale e una colonna per il tipo di rettifica e un FK alla chiave primaria su ciascuna tabella di regolazione. Naturalmente, vorrai anche una tabella di metadati per archiviare i tipi di aggiustamento e le loro descrizioni.

ERD

Potresti chiedere perché non puoi semplicemente avere un FK to Master dai tavoli figli. Un punto valido, ma questo design offre l'opportunità di applicare la stessa modifica a più record Master senza introdurre ridondanza.

Ho visto alcune implementazioni simili allo scenario che hai descritto in cui il tipo è omesso nella tabella dei link per motivi di brevità e una serie di tabelle di regolazione PK sono state assegnate per il tipo. Ti consigliamo vivamente di non di farlo, poiché alcuni tipi di aggiustamenti potrebbero superare di gran lunga ciò che avresti previsto.

score 0 · Answer 3

Penso che molto dipenda dal volume di dati previsto. Se hai solo un paio di migliaia di aggiustamenti di inventario all'anno, allora lascia che il LOE di implementazione determini quale metodo usare. Se prevedi un volume più alto, probabilmente otterrai prestazioni migliori andando con tabelle separate (specialmente se devi cercare o generare report su alcuni campi di dati variabili). So che SQL Server ha un supporto integrato per XML nei record del database, ma non sembra supportare le query complesse IIRC e le prestazioni saranno più lente se non si ha lo spazio da dedicare al supporto dell'indice. Suggerisco anche di guardare JSON anziché XML se si stanno memorizzando molti dati nei campi variabili, è molto più semplice da analizzare (anche se si perde la strong tipizzazione dello schema XML).