Отношение 1 к 0..1 - в какую сторону должен указывать FK? - PullRequest
Новая
       22

Отношение 1 к 0..1 - в какую сторону должен указывать FK?

4 голосов
/ 12 октября 2011

Скажем, у меня есть таблица клиентов с отношением 1: 0..1 к другой таблице, обычно в таблице клиентов у меня есть NK, обнуляемый, указывающий на другую таблицу.

Однако, скажем, числодополнительные необязательные фрагменты данных, относящиеся к клиенту, растут, и просто ради аргументов число таблиц теперь равно 10. Желательно ли использовать ту же архитектуру, чтобы в таблице клиентов было 10 дополнительных столбцов, все из которых, возможно, будут нулевыми, еслиникакие дополнительные данные не были сохранены или лучше, чтобы FK указывал на таблицу клиентов от ребенка?Эта модель выглядит лучше, поскольку у меня нет тонны пустых столбцов, и я могу постепенно расширять систему, если нужно, просто добавляя новые таблицы и новый столбец FK, указывающий на клиента в новой таблице.Единственным недостатком является то, что кажется (глядя на БД), что вы можете добавить больше строк, нарушая правило отношения 1: 0-1.Однако мое приложение никогда не вставит дополнительную строку.

1-й метод требует, чтобы я добавлял новый столбец в конце таблицы клиентов для каждой новой таблицы, добавленной в систему.

Какой метод лучше всего подходит для этого сценария?

Ответы [ 2 ]

3 голосов
/ 12 октября 2011

Ответ механически получен из идеи функциональной зависимости.

Чтобы значение существовало в одном отношении, это означает, что значение должно существовать в другом.Когда это так, будет ограничение внешнего ключа от зависимой таблицы (первой) к независимой таблице (второй)

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

в SQL: 

CREATE TABLE independent (
    id INTEGER PRIMARY KEY
);

CREATE TABLE dependent (
    independent_id INTEGER UNIQUE NOT NULL FOREIGN KEY REFERENCES independent(id)
);

Как и «один ко многим», «многие» имеют внешний ключ к «одному», ночтобы превратить «много» в «одно», просто сделайте это unique.Обычно удобно выразить все это, сделав столбец внешнего ключа для зависимого отношения первичным ключом для этого отношения: 

CREATE TABLE dependent (
    independent_id INTEGER PRIMARY KEY FOREIGN KEY REFERENCES independent(id)
);

Редактировать : я заметил, что ваш заголовок задает другой вопросчем ваше тело, кажется, спрашивает.Вышеуказанное отвечает названию.

С точки зрения нормализации базы данных, вероятно, предпочтительнее использовать несколько таблиц, как указано выше, в пользу обнуляемых атрибутов.Нули являются своего рода внеплановым способом сказать, что значение определенного атрибута в некотором роде «особенное», но на самом деле не обеспечивает какой-либо конкретной интерпретации того, что это может означать.Нуль manager_id, вероятно, означает что-то совершенно отличное от нуля birthdate, даже если они имеют одинаковую отметку.

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

Тем не менее, существуют некоторые очень реальные практические причины для использования одного или другого.Наиболее очевидная причина производительности связана с космическими затратами на использование одного или другого.Когда обычно используется необязательное значение, дополнительное пространство, используемое внешним ключом и соответствующим индексом, не окупается.Аналогично, если необязательное значение используется редко;это более компактно, чтобы поместить эти значения в другое отношение.Наличие атрибута NULL может занять место в таблице, которое почти никогда не используется.

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

0 голосов
/ 12 октября 2011

Частичный ответ:

Имейте в виду, что разбиение таблицы пополам с отношением 1-1 или 1-0..1 всегда требует дополнительного объединения этих таблиц.

Если вам часто нужно возвращать данные из обеих таблиц вместе, и эти таблицы сильно загружены, лучше иметь «тонны значений NULL» в одной большой таблице.

...