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

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

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

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

Спасибо!

Ответ 1

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

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

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

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

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

Ответ 2

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

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

ИЗМЕНИТЬ

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

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

Ответ 3

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

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

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

A и B имеют одно к одному отображение.

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

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

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

Ответ 4

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

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

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

Ответ 5

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

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

Ответ 6

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

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

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

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

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

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

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