Существует ли когда-нибудь время, где с помощью базы данных 1:1 отношения имеют смысл?

Я окончательно определил, что эта комбинация работает:

{
    "location": "global",
    "properties": {
        "productType": "StandardDomainValidatedSsl",
        "autoRenew": true,
        "distinguishedName":"CN=mysubdomain.mydomain.com"
    }
}

Поле csr, как оказалось, не нужно; один возвращается в результате выполнения этого вызова REST. И это только первый шаг в процессе создания сертификата. На данный момент запрос находится в состоянии ожидания и все еще нуждается в проверке.

157
задан Mike Sherrill 'Cat Recall' 24 February 2018 в 13:55
поделиться

22 ответа

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

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

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

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

156
ответ дан Godeke 23 November 2019 в 21:42
поделиться

Где-нибудь были две доли совершенно независимой сущности непосредственными отношениями. Должно быть много примеров:

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

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

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

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

Так, я попробую еще раз. Это складывается, после небольшого количества размышления, что единственный путь у Вас может быть два отдельных объекта, которые должны (насколько программное обеспечение идет) быть вместе всем временем для них для существования вместе в более высокой классификации. Затем если и только если Вы попадаете в более низкое разложение, вещи и должны быть отдельными, но в более высоком уровне они не могут жить друг без друга. Контекст, затем ключ.

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

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

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

Paul.

-4
ответ дан Paul W Homer 23 November 2019 в 21:42
поделиться

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

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

0
ответ дан Eppz 23 November 2019 в 21:42
поделиться

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

3
ответ дан Ryan Guill 23 November 2019 в 21:42
поделиться

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

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

2
ответ дан JohnFx 23 November 2019 в 21:42
поделиться

Большую часть времени проекты, как думают, 1:1, пока кто-то не спрашивает "хорошо, почему это не может быть 1:many"? Развод с понятиями друг от друга преждевременно сделан в ожидании этого общего сценария. Человек и Адрес не связывают так плотно. У большого количества людей есть несколько адресов. И так далее...

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

4
ответ дан Tom H 23 November 2019 в 21:42
поделиться

При использовании данных с одним из популярных ORMs Вы могли бы хотеть разбить таблицу в несколько таблиц для соответствия Иерархии объектов.

4
ответ дан Jason Punyon 23 November 2019 в 21:42
поделиться

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

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

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

4
ответ дан DevelopingChris 23 November 2019 в 21:42
поделиться

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

6
ответ дан J.T. Grimes 23 November 2019 в 21:42
поделиться

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

8
ответ дан HLGEM 23 November 2019 в 21:42
поделиться

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

, Например, у Вас есть класс Bird и Fish, которого оба наследовали от Животного. В Вашем DB у Вас могла быть таблица 'Animal', которая содержит общие поля класса Животных, и таблица Animal имеет непосредственные отношения с Кормушкой для птиц и непосредственные отношения с таблицей Fish.

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

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

8
ответ дан Frederik Gheysels 23 November 2019 в 21:42
поделиться

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

8
ответ дан eleven81 23 November 2019 в 21:42
поделиться

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

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

9
ответ дан Quassnoi 23 November 2019 в 21:42
поделиться

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

13
ответ дан Tom H 23 November 2019 в 21:42
поделиться

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

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

19
ответ дан Shane Delmore 23 November 2019 в 21:42
поделиться

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

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

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

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

существует уровень нормализации, названной 6 нФ. Правило нормализации для 6 нФ может определенно привести к двум таблицам с тем же первичным ключом. 6 нФ имеют преимущество перед 5 нФ, которые можно полностью избежать ПУСТЫХ УКАЗАТЕЛЕЙ. Это важно для некоторых, но не всех, разработчиков базы данных. Я никогда не потрудился помещать схему в 6 нФ.

В 6 нФ недостающие данные могут быть, представляют опущенной строкой, вместо строки с ПУСТЫМ УКАЗАТЕЛЕМ в некотором столбце.

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

21
ответ дан Walter Mitty 23 November 2019 в 21:42
поделиться

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

42
ответ дан chaos 23 November 2019 в 21:42
поделиться

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

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

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

121
ответ дан kemiller2002 23 November 2019 в 21:42
поделиться

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

0
ответ дан 23 November 2019 в 21:42
поделиться

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

Пока Марио

1
ответ дан 23 November 2019 в 21:42
поделиться

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

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

5
ответ дан 23 November 2019 в 21:42
поделиться

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

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

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

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

2
ответ дан 23 November 2019 в 21:42
поделиться
Другие вопросы по тегам:

Похожие вопросы: