Se abbiamo una tabella A che ha una relazione uno a uno con la tabella B, ha mai senso tenerli separati? O non fa mai male combinarli in un unico tavolo? Uno di questi scenari (due tabelle contro una tabella combinata) influisce su qualcosa rispetto alla sua forma normale (1NF, 2NF, 3NF, ecc.)?
Risposte:
Sì, ci sono molte ragioni per cui questo potrebbe essere il design migliore.
Potresti avere una relazione di ereditarietà / estensione, ad esempio potresti avere una Usertabella e quindi una Administratortabella con più campi. Entrambe le tabelle possono avere una chiave primaria di ID utente (e quindi avere una relazione 1: 1) ma non tutti gli utenti avranno un record nella Administratortabella. Avresti bisogno di qualcosa di simile se stai supportando un flusso di lavoro, ad esempio una ScheduledTasktabella e una CompletedTasktabella.
Potresti voler avere una tabella leggera per i dati di uso comune Usere quindi una tabella più grande per i dettagli che non ti servono molto spesso UserDetails. Questo può migliorare le prestazioni perché sarai in grado di adattare più record in una singola pagina di dati.
Potresti volere autorizzazioni diverse per le tabelle, ad es. UserEUserCredentials
Potresti desiderare strategie di backup diverse e quindi inserire due tabelle su partizioni diverse, ad esempio TransactioneTransactionArchive
Potresti aver bisogno di più colonne di quelle che possono essere supportate in una singola tabella, ad esempio se ci sono molte colonne di testo di grandi dimensioni che devi poter indicizzare e la tua piattaforma DB è limitata a pagine di dati 4K o quant'altro.
Aggiungendo alla risposta eccellente di @ john-wu un altro, un altro motivo è quando hai un tipo BLOB di colonna come un'immagine.
Si desidera che quella colonna BLOB in una tabella separata, non solo per le query sulla tabella utente sia più rapida, ma anche perché è possibile spostare la tabella contenente il BLOB in un tablespace diverso su uno spazio di archiviazione più economico e più lento, mantenendo i dati più interrogati nella tablespace principale su una memoria più veloce.
Le relazioni uno a uno hanno davvero senso solo quando si desidera che il record correlato nella Tabella B sia facoltativo.
A volte quello che vuoi è un record di variante o Tagged Union . Ciò significa che hai più tabelle contenenti informazioni diverse, ma tutte relative alla tabella A in relazioni uno a uno. Quindi scegliere quale tabella associare in base a un campo nella Tabella A
Per esempio:
type Transaction(The_Type: PaymentType := Cash) is record
Amount: Integer;
case The_Type is
when Cash =>
Discount: boolean;
when Check =>
CheckNumber: Positive;
when Credit =>
CardNumber: String(1..5);
Expiration: String(1..5);
end case;
end record;
Nella modellazione aziendale, due entità A e B che logicamente sono separate dal punto di vista aziendale in genere vengono mappate su tabelle diverse.
Ad esempio, quando si esegue la modellazione aziendale con mezzi orientati agli oggetti, in genere è in atto un qualche tipo di mappatura relazionale degli oggetti. Potresti iniziare con un modello a oggetti e derivarne il tuo modello relazionale. Quindi immagina nel tuo modello di oggetto di aver creato le classi A e B, che, sebbene gli oggetti abbiano una corrispondenza 1: 1, dovrebbero rimanere separati a causa del principio di responsabilità singola . Nota nel tuo modello a oggetti, queste classi non sono solo tabelle con attributi, potrebbero rappresentare oggetti business, con alcuni comportamenti implementati nei metodi. E quando si mappano quelle classi ora direttamente a un modello relazionale, si ottengono tabelle separate A e B con relazione 1: 1.
Secondo la mia esperienza, quando si crea un modello di dati aziendali o OO, questa separazione logica è molto più tipica per le relazioni 1: 1 rispetto a ragioni "fisiche" come prestazioni, sicurezza individuale o partizionamento.