Имеет ли смысл когда-либо НЕ сводить отношения один к одному?

Если у нас есть таблица A, которая имеет отношение один к одному с таблицей B, имеет ли смысл когда-нибудь их разделять? Или никогда не помешает объединить их в один стол? Влияет ли какой-либо из этих сценариев (две таблицы против одной объединенной таблицы) на что-либо относительно его нормальной формы (1NF, 2NF, 3NF и т. Д.)?

Да, есть множество причин, почему это может быть лучшим дизайном.

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

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

Вам могут потребоваться разные разрешения для таблиц, например UserиUserCredentials

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

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

Добавление к отличному ответу @ john-wu другой, еще одна причина, когда у вас есть столбец типа BLOB, как изображение.

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

Отношения один к одному действительно имеют смысл только тогда, когда вы хотите, чтобы связанная запись в таблице B была необязательной.

Иногда то, что вы хотите, это вариант записи или Tagged Union . Это означает, что у вас есть несколько таблиц, содержащих разную информацию, но все они связаны с таблицей А в отношениях один-к-одному. Затем вы выбираете, какую таблицу связать, основываясь на поле в таблице A

Например:

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, чем для «физических» причин, таких как производительность, индивидуальная безопасность или разбиение.