Когда использовать 1 к 1 отношения между таблицами базы данных?

Единственное время я использовал от 1 до 1 отношения, - когда я хочу, чтобы оно полиморфно принадлежало нескольким объектам.

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

Думайте о том, как Вы разработали бы бизнес-объекты. Вы собираетесь иметь Пользовательский объект с 50 свойствами на нем, или Вы собираетесь иметь Пользовательский объект с несколькими свойствами детали и затем объект Профиля, который содержит другие данные для профиля?

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

, Также это может сделать вещи легче найти. Не много вещей я ненавижу больше, чем необходимость просмотреть таблицу с 75 столбцами.

Классическая причина состоит в том, чтобы избежать nullable столбцов.

Наличие Нулевого значения в столбце может мешать писать ясный (удобный в сопровождении) SQL. Ovid записал об этом здесь , привлекая работу Chris Date .

Только, когда поля в таблице UserProfile не требуются для всего количества записей в пользовательской таблице. Например, если у Вас было 3 000 000 пользователей, но у только 3 000 из тех есть UserProfiles, может иметь смысл разделять их (для предотвращения целого набора пустых столбцов.)

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

Это - прямая копия и вставка от другого вопроса, который открылся сегодня в этом потоке, но это чувствует себя полезным здесь также. там когда-нибудь время, где с помощью базы данных 1:1 отношения имеют смысл?

я использую их, прежде всего, по нескольким причинам. Каждый - существенные изменения в уровне изменения данных. Некоторые мои таблицы могут иметь журналы аудита, где я отслеживаю предыдущие версии записей, если я только хочу отследить предыдущие версии 5 из 10 столбцов, разделяющих те 5 столбцов на отдельную таблицу с механизмом журнала аудита на нем, более эффективно. Кроме того, у меня могут быть записи (скажите для приложения учета), которые только для записи. Вы не можете изменить суммы в долларах или учетную запись, для которой они были, если бы Вы сделали ошибку затем, то необходимо заставить соответствующую запись на запись корректироваться от неправильной записи, затем создать запись исправления. У меня есть ограничения на таблицу, осуществляющую то, что они не могут быть обновлены или удалены, но у меня может быть несколько атрибутов для того объекта, которые покорны, они сохранены в отдельной таблице без ограничения на модификацию. Другое время я делаю это, находится в приложениях медицинской документации. Существуют данные, связанные с посещением, которое не может быть изменено, после того как они закончены на, и другие данные, связанные с посещением, которое может быть изменено после выхода. В этом случае я разделю данные и помещу триггер на заблокированные обновления отклонения таблицы заблокированной таблицы при заканчивании, но позволяющие обновления данных доктор не заканчивают на.

Другой плакат, прокомментированный 1:1 не быть нормализованным, я не согласился бы с этим в некоторых ситуациях, особенно выделив подтипы. Скажите, что у меня есть список сотрудников, и первичный ключ является их SSN (это - пример, давайте сохраним дебаты по тому, является ли это хорошим ключом или не для другого потока). Сотрудники могут иметь различные типы, сказать временный или постоянный и если они являются постоянными у, их есть больше полей, чтобы быть заполненными, как число офисного телефона, которое должно только быть не пустым если тип = 'Постоянный'. В 3-й базе данных нормальной формы столбец должен зависеть только от ключа, означая сотрудника, но это на самом деле зависит от сотрудника, и введите, таким образом, 1:1 отношения совершенно нормальны, и желательны в этом случае. Это также предотвращает чрезмерно редкие таблицы, если у меня есть 10 столбцов, которые обычно заполнены, но 20 дополнительных столбцов только для определенных типов.

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

вторая таблица имела одну треть строк, но в три раза больше столбцов.

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

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

Я думаю, что у Шейна D есть причина, которая вполне обоснована. Поскольку даже я сталкивался с той же ситуацией для таблицы, имеющей около 40 столбцов, данные для этих столбцов загружаются через csvs и используются только для целей отчетности и набора столбцов для обработки этих файлов, которые часто обновляются.

Так что если мы поддерживаем одну таблицу в качестве решения. Мы выполняем частые обновления этой таблицы и будем обновлять только 5 столбцов из 50. Я чувствую, что каждое обновление мешает распределению строк, и существует высокая вероятность объединения строк, поэтому, чтобы избежать объединения строк, я следовал подходу разделения данных на основе DML-активности.

Дайте мне знать, если есть какое-либо лучшее решение