Czy kiedykolwiek ma sens NIE zagęszczać relacji jeden do jednego?

Jeśli mamy tabelę A, która ma relację jeden do jednego z tabelą B, czy kiedykolwiek ma sens rozdzielanie ich? Czy też nigdy nie boli łączenie ich w jeden stół? Czy któryś z tych scenariuszy (dwie tabele vs jedna tabela łączona) wpływa na cokolwiek w odniesieniu do jego normalnej postaci (1NF, 2NF, 3NF itp.)?

Tak, istnieje mnóstwo powodów, dla których może to być lepszy projekt.

Możesz mieć relację dziedziczenie / rozszerzenie, np. Możesz mieć Usertabelę, a następnie Administratortabelę, która ma więcej pól. Obie tabele mogą mieć podstawowy klucz identyfikatora użytkownika (a zatem relację 1: 1), ale nie wszyscy użytkownicy będą mieli zapis w Administratortabeli. Potrzebowałbyś czegoś podobnego, jeśli wspierasz przepływ pracy, np. ScheduledTaskStół i CompletedTaskstół.

Możesz mieć lekką tabelę dla często używanych danych, Usera następnie większą tabelę dla szczegółów, których nie potrzebujesz bardzo często UserDetails. Może to poprawić wydajność, ponieważ będziesz mógł zmieścić więcej rekordów na jednej stronie danych.

Możesz chcieć różnych uprawnień do tabel, np. UserIUserCredentials

Możesz chcieć różnych strategii tworzenia kopii zapasowych i dlatego umieść dwie tabele na różnych partycjach, np. TransactionITransactionArchive

Możesz potrzebować więcej kolumn niż jest w stanie obsłużyć w pojedynczej tabeli, np. Jeśli istnieje wiele dużych kolumn tekstowych, które musisz indeksować, a Twoja platforma DB jest ograniczona do stron z danymi 4K lub co chcesz.

Dodając do doskonałej odpowiedzi przez @ john-wu inny, innym powodem jest to, że masz kolumnę typu BLOB, taką jak obrazek.

Chcesz mieć tę kolumnę BLOB w osobnej tabeli, nie tylko by zapytania w tabeli użytkownika były szybsze, ale także dlatego, że możesz przenieść tabelę zawierającą obiekt BLOB do innego obszaru tabel na tańszym, wolniejszym magazynie, zachowując najczęściej wyszukiwane dane w główny obszar tabel na szybszym magazynie.

Relacje jeden do jednego mają sens tylko wtedy, gdy chcesz, aby powiązany rekord w tabeli B był opcjonalny.

Czasami to, czego chcesz, to wariant zapisu lub Tagged Union . Oznacza to, że masz wiele tabel zawierających różne informacje, ale wszystkie odnoszą się z powrotem do tabeli A w relacjach jeden do jednego. Następnie wybierz tabelę do powiązania na podstawie pola w tabeli A.

Na przykład:

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;

W modelowaniu biznesowym dwa podmioty A i B, które są logicznie oddzielone od biznesowego punktu widzenia, zwykle są mapowane na różne tabele.

Na przykład podczas modelowania biznesowego za pomocą środków zorientowanych obiektowo, zwykle istnieje pewne mapowanie obiektowo-relacyjne. Możesz zacząć od modelu obiektowego i na tej podstawie wyprowadzić swój model relacyjny. Wyobraźcie sobie zatem w swoim modelu obiektowym, że stworzyliście klasy A i B, które chociaż obiekty mają zgodność 1: 1, powinny pozostać oddzielone z powodu zasady pojedynczej odpowiedzialności . Uwaga: w modelu obiektowym klasy te nie są tylko tabelami z atrybutami, mogą reprezentować obiekty biznesowe, a niektóre zachowania są zaimplementowane w metodach. A kiedy mapujesz te klasy teraz bezpośrednio na model relacyjny, otrzymujesz osobne tabele A i B z relacją 1: 1.

Z mojego doświadczenia wynika, że ​​podczas tworzenia modelu danych biznesowych lub OO ta logiczna separacja jest o wiele bardziej typowa dla relacji 1: 1 niż z przyczyn „fizycznych”, takich jak wydajność, indywidualne bezpieczeństwo lub partycjonowanie.