Зачем использовать отношения «один к одному» при проектировании базы данных?

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

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

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

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

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

См. Также: Когда мне следует использовать отношения "один к одному"?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот несколько примеров из прошлых проектов:

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