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

Question

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

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

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

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

Answer 1

Это не очень удобно в целях безопасности, но есть более эффективные способы проверки безопасности. Представьте, вы создаете ключ, который может открыть только одну дверь. Если ключ может открыть любую другую дверь, вы должны позвонить в будильник. По сути, вы можете иметь «CitizenTable» и «VotingTable». Гражданин Один голосует за Кандидата Один, который хранится в таблице для голосования. Если гражданин один снова появится в таблице для голосования, то это должно быть тревогой. Будьте советом, это отношение один к одному, потому что мы не ссылаемся на поле кандидата, мы обращаемся к таблице голосования и таблице граждан.

Пример:

 Citizen Table
 id = 1, citizen_name = "EvryBod"
 id = 2, citizen_name = "Lesly"
 id = 3, citizen_name = "Wasserman"

 Candidate Table
 id = 1, citizen_id = 1, candidate_name = "Bern Nie"
 id = 2, citizen_id = 2, candidate_name = "Bern Nie"
 id = 3, citizen_id = 3, candidate_name = "Hill Arry"

Тогда, если мы увидим таблицу голосования так:

 Voting Table
 id = 1, citizen_id = 1, candidate_name = "Bern Nie"
 id = 2, citizen_id = 2, candidate_name = "Bern Nie"
 id = 3, citizen_id = 3, candidate_name = "Hill Arry"
 id = 4, citizen_id = 3, candidate_name = "Hill Arry"
 id = 5, citizen_id = 3, candidate_name = "Hill Arry"

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

Answer 2

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

Answer 3

Возможно, если в вашей базе данных есть какие-то типизированные объекты.

Скажем, в таблице, T1, у вас есть столбцы C1, C2, C3 ... с отношением один к одному. Все нормально, нормализовано. Теперь, скажем, в таблице T2, у вас есть столбцы C1, C2, C3,… (имена могут отличаться, но говорят, что типы и роль одинаковы) с отношением один к одному. Это нормально для T2 по тем же причинам, что и для T1.

В этом случае, однако, я вижу соответствие для отдельной таблицы T3, содержащей C1, C2, C3 ... и отношение один к одному от T1 до T3 и от T2 до T3. Я даже больше подхожу, если существует другая таблица, с которой уже существует от одного до нескольких C1, C2, C3… скажем, из таблицы A в несколько строк в таблице B. Затем вместо T3 вы используете B и отношение один к одному от T1 до B, то же самое для от T2 до B, и все еще то же самое отношение к множеству от A до B.

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

Answer 4

Где бы то ни было, два совершенно независимых субъекта имели отношения один-к-одному. Там должно быть много примеров:

человек <-> стоматолог (его 1: N, значит, это неправильно!)

человек <-> врач (его 1: N, значит, тоже неправильно!)

person <-> spouse (его 1: 0 | 1, так что в основном это неправильно!)

РЕДАКТИРОВАТЬ: Да, это были довольно плохие примеры, особенно если я всегда искал 1: 1, а не 0 или 1 с обеих сторон. Я предполагаю, что мой мозг плохо стрелял: -)

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

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

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

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

Paul.

Answer 5

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

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