struttura del database ottimale - tabella 'ampia' con campi vuoti o maggior numero di tavoli?

https://stackoverflow.com/questions/4286698

28-09-2019
|

Domanda

ho bisogno di andare bene in altri dati in un database, e ho una scelta tra la modifica di una tabella esistente (table_existing) o la creazione di nuove tabelle.

Questo è il modo table_existing assomiglia a questo momento:

table_existing
-------------------------
| ID | SP | SV | Field1 |
| .. | WW |  1 | ...... |
| .. | WW |  1 | ...... |
-------------------------

Opzione (A)

table_existing
----------------------------------------------------------------------
| ID | SP | SV | Field1 | Field2 | Field3 | Field4 | Field5 | Field6 |
| .. | XX |  1 | ...... | ...... | ...... | ...... | ...... | ...... |
| .. | YY |  2 | ...... | ...... | ...... | ...... | ...... | ...... |
----------------------------------------------------------------------

Opzione (B)

table_existing would be converted into table_WW_1_data
---------------
| ID | Field1 |
| .. | ...... |
| .. | ...... |
---------------

table_XX_1_data
------------------------
| ID | Field1 | Field2 |
| .. | ...... | ...... |
| .. | ...... | ...... |
------------------------

table_YY_2_data
---------------------------------
| ID | Field1 | Field2 | Field3 |
| .. | ...... | ...... | ...... |
| .. | ...... | ...... | ...... |
---------------------------------

Contesto: La combinazione di SP, SV determinare il "numero" di campi che verranno popolate. Ad esempio, (XX, 1) ha 2 campi. (YY, 2) ha 3 campi.

Se dovessi andare con l'opzione (A) avrei molti valori vuoto / NULL nella tabella "più ampio".

Se vado con l'opzione (B), io sono fondamentalmente la creazione di più tabelle ... uno per "ogni" combinazione di SP, SV - ci sarà forse 4-5 in totale. Ma ogni sarebbero completamente popolato con il giusto numero di campi. table_existing sarebbe cambiata pure.

Qual è la struttura del database più ottimale dal punto di vista della velocità? Penso che dal punto manutenibilità di vista, Opzione (B) potrebbe essere migliore.

Edit1

Nessuna delle due opzioni saranno le / tabelle utilizzate di frequente più critici nella mia applicazione.

In opzione (B), dopo che i dati è stato diviso, non ci sarebbe alcun bisogno di unirsi a loro a tutti. Se so che ho bisogno di campi per XX_1, mi recherò a quel tavolo.

Sto cercando di capire se ci sono pro e contro per avere una grande tavolo con molti valori inutilizzati vs avendo la stessa spaccatura dati attraverso più il numero di tabelle. Fare il maggior numero di tavoli portare ad un calo di prestazioni nel database (che abbiamo ~ 80 tavoli già)?

Soluzione

Qual è la struttura più ottimale database dal punto di vista della velocità?

Bene, ciò che è corretto, le migliori pratiche, ecc, si chiama normalizzazione. Se lo fai correttamente, non ci saranno colonne opzionali (non campi), non Null. Le colonne opzionali saranno in una tabella separata, con meno righe. Certo, è possibile organizzare le tabelle in modo che siano insiemi di colonne opzionali, piuttosto che (uno PK plus) una colonna ciascuna.

Combinando le righe delle sotto-tabelle in una 5NF riga è facile, farlo vista ia (ma non aggiornare tramite la visualizzazione, farlo direttamente a ciascuna sotto-tavolo, tramite un transazionale proc memorizzato).

More, tavoli più piccoli, sono la natura di un database relazionale normalizzato. Abituarsi ad esso. Meno, tavoli più grandi sono più lenti, a causa della mancanza di normalizzazione, duplicati e Null. Partecipare è ingombrante in SQL

che risulta essere prestazioni ottimali re, non è una sorpresa. Per due motivi:

I tavoli sono più strette, quindi non ci sono più righe per pagina, si ottiene di più righe per I / O fisici, e più righe nello stesso spazio della cache.
Dal momento che hai No Null, le colonne sono fissi len, non disimballaggio per estrarre il contenuto della colonna.

Non ci sono professionisti per tabelle di grandi dimensioni con molte colonne opzionali (null), unici lati negativi. Non c'è mai è un pro per violazione norme.

La risposta è invariato indipendentemente dal fatto che si sta pensando di 4 o 400 nuove tabelle.

Una raccomandazione se siete seriamente in considerazione che molte tabelle: ci si sta muovendo nella direzione della sesta forma normale, senza rendersene conto. Così rendersene conto, e lo fanno formalmente. I 400 tavoli saranno molto meglio controllati. Se si ottiene un professionista per farlo, si normalizzare che, e finiscono per tornare a meno di 100.

Altri suggerimenti

Sono un DBA di SQL Server quindi mi sugggest cosa avrei fatto in SQL Server 2008.

Aggiungere le colonne alla tabella esistente come nullable segna le colonne come SPARSE. Utilizzando il tag sparse non aumenterà l'archiviazione per le colonne aggiuntive nelle pagine da tavolo esistenti e consentono ancora di interrogare le colonne di tipo sparse come colonne. SQL Server memorizza sparse colonne internamente in formato XML che possono anche essere interrogati o visualizzati.

Se ci sono applicazioni legacy che non in grado di gestire la nuova struttura della tabella

rinominare la tabella
Creare una visualizzazione con la struttura della tabella originale e il nome il nome della tabella originale

Se si dispone di una versione che non supporta colonne di tipo sparse costruire una singola tabella figlio per la vostra tabella esistente che collega il bambino al genitore con l'ID della tabella padre. Creare una vista attraverso le due tabelle per presentare i dati.

Sono le query più probabilità di necessità di coniugare le righe fro (XX, 1) set con (YY, 2) insieme ecc ...?

In caso contrario, la divisione in tabelle separate è più veloce, dal momento che le singole tabelle utilizzate per tutte le query sono più strette.

Se si combinano, si potrebbe essere leggermente più lento da quando avresti bisogno di unioni che richiederanno query duplicati contro tabella principale.

Sono d'accordo con DVK che se si opta per (B) si finirà per dover query su diversi tavoli per ottenere tutti i valori originali Field1, per non parlare della complessità di join ecc wouldnt ha senso a meno che la divisione in tabelle separate anche corrispondevano alla separazione in entità diverse.

Sono d'accordo con Paolo in quel tua domanda non può davvero essere risolta senza conoscere i dettagli dei soggetti interessati, nonché le tipologie di query e aggiornamenti si sarà in esecuzione.

Mi ricordo di avere questi dubbi prima.

Dal punto di vista di convalida dei dati, l'opzione (B) risulta essere più favorevole. È possibile inserire vincoli sui campi migliori. Questo è precisamente il motivo per cui si vuole dividere, per esempio, un tavolo users in students, teachers, ecc per far rispettare i vincoli NOT NULL a seconda del ruolo dell'utente.

In generale, avendo un sacco di valori NULL nella tabella è un male per le prestazioni a causa di problemi di indicizzazione.

Come regola generale, a condizione che il numero di tabelle coinvolte nel vostro unisce è 4 o meno, non si deve preoccupare di un calo di prestazioni.

Modifica Se siete preoccupati per il numero di tabelle nel database, vi consiglio di guardare qui .

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow