Зачем использовать отношение 1 к 1 в дизайне базы данных?

Question

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

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

Итак, когда вы разрабатываете схему базы данных, как вы учитываете отношения 1 к 1? Какие критерии вы используете, чтобы определить, нужен ли он вам, и каковы преимущества по сравнению с его отсутствием?

Answer 1

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

С другой стороны, могут быть физические соображения для таких "вертикального разделения" или "разбиения строк", особенно если вы знаете, что будете обращаться к некоторым столбцам чаще или в отличие от других, например:

• Возможно, вы захотите кластер или раздел две таблицы «конечных точек» отношения 1: 1 по-разному.
• Если ваша СУБД это позволяет, вы можете разместить их на разных физических дисках (например, более критично для производительности на SSD, а другое - на дешевом HDD).
• Вы измерили влияние на кеширование и хотите убедиться, что «горячие» столбцы хранятся в кеше, а «холодные» столбцы не «загрязняют» его.
• Вам необходимо поведение параллелизма (например, блокировка), которое "уже", чем весь ряд. Это сильно зависит от СУБД.
• Вам нужна разная защита для разных столбцов, но ваша СУБД не поддерживает разрешения на уровне столбцов.
• Триггеры обычно зависят от таблицы. Хотя теоретически вы можете иметь только одну таблицу и триггер игнорирует «неправильную половину» строки, некоторые базы данных могут накладывать дополнительные ограничения на то, что триггер может и не может делать. Например, Oracle не позволяет вам изменять так называемую «мутирующую» таблицу из триггера уровня строки - имея отдельные таблицы, только одна из них может изменяться, поэтому вы все равно можете изменить другую из своего триггера (но есть другие способы обойти это).

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

---

С другой стороны, если вы говорите о «1: 0 или 1» (а не об истинном 1: 1), это совершенно другой вопрос, заслуживающий другого ответа ...

Answer 2

Разделение обязанностей и абстракция таблиц базы данных.

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

РЕДАКТИРОВАТЬ

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

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

Answer 3

Ну, на бумаге нормализованная форма выглядит лучше всего. В реальном мире это обычно компромисс. Большинство крупных систем, которые я знаю, делают компромиссы и не пытаются полностью нормализоваться.

Я попробую привести пример. Если вы находитесь в банковском приложении с 10-миллионной учетной записью, и обычные транзакции будут просто запросом последнего баланса определенного счета. У вас есть таблица A, в которой хранится только эта информация (номер счета, остаток на счете и имя владельца счета).

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

А и В имеют однозначное сопоставление.

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

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

Наличие всех 43 атрибутов в одной таблице кажется естественным и, вероятно, «естественно медленным» и неприемлемым для получения только одного баланса счета.

Answer 4

Имеет смысл использовать 1-1 отношения для моделирования сущности в реальном мире. Таким образом, когда в ваш «мир» добавляется больше сущностей, они также должны иметь отношение только к тем данным, к которым они относятся (и не более).

Это ключевой момент: ваши данные (каждая таблица) должны содержать только достаточно данных, чтобы описать реальную вещь, которую они представляют, и не более. Не должно быть лишних полей, поскольку все имеют смысл в терминах этой «вещи». Это означает, что по всей системе повторяется меньше данных (с проблемами обновления, которые могут привести к этому!), И что вы можете извлекать отдельные данные независимо (например, не нужно разбивать / анализировать строки).

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

Answer 5

Часто люди говорят об отношениях 1: 0..1 и называют это 1: 1.В действительности, типичная СУБД не может поддерживать буквальное отношение 1: 1 в любом случае.

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

A 1: 0..1 очень полезно, когда у вас есть поля, которые будут одинаковыми среди нескольких сущностей / таблиц.Например, поля контактной информации, такие как адрес, номер телефона, адрес электронной почты и т. Д., Которые могут быть общими для сотрудников и клиентов, можно разбить на объект, созданный исключительно для контактной информации.

Таблица контактов будет содержатьобщая информация, такая как адрес и телефон (ы).

Таким образом, таблица сотрудников содержит информацию о сотрудниках, такую ​​как номер сотрудника, дата найма и так далее.Он также будет содержать ссылку на внешний ключ в таблице контактов для контактной информации сотрудника.

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

При этом у каждого сотрудника будет контакт, но не у каждого контакта будет сотрудник.Та же концепция будет применяться к клиентам.

Answer 6

Всего несколько образцов из прошлых проектов:

• таблица TestRequests может иметь только один соответствующий отчет. Но в зависимости от характера запроса, поля в отчете могут быть совершенно разными.
• в банковском проекте, таблица Entities содержит различные виды сущностей: Funds, RealEstateProperties, Companies. Большинство из этих сущностей имеют аналогичные свойства, но Фонды требуют около 120 дополнительных полей, в то время как они представляют только 5% записей.