Чи має сенс НЕ конденсувати відносини один до одного?

Якщо у нас є Таблиця А, яка має стосунки один до одного з Таблицею В, чи є коли-небудь сенс їх відставати? Або ніколи не шкода поєднувати їх в єдиний стіл? Чи впливає будь-який із цих сценаріїв (дві таблиці проти однієї комбінованої таблиці) щодо його нормальної форми (1NF, 2NF, 3NF тощо)?

Так, є багато причин, чому це може бути кращий дизайн.

У вас можуть бути відносини успадкування / розширення, наприклад, у вас може бути Userтаблиця, а потім Administratorтаблиця, яка містить більше полів. Обидві таблиці можуть мати первинний ключ User ID (і тому вони мають відношення 1: 1), але не всі користувачі матимуть запис у Administratorтаблиці. Вам знадобиться щось подібне, якщо ви підтримуєте робочий процес, наприклад ScheduledTaskтаблицю та CompletedTaskстіл.

Ви можете мати полегшену таблицю для часто використовуваних даних, Userа потім більшу таблицю для деталей, які вам не дуже потрібні UserDetails. Це може підвищити продуктивність, оскільки ви зможете помістити більше записів на одну сторінку даних.

Ви можете вимагати різних дозволів до таблиць, наприклад, UserтаUserCredentials

Ви можете захотіти різних стратегій резервного копіювання, і тому розмістіть дві таблиці на різних розділах, наприклад, TransactionтаTransactionArchive

Вам може знадобитися більше стовпців, ніж може бути підтримано в одній таблиці, наприклад, якщо є велика кількість великих текстових стовпців, які потрібно мати змогу проіндексувати, а ваша платформа БД обмежена сторінками даних 4K або що-то вам більше.

Додаючи до чудової відповіді @ john-wu ще одну, ще одна причина - коли у вас є стовпець типу BLOB, як малюнок.

Ви хочете, щоб цей стовпець BLOB був в окремій таблиці, не тільки для запитів на таблиці користувачів швидше, але й тому, що ви могли перемістити таблицю, що містить крапку, в іншу область таблиць на дешевшій і повільнішій пам’яті, зберігаючи найбільш запитувані дані в основний простір таблиць на більш швидкому сховищі.

Відносини один на один справді мають сенс лише тоді, коли ви хочете, щоб відповідна запис у Таблиці B був необов'язковим.

Іноді те, що потрібно, - це варіант запису або Tagged Union . Це означає, що у вас є кілька таблиць, що містять різну інформацію, але всі, що відносяться до Таблиці А, стосуються один на один. Потім ви вибираєте, яку таблицю пов’язати на основі поля в таблиці А

Наприклад:

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;

У бізнес-моделюванні два об'єкти A і B, які логічно відокремлені від бізнес-точки зору, зазвичай відображають в різні таблиці.

Наприклад, під час моделювання бізнесу за допомогою об'єктно-орієнтованих засобів зазвичай у вас є якесь об’єктно-реляційне відображення. Ви можете почати з об'єктної моделі і вивести з цього свою реляційну модель. Тож уявіть, що у вашій об'єктній моделі ви створили класи A і B, які, хоч і об'єкти мають відповідність 1: 1, повинні залишатися відокремленими через єдиний принцип відповідальності . Зауважте, що у вашій об'єктній моделі ці класи не є просто таблицями з атрибутами, вони можуть представляти бізнес-об'єкти з деякою поведінкою, реалізованою в методах. І коли ви зараз перерахуєте ці класи прямо на реляційну модель, ви отримаєте окремі таблиці A і B із співвідношенням 1: 1.

На мій досвід, під час створення моделі даних про бізнес або OO, це логічне розмежування набагато більш характерне для відносин 1: 1, ніж "фізичні" причини, такі як продуктивність, індивідуальна безпека або розділення.