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

Ответ 1

1 до 0..1

• "1 до 0..1" между супер и подклассами используется как часть стратегии "всех классов в отдельных таблицах" для реализации наследования.

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

от 1 до 1

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

• Другим использованием вертикального разбиения является изменение поведения блокировки: базы данных обычно не могут блокироваться на уровне отдельных полей, а всего целых строк. Разделив строку, вы разрешаете блокировку только на одной из ее половин.

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

• Отдельные таблицы могут обеспечить более подробную защиту.

В большинстве случаев эти соображения неактуальны, поэтому в большинстве случаев вам следует рассмотреть возможность объединения таблиц "1 к 1" в одну таблицу.

Ответ 2

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

Это может обеспечить преимущества в будущем, если отдельные данные также должны быть связаны с каким-либо другим объектом.

Ответ 3

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

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

Если ваша таблица имеет 20 атрибутов, и только 4 из них используются иногда, имеет смысл разбить таблицу на 2 таблицы для проблем с производительностью.

В таких случаях нехорошо иметь все в одной таблице. Кроме того, нелегко иметь дело с таблицей, содержащей 45 столбцов!

Ответ 4

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

Другая причина заключается в том, что вы хотите специализировать концепцию по-разному. Если у вас есть таблица Person и вы хотите добавить концепцию разных типов Person, таких как Employee, Customer, Акционер - каждому из них понадобятся разные наборы данных. Данные, которые схожи между собой, будут находиться в таблице Person, информация специалиста будет указана в конкретных таблицах для Клиента, Акционера, Сотрудника.

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

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

Ответ 5

Мои 2 цента.

Я работаю в месте, где мы все развиваемся в большом приложении, и все это модуль. Например, у нас есть таблица users, и у нас есть модуль, который добавляет детали facebook для пользователя, другой модуль, который добавляет детали Twitter для пользователя. Мы могли бы решить отключить один из этих модулей и удалить все его функции из нашего приложения. В этом случае каждый модуль добавляет свою собственную таблицу с отношениями 1:1 к глобальной таблице users, например:

create table users ( id int primary key, ...);
create table users_fbdata ( id int primary key, ..., constraint users foreighn key ...)
create table users_twdata ( id int primary key, ..., constraint users foreighn key ...)

Ответ 6

не очень часто.

вы можете найти какое-то преимущество, если вам нужно реализовать некоторую защиту - поэтому некоторые пользователи могут видеть некоторые из столбцов (таблица1), но не другие (таблица2)..

конечно, некоторые базы данных (Oracle) позволяют вам выполнять такую ​​защиту в одной и той же таблице, но некоторые другие не могут.

Ответ 7

Вы имеете в виду нормализацию базы данных. Один из примеров, который я могу придумать в приложении, которое я поддерживаю, - это элементы. Приложение позволяет пользователю продавать множество различных типов элементов (то есть InventoryItems, NonInventoryItems, ServiceItems и т.д.). Хотя я мог хранить все поля, необходимые для каждого элемента в одной таблице Items, гораздо проще поддерживать таблицу базового элемента, содержащую поля, общие для всех элементов, а затем разделять таблицы для каждого типа элемента (то есть Inventory, NonInventory, и т.д.), которые содержат поля, специфичные только для этого типа элемента. Затем таблица элементов будет иметь внешний ключ для определенного типа элемента, который он представляет. Связь между конкретными таблицами элементов и базой элементов будет взаимно однозначной.

Ниже приведена статья о нормализации.

http://support.microsoft.com/kb/283878

Ответ 8

Как и во всех вопросах дизайна, ответ "зависит".

Существует несколько соображений:

• насколько велика будет таблица (как по полям, так и по строкам)? Возможно, неудобно размещать имя пользователя, пароль с другими менее часто используемыми данными как с точки зрения обслуживания, так и с точки зрения программирования.

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

• Насколько вы уверены, что отношения будут 1:1? Как указывает Этот вопрос, все может быстро усложниться.

Ответ 9

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

Ответ 10

Обычно я встречаю два общих вида отношений 1:1:

• Связи IS-A, также известные как отношения супертипа/подтипа. Это когда один вид сущности фактически является типом другого объекта (EntityA IS A EntityB). Примеры:

  • Лицо-лицо, с отдельными лицами для Бухгалтера, Инженера, Продавца, в пределах той же компании.
  • Элемент объекта, с отдельными объектами для виджета, RawMaterial, FinishedGood и т.д.
  • Автомобильный объект с отдельными объектами для грузовика, седана и т.д.

  Во всех этих ситуациях объект супертипа (например, Person, Item или Car) будет иметь атрибуты, общие для всех подтипов, а сущности подтипа будут иметь атрибуты, уникальные для каждого подтипа. Первичный ключ подтипа будет таким же, как и у супертипа.

• "Босс". Это когда человек является единственным боссом или менеджером или руководителем организационного подразделения (отдела, компании и т.д.). Когда только один босс разрешен для организационной единицы, тогда существует связь 1:1 между лицом, которое представляет босса и объект организационной единицы.

Ответ 11

В свое время программирования я столкнулся с этим только в одной ситуации. Что происходит, когда между одними и теми же 2 объектами существует связь 1-ко-многим и 1-к-1 ( "Объект А" и "Сущность Б" ).

Когда "Entity A" имеет несколько "Entity B" и "Entity B" имеет только 1 "Entity A", а также "Entity A" имеет только 1 текущий "Entity B", а "Entity B" имеет только 1 "Entity A".

Например, у автомобиля может быть только один текущий драйвер, и Драйвер может управлять только одним автомобилем за раз - так что соотношение между понятиями "Автомобиль и водитель" будет от 1 до 1. - Я взял этот пример из @Стив Фентон отвечает

Если водитель может управлять несколькими автомобилями, просто не в одно и то же время. Таким образом, объекты "Автомобиль и драйвер" являются "один-ко-многим" или "многие-ко-многим". Но если нам нужно знать, кто является текущим драйвером, тогда нам также нужно отношение 1 к 1.

Ответ 12

Во-первых, я думаю, что это вопрос моделирования и определения того, что представляет собой отдельный объект. Предположим, что у вас есть customers с одним и только одним address. Конечно, вы могли бы реализовать все в одной таблице customer, но если в будущем вы разрешите ему иметь два или более адресов, тогда вам нужно будет реорганизовать это (не проблема, но принять осознанное решение).

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

Представьте себе, что у вас есть customers с одним address каждым, но на этот раз необязательно иметь адрес. Конечно, вы можете реализовать это как группу столбцов NULL -able, таких как ZIP,state,street. Но предположим, что, учитывая, что у вас есть адрес, состояние не является обязательным, но ZIP. Как смоделировать это в одной таблице? Вы можете использовать ограничение в таблице customer, но гораздо проще разделить другую таблицу и сделать foreign_key NULLable. Таким образом, ваша модель гораздо более ясна, говоря, что объект address является необязательным и что ZIP является необязательным атрибутом этого объекта.

Ответ 13

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