Ha mai senso NON condensare le relazioni uno a uno?

Sì, ci sono un sacco di motivi per cui questo potrebbe essere il design migliore.

Potresti avere una relazione di ereditarietà / estensione, ad es. potresti avere una tabella User e quindi una tabella Administrator con più campi. Entrambe le tabelle possono avere una chiave primaria di ID utente (e quindi hanno una relazione 1: 1) ma non tutti gli utenti avranno un record nella tabella Administrator . Avresti bisogno di qualcosa di simile se stai supportando un flusso di lavoro, ad es. una tabella ScheduledTask e una tabella CompletedTask .

Potresti avere una tabella leggera per i dati di uso comune User e 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 richiedere autorizzazioni diverse alle tabelle, ad es. User e UserCredentials

Potresti volere strategie di backup diverse e quindi inserire due tabelle in partizioni diverse, ad es. Transaction e TransactionArchive

Potresti aver bisogno di più colonne di quante possano essere supportate in una singola tabella, ad es. se ci sono molte colonne di testo di grandi dimensioni che è necessario essere in grado di indicizzare e la piattaforma DB è limitata a pagine di dati 4K o whathaveyou.

Aggiungendo alla risposta eccellente l'@ john-wu un altro, un'altra ragione è quando hai un tipo di colonna BLOB come una foto.

Si desidera avere la colonna BLOB in una tabella separata, non solo per le query sulla tabella utente essere più veloce ma anche perché è possibile spostare la tabella contenente il blob in un tablespace diverso su uno storage più economico, più lento, mantenendo il più interrogato dati nel tablespace principale su una memoria più veloce.

Le relazioni uno a uno hanno davvero senso solo quando vuoi che il record correlato nella Tabella B sia opzionale.

A volte ciò che desideri è un record di varianti o Tagged Union . Ciò significa che hai più tabelle contenenti informazioni diverse, ma tutte relative alla Tabella A in relazioni uno-a-uno. Quindi scegli la tabella da associare in base a un campo nella Tabella A

Ad 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 da un punto di vista aziendale generalmente si riferiscono a tabelle diverse.

Ad esempio, quando si fa la modellazione di business con mezzi orientati agli oggetti, di solito si ha una sorta di mappatura relazionale agli oggetti. Potresti iniziare con un modello a oggetti e derivare il tuo modello relazionale da quello. Quindi immagina nel modello a oggetti che hai 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 modello a oggetti, queste classi non sono solo tabelle con attributi, possono rappresentare oggetti di business, con qualche comportamento implementato nei metodi. E quando si mappano queste classi ora direttamente su un modello relazionale, si ottengono tabelle separate A e B con relazione 1: 1.

In base alla mia esperienza, quando creo un modello di dati aziendale o OO, questa separazione logica è molto più tipica per le relazioni 1: 1 che per motivi "fisici" come prestazioni, sicurezza individuale o partizionamento.