Есть ли время, когда использование базы данных 1: 1 имеет смысл?

Question

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

Имя: SSN? Я бы их в одной таблице PersonID: AddressID? Опять та же таблица.

Я могу привести миллионы примеров 1: много или много: много (с соответствующими промежуточными таблицами), но никогда не 1: 1.

Я что-то упускаю из виду?

Answer 1

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

Answer 2

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

Answer 3

В SQL невозможно навязать соотношение 1: 1 между двумя таблицами, которое является обязательным для обеих сторон (если только таблицы доступны только для чтения). Для большинства практических целей отношение «1: 1» в SQL действительно означает 1: 0 | 1.

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

Answer 4

Если вы используете данные с одним из популярных ORM, вы можете разбить таблицу на несколько таблиц в соответствии с вашей иерархией объектов.

Answer 5

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

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

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

Answer 6

В большинстве случаев дизайны считаются 1: 1, пока кто-то не спросит «ну, почему это не может быть 1: много»? Отделение понятий друг от друга преждевременно делается в ожидании этого общего сценария. Персона и Адрес не связывают так тесно. У многих людей есть несколько адресов. И так далее ...

Обычно два отдельных объектных пространства подразумевают, что одно или оба могут быть умножены (x: много). Если два объекта были действительно, по-настоящему 1: 1, даже философски, то это скорее отношения между людьми. Эти два «объекта» фактически являются частями одного целого объекта.

Answer 7

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

Answer 8

Лучшая причина, которую я вижу для отношения 1: 1, - это подтип SuperType для проектирования базы данных. Я создал структуру данных Real Estate MLS на основе этой модели. Было пять разных каналов данных; Жилая, Коммерческая, Многосемейная, Гостиницы и Земля.

Я создал свойство SuperType с именем, которое содержало данные, которые были общими для каждого из пяти отдельных каналов данных. Это позволило очень быстро выполнять «простой» поиск по всем типам данных.

Я создаю пять отдельных подтипов, в которых хранятся уникальные элементы данных для каждого из пяти каналов данных. Каждая запись SuperType имела отношение 1: 1 к соответствующей записи SubType.

Если клиент хотел подробного поиска, ему нужно было выбрать тип Super-Sub, например PropertyResidential.

Answer 9

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

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

Answer 10

По моему мнению, отношение 1: 1 отображает наследование классов в СУБД. Существует таблица A, которая содержит общие атрибуты, то есть статус класса partent Каждое унаследованное состояние класса отображается в СУБД с помощью таблицы B с соотношением 1: 1 Таблица, содержащая специализированные атрибуты. Имя таблицы А также содержит поле «тип», которое представляет функциональность «приведения»

Bye Mario