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

162

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

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

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

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

Pulsehead
источник
Так проще разделить базу данных на несколько физических устройств.
Pacerier
И дополнительный вопрос, если это имеет смысл, как это сделать? Рассмотрено здесь и здесь - мой вопрос: как выбрать, какая из 2 таблиц имеет ограничение внешнего ключа? Я думаю, это зависит от того, какой вариант использования вы пытаетесь решить ...
The Red Pea

Ответы:

161

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

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

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

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

Godeke
источник
32
Прекрасным примером этого может быть таблица с файлами. Вы можете (по очевидным причинам) иметь одну таблицу, которая содержит только метаданные файла (имя файла, тип MIME и т. Д.), И другую таблицу с отображением 1: 1, которая содержит фактические данные BLOB-объектов. Это уменьшит накладные расходы при запросе / сортировке файлов в некоторых случаях.
Кевин Пено
2
Да. Это зависит от базы данных (современные дизайны хранят большие двоичные объекты в файловой системе, просто используя правильный тип), и даже при такой поддержке нужно быть осторожным, чтобы исключить столбцы (в SQL явные списки столбцов нормальны, но некоторые ORM хотят перетащить вся запись). Хитрость заключается в том, чтобы знать ваш шаблон использования: если большую часть времени фактические данные игнорируются, я бы использовал таблицу больших двоичных объектов 1: 1. Если большинство обращений являются загрузками данных, я бы использовал собственный механизм хранения.
Годеке
@Ochado Хотя я согласен, что у вас есть много естественных (нефизических) причин для 1: 1, кавата «если у вас нет исторической информации» приводит к тем случаям, в которых я, вероятно, не использовал бы отношение 1: 1 для соблюдение.
Годеке
1
@ Ochado Я думаю, что отношения IS-A - хороший пример. Я стараюсь не пытаться навязывать объектно-ориентированные концепции моим таблицам (вместо этого используя ORM в качестве библиотеки данных), но я встречал случаи, когда меня искушали. Производительность таких систем в масштабе убила те эксперименты все же. Тем не менее, это, вероятно, лучший пример не относящегося к производительности примера.
Годеке
На самом деле IS-A, а также соответствующие сценарии резервирования, скорее всего, останутся 1: 1, даже если сохранятся исторические данные.
Tripartio
125

Одной из причин является эффективность базы данных. Наличие отношения 1: 1 позволяет разделить поля, которые будут затронуты во время блокировки строки / таблицы. Если в таблице A содержится масса обновлений, а в таблице b - тонна операций чтения (или имеется масса обновлений из другого приложения), то блокировка таблицы A не повлияет на то, что происходит в таблице B.

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

Моя запись в блоге об этом.

kemiller2002
источник
47

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

хаос
источник
8
«но соответствующие строки не должны существовать для каждой строки» Тогда это не 1: 1. Вы говорите о 1: 0,1.
1
Да. Не знаю, если ОП проводит различие.
хаос
2
Ну, я бы предположил, что они сделали, потому что 1: 0,1 имеет много применений, включая ваше, но 1: 1 имеет гораздо меньше. И они изо всех сил пытались найти применение, поэтому я бы сказал, что ОП проводит различие.
12
Мое рабочее предположение было противоположным, потому что он перечислил 1: 1, 1: многие и многие: многие, не упоминая 1: 0,1.
хаос
26

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

Обратите внимание на одну важную характеристику реализации базы данных большинства этих примеров: историческая информация об отношении 1: 1 не сохраняется. То есть эти отношения 1: 1 в любой данный момент времени. Если разработчик базы данных хочет записывать изменения участников отношений с течением времени, то отношения становятся 1: M или M: M; они теряют свою природу 1: 1. С этим понял, здесь идет:

  • «Is-A» или отношения супертип / подтип или наследование / классификация: Эта категория относится к тем случаям, когда один объект представляет собой определенный тип другого объекта. Например, может существовать сущность «Сотрудник» с атрибутами, которые применяются ко всем сотрудникам, а затем - разные сущности для указания конкретных типов сотрудников с атрибутами, уникальными для этого типа сотрудника, например, «Доктор», «Бухгалтер», «Пилот» и т. Д. В этой схеме избегается нескольких нулей, поскольку у многих сотрудников не было бы специализированных атрибутов определенного подтипа. Другими примерами в этой категории могут быть Product как супертип, и ManufacturingProduct и MaintenanceSupply как подтипы; Животное как супертип и Собака и Кошка как подтипы; и т.д. Обратите внимание, что всякий раз, когда вы пытаетесь отобразить объектно-ориентированную иерархию наследования в реляционную базу данных (например, в объектно-реляционной модели), это тот тип отношений, который представляет такие сценарии.

  • Отношения «босс» , такие как менеджер, председатель, президент и т. Д., Где организационная единица может иметь только одного начальника, а один человек может быть боссом только одной организационной единицы. Если эти правила применяются, то у вас отношения 1: 1, например, один руководитель отдела, один генеральный директор компании и т. Д. Отношения типа «босс» относятся не только к людям. Такие же отношения возникают, если в качестве штаб-квартиры компании существует только один магазин, или, например, только один город является столицей страны.

  • Некоторые виды ограниченного распределения ресурсов , например, одному сотруднику может быть назначен только один служебный автомобиль за раз (например, один грузовик на водителя грузовика, одно такси на водителя такси и т. Д.). Коллега недавно привел мне этот пример.

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

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

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

Есть два заметных исключения из исторической заметки: во-первых, некоторые отношения изменяются настолько редко, что историческая информация обычно не сохраняется. Например, большинство отношений IS-A (например, тип продукта) являются неизменяемыми; то есть они никогда не могут измениться. Таким образом, исторический рекорд является спорным; они всегда будут реализованы как естественные отношения 1: 1. Во-вторых, магазин отношений резервирование-аренда датируется отдельно, поскольку резервирование и аренда являются независимыми событиями, каждое из которых имеет свои даты. Поскольку у сущностей есть свои собственные даты, а не сами отношения 1: 1, имеющие дату начала, они останутся как отношения 1: 1, даже если сохранена историческая информация.

Tripartio
источник
2
Мне действительно нравится, как вы придерживались первоначального духа вопросов о том, когда такое отношение является правильным, а не когда оно полезно из-за земных причин, таких как физическая природа компьютеров.
user1852503
21

Ваш вопрос может быть истолкован несколькими способами, из-за того, как вы его сформулировали. Ответы показывают это.

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

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

Правила нормализации для 1NF, 2NF и 3NF никогда не требуют разложения (разбиения) таблицы на две таблицы с одинаковым первичным ключом. Я не выяснил, может ли когда-либо поместить схему в BCNF, 4NF или 5NF две таблицы с одинаковыми ключами. Вдобавок ко всему, я собираюсь догадаться, что ответ - нет.

Существует уровень нормализации, называемый 6NF. Правило нормализации для 6NF может определенно привести к двум таблицам с одинаковым первичным ключом. Преимущество 6NF перед 5NF в том, что NULLS можно полностью избежать. Это важно для некоторых, но не для всех разработчиков баз данных. Я никогда не удосужился поместить схему в 6NF.

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

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

Уолтер Митти
источник
19

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

Другой автор прокомментировал, что 1: 1 не нормализуется, я бы не согласился с этим в некоторых ситуациях, особенно подтипов. Скажем, у меня есть таблица сотрудников, и первичным ключом является их SSN (это пример, давайте сохраним дискуссию о том, является ли это хорошим ключом или нет для другого потока). Сотрудники могут быть разных типов, скажем, временными или постоянными, и если они являются постоянными, им нужно заполнить больше полей, например, номер телефона офиса, который должен быть не нулевым, если type = 'Permanent'. В базе данных третьей нормальной формы столбец должен зависеть только от ключа, то есть сотрудника, но на самом деле он зависит от сотрудника и его типа, поэтому соотношение 1: 1 совершенно нормально и желательно в этом случае. Это также предотвращает чрезмерно разреженные таблицы, если у меня есть 10 столбцов, которые обычно заполнены,

Шейн Делмор
источник
1
@ShaneD +1 для реального примера слова. Мне также нравится различие «Только для чтения».
Майкл Райли - AKA Gunny
13

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

Эрик Фанкенбуш
источник
Шутки в сторону? Как правило, не самый лучший способ? Единственный крупнейший поставщик музыки в Интернете хранит, к примеру, MP3 в базе данных.
1
@ Марк, есть несколько вопросов, касающихся лучшего способа хранения изображений, либо в базе данных, либо вне ее, и, как представляется, все согласны с тем, что по большей части файловая система работает быстрее. Я полагаю, если это действительно так, то то же самое можно сказать и о MP3.
Джеймс МакМахон
1
«Как правило, вы хотите, чтобы большой двоичный объект находился в отдельной таблице» - обычно большие двоичные объекты не хранятся в строке (если они превышают определенную длину строки, определенную в БД). BLOB, если они не встроенные, обычно хранятся в виде «указателя» на их физическое местоположение на страницах БД.
Блиспр
1
Можно поспорить, имеет ли смысл хранить большие данные (файлы) в базе данных, некоторые для некоторых против всех имеют веские причины, но +1 для примера 1: 1.
Кевин Пено
Это действительно должен быть свой собственный вопрос, который я хотел бы видеть. С помощью умных людей, которые измеряют время / предварительные требования для разных жестких дисков / ОС / СУБД. Должен быть однозначный ответ на этот вопрос, он не должен быть спорным, если измерен правильно. Кто-нибудь уже сделал это?
Стефан
9

С точки зрения чистой науки, да, они бесполезны.

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

Quassnoi
источник
3
@ Марк Брэйди: нет, это не так, как есть Na2SO4 и KCl. При создании базы данных юниверсов вы должны создать t_atom (id INT, протоны INT, нейтроны INT), t_molecule (id INT, atom_id INT) и сделать соединения. Это отношения один ко многим.
Quassnoi
2
С другой стороны, INT может не хватить, поскольку во Вселенной 10 ^ 78 атомов. Даже два GUID, склеенные вместе, могут содержать только 1/10 атомов. Нам понадобится первичный ключ RAW (40) - на случай, если наша база данных будет расти слишком быстро. Темная материя, вы знаете, о чем-то.
Quassnoi
1
О, так что только теория отношений - это чистая наука. Я не осознавал, что химия не была чистой наукой, пока мы не создали базу данных для нее.
1
@Mark Brady: не могли бы вы просто сказать, с чем вы не согласны? Я не понимаю вашего сарказма, правда :)
Quassnoi
Quassnoi (и Марк Брэди) Вы получили голос за LOL, который вы только что дали мне.
Pulsehead
8

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

eleven81
источник
8

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

Например, у вас есть класс Bird и Fish, которые оба наследуются от Animal. В вашей БД у вас может быть таблица Animal, которая содержит общие поля класса Animal, а таблица Animal имеет отношение один к одному с таблицей Bird и отношение один к одному с рыбой. стол.

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

Вместо этого у вас есть запись в таблице Birds, которая имеет отношение один к одному с записью в таблице Animal.

Фредерик Гейсель
источник
Этот ответ связан с другим вопросом: это вопрос отношения 1: 0-1.
Hibou57
8

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

HLGEM
источник
6

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

JT Grimes
источник
Почему призналась? Считаете ли вы, что новый бренд-шлепок имеет такой же риск, как и изменение существующего стола? Пожалуйста, перечислите вещи, которые ломаются при добавлении новых таблиц. Единственное, о чем я могу думать, - это код, работающий с метаданными, т.е. SELECT * из цикла USER_TABLES <что-то> завершает цикл.
1
Меньше всего что сломается, чем то, что для правильного добавления таблицы 1: 1 требуется больше работы, чем для добавления дополнительного поля. Теперь новая запись означает обновление двух таблиц вместо одной. Удалить запись? Два запроса. Теперь мы поддерживаем больше кода, а не меняем его один раз.
JT Grimes
@ Марк Брэди, строго типизированные наборы данных могут быть адским, когда вы добавляете пару файлов в базу данных. Если у адаптера таблицы в наборе данных много запросов и т. Д., Гораздо проще просто перетащить новую таблицу, и тогда все готово.
Стефан
@ Стефан: Там нет каскадной вставки.
JT Grimes
@ Boofus, ну .. иногда нам приходится использовать клавиатуру и немного программировать на заработанные деньги. ;)
Стефан
5

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

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

nvogel
источник
4

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

Джейсон Пуньон
источник
3
Грустная, грустная причина. Если ORM не может справиться с расхождением между объектной моделью и физическим хранилищем, тогда ... просто грустно.
На самом деле, если я правильно понимаю, это означает реализацию классификации иерархий в реляционной базе данных. Это совершенно законный и естественный случай отношений 1: 1; в этом нет ничего «грустного».
Tripartio
4

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

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

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

DevelopingChris
источник
явление: любой факт или событие, представляющее научный интерес, которое может быть научно описано и / или объяснено. Я не думаю, что вы хотели использовать это слово.
1
Я имел в виду использовать его, в его значении, быть редкой вещью. Обычно для описания выбросов используется явление, хотя его определение определяет вашу потребность исправлять каждое слово в моем посте.
DevelopingChris
@DevelopingChris Я согласен, что 1: 1 - это феномен. За исключением школьной теории, существует очень мало реальных ситуаций.
Майкл Райли - AKA Gunny
4

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

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

Марк Канлас
источник
3

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

Райан Гилл
источник
2

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

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

JohnFx
источник
2

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

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

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

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

Майкл Райли - AKA Gunny
источник
1

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

Пока Марио


источник
1

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

КТА
источник
0

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

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

Eppz
источник
Я не согласен с теорией одной таблицы. Есть моменты, когда отношение SuperType SubType лучше всего выражать отношениями 1: 1.
Майкл Райли - AKA Gunny
1
На самом деле, если бы вы пошли на крайнюю нормализацию, у вас было бы намного больше отношений 1: 1. Ранние формы нормализации, предложенные датой, включали правило, согласно которому ни один столбец не должен разрешать значение NULL. Это означало, что если столбец может иметь значение NULL для таблицы, то он должен находиться в отдельной таблице, а строка добавляется только тогда, когда она оценена. Это правило было в основном отменено, в том числе Коддом.
Том Х
0

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

Скажем, в таблице 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.

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

Hibou57
источник
0

Это не очень удобно в целях безопасности, но есть более эффективные способы проверки безопасности. Представьте, вы создаете ключ, который может открыть только одну дверь. Если ключ может открыть любую другую дверь, вы должны позвонить в будильник. По сути, вы можете иметь «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 - лжец в огненных штанах, который обманул Берна Не. Просто пример.

Лесли Месть
источник
0

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

симбионт
источник
-4

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

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

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

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

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

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

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

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

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

Павел.

Пол У Гомер
источник
У стоматолога есть один пациент? У врача есть только один пациент? На одного супруга только 1: 1, если вы положили одного супруга в один стол, а другого супруга - в другой (я собирался сказать, что мужчины в одном, а женщины в другом. Да ладно)
Марк, вы могли бы просто создать таблицу «Пары», где строки всегда бывают попарно. Но в остальном я согласен с твоей, эм ... напыщенной. : P
JohannesH
Да, я тоже согласен с Марком. :-) (мне разрешено отклонять мой собственный глупый ответ?)
Пол В. Гомер
Да, владение "немотой" доказывает, насколько ты умный. Настоящие трусы удаляют свои глупые ответы ... хорошо, что они не врачи, стирают медицинские записи. На самом деле, это хорошо, что мы не такие; перезагрузка будет плохим лечением.
2
Я всегда полагал, что даже у самого умного человека в мире (кто бы это ни был в это время) все еще есть моменты глупости вымени. Это человеческое проклятие :-) В то время как у моего компьютера есть моменты, близкие к интеллекту.
Пол У Гомер