La relazione one-to-none one-to-one o one-to-many?

Question

La relazione one-to-none one-to-one o one-to-many?

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

2

Sto lavorando su un progetto di database esistente. Esiste una tabella in cui ogni riga viene creata con solo metà delle colonne popolate (il resto è inizialmente tutto NULL , ad eccezione di una colonna is_populated ) e successivamente un singolo UPDATE per popolare le colonne rimanenti (in genere settimane a un mese dopo). Nessuno dei dati in nessuna delle colonne è destinato a cambiare dopo essere stato popolato (vale a dire quando non sono più NULL ). Anche se il sistema è piuttosto vecchio, sembrano esserci molte più righe non aggiornate rispetto alle righe aggiornate.

Diciamo che inizialmente ci sono 5 colonne popolate e 5% colonneNULL. Dopo il UPDATE vengono popolate tutte e 10 le colonne. Non è consentito che i dati diventino non popolati dopo il primo UPDATE .

Questa è veramente una relazione uno a uno? Se entrambe le metà dei dati sono state inizialmente memorizzate in una singola tabella o dovrebbero essere state divise in due? Ci sono implicazioni negative sulla performance se si fa un LEFT JOIN sulla chiave primaria della prima tabella (che finirebbe per restituire esattamente la stessa struttura) invece di interrogare una singola tabella? Se dovessi creare una struttura simile in futuro dovrei seguire questo disegno o separare i due dubbi?

sql database-design

posta CJ Dennis 08.07.2016 - 02:20

fonte

2 risposte

Leggi altre domande sui tag sql database-design

In un ambiente di integrazione continua, in che modo i team gestiscono bug noti minori? [duplicare] Come posso rintracciare una dipendenza che sta causando un errore X509TrustManager senza avere la fonte?

score 1 · Answer 1

Questa è una relazione opzionale 1 a 1 o una relazione da 1 a (0,1). Una vera relazione di identità sarebbe 1 a (1,1).

Trovo questa notazione utile per capire la scala della relazione. Una relazione uno a molti potrebbe essere da 1 a (0,10), da 1 a (1,5), da 1 a (1, *). La prima cifra è sempre 0 (opzionale) o 1 (obbligatoria) mentre la seconda specifica un limite superiore o illimitato / non specificato.

Una relazione molti a molti risolve in due le relazioni 1 alla tabella di join richiesta.

In genere trovo che non sia utile spostare le colonne opzionali fuori dalla tabella. In questo caso, sono necessarie tutte e 10 le colonne, ma è possibile creare un record senza disporre dell'intero set di dati.

L'unico caso in cui ho visto che le relazioni di identità hanno senso sono le tabelle tipo inventario, dove ci sono dati di tombstone che non cambiano molto e spesso cambiano i conteggi. Anche i diritti di accesso ai dati tombstone sono spesso diversi. Man mano che il sistema si ridimensiona, questo diventa spesso una relazione uno a molti con i conteggi di inventario per ogni posizione. I join vengono creati solo per una delle tabelle con la stessa identità, se i dati richiesti si trovano solo in una delle tabelle.

score 0 · Answer 2

Li lascerei in una sola tabella se è lì dove si trovano ora.

Suddividere la tabella potrebbe avere senso se hai dei campi BLOB che vuoi isolare, ma non lo hai menzionato. Ho visto tabelle come questa (con molte colonne che sono per lo più NULL) con quasi 100 colonne. Sono brutti con cui lavorare, ma dovresti chiedertelo

quanto lavoro ci vorrebbe per rendere questo più pulito?
quanto lavoro ci vorrebbe per riparare tutti i bug introdotti rendendolo più pulito?
quali altre attività non sarebbero state eseguite perché ciò ha avuto la priorità?
gli utenti se ne accorgono o si preoccupano se questo è fatto?
l'azienda sarà disposta a pagare per questo lavoro?
qual è il peggio che può accadere se questo tentativo fallisce?

Come per le altre tue domande:

Is this truly a one-to-one relationship?

Non finché tutte le colonne si trovano nella stessa tabella. Non ci sono termini per questo: sono solo "colonne in un tavolo".

Should both halves of the data be stored in a single table or should they be split into two?

Come indicato sopra, lasciali in pace.

Are there any negative performance implications if doing a LEFT JOIN on the first table's primary key (which would end up returning exactly the same structure) instead of querying a single table?

Per tutti gli scopi pratici, "no" - a meno che tu non abbia un miliardo di righe o stiano girando su una vecchia macchina XP o hai veramente un buon software di cronometraggio. (Tecnicamente c'è una piccola differenza, ma puoi tranquillamente ignorarla)

Un'ultima cosa: il termine "relazione da uno a nulla" non ha senso per me. Sta implicando che una singola riga nella tabella A è garantita NON deve essere correlata a 1 o più righe nella tabella B. Questo è praticamente il caso per due tabelle che non hanno una relazione.