Когда нам нужно использовать отношения 1-к-1 в дизайне базы данных?
Когда нам нужно использовать отношение 1 к 1 при проектировании базы данных? По моему мнению, если две таблицы находятся в отношении 1: 1, их можно объединить в одну таблицу. Это правда?
5 ответов
Вертикальное разбиение для больших таблиц для снижения требований к вводу-выводу и кэш-памяти - отдельные столбцы, которые запрашиваются часто, редко.
Добавление столбца в производственную систему, когда
alter table"слишком дорого".Образец супертипа / подтипа.
Вертикальное разбиение выигрывает от исключения таблиц (объединений) - при условии, что оптимизатор поддерживает его (опять же, чтобы уменьшить количество операций ввода-вывода и кеш) .
Якорное моделирование - похоже на 4, но до 6NF.
Иногда это полезно для блокировки таблицы. Когда вы добавляете столбец в базу данных, вся таблица блокируется, пока не будет полностью перезаписана. Это не оказывает никакого влияния, когда ваша база данных имеет 100 тыс. Строк. Но если у вас 100M строк или 1B строк, это совсем другая история...
Также полезно избегать мертвых строк, которые занимают слишком много места. Если вы используете MVCC и некоторые из ваших столбцов регулярно перезаписываются, иногда имеет смысл поместить их в отдельную таблицу. Можно утверждать, что автоматическая очистка в конечном итоге срабатывает, но ради экономии работы с жестким диском лучше собирать несколько полей int в отдельной таблице, чем целую кучу целых строк, заполненных текстом, varchar(n) и кто знает, что еще.
Последней причиной будет злоупотребление select * в ОРМ. Например, если вы храните изображения или сообщения / статьи в блоге, имеет смысл сохранить поле blob / text в отдельной таблице. Потому что каждый раз, когда он загружается по той или иной причине, ваш ORM будет загружать всю строку. Когда вам нужен только URL-адрес вашего изображения или сообщения, последнее, что вам нужно, это извлечь весь двоичный файл / текст из базы данных; и все же ваша ORM сделает именно это...
Да в общем.
Единственное исключение может быть, если вы хотите по-разному назначать привилегии подмножеству столбцов.
Также учтите, что это верно только тогда, когда требуются обе стороны.
Одной из причин может быть помещение часто используемых данных в одну таблицу и крайне редко используемых данных в другую таблицу. Это будет работать быстрее и сэкономит память.
Но мне пришлось бы сильно изогнуть руку, прежде чем я это сделаю.
«Один-к-одному» является неоднозначным, поскольку он относится к мощности и не уточняет явно, является ли это обязательным участием в отношении (т. е. одним и ровно одним) или необязательным участием (т. е. нулем или единицей).
Если это « точно один к точно одному », на практике вы действительно можете решить объединить оба объекта проекта в одну таблицу, реализующую оба. Такой подход эквивалентен с точки зрения данных, которые он может представлять, и иногда может упростить реализацию. Технические плюсы и минусы хорошо описаны в других ответах. Однако он не полностью эквивалентен первоначальному проекту:
- Разделение интересов между двумя организациями нарушено . Это может иметь некоторые недостатки, например, если концепции, лежащие в основе каждого объекта, могут развиваться по-разному (например, разные приложения отвечают за их обслуживание) или иметь разные требования (например, разрешения).
- С теоретической точки зрения сущности по определению должны иметь свою собственную независимую идентичность, которая реализуется на уровне базы данных с помощью первичного ключа. Слияние привело бы к появлению двух разных потенциальных первичных ключей, один из которых функционально зависит от другого: это не рекомендуется с учетом принципов нормализации. Использование одного и того же первичного ключа для обоих удостоверений легко решает эту проблему, но означает, что сущности больше не имеют независимого удостоверения. Это тонкая смысловая разница, которую можно игнорировать, если преимущества перевешивают неудобства.
Если это любая комбинация, включающая ноль или единицу , вам следует избегать объединения двух сущностей в одну таблицу:
- Технически это возможно, но для этого потребуются атрибуты необязательного объекта, допускающие значение null. Во втором примере выше это будет означать, что все столбцы, кроме первичного ключа, будут иметь значение NULL, что больше не позволит обеспечить согласованность, например, если некоторые из них являются обязательными.
- Разделение их, возможно, является небольшими накладными расходами, поскольку у вас есть еще одна таблица, но на уровне базы данных точно отражает все возможные случаи.