Почему требуется отношение первичный-внешний ключ, когда мы можем присоединиться без него? - PullRequest
42 голосов
/ 24 апреля 2011

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

Структура таблиц:

**

table - 'test1'
columns - id,lname,fname,dob
no primary and foreign key and also not unique(without any constraints)

**

**table - 'test2'
columns- id,native_city
again, no relations and no constraints** 

Я все еще могу объединить эти таблицы с одинаковыми столбцами 'id', так что, если нет первичного-внешнего ключа, тогда какой смысл в этом?

Ответы [ 5 ]

58 голосов
/ 24 апреля 2011

Основная причина использования первичных и внешних ключей заключается в обеспечении согласованности данных.

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

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

20 голосов
/ 24 апреля 2011

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

17 голосов
/ 24 апреля 2011

Вам не нужен FK, вы можете объединять произвольные столбцы.

Но наличие внешнего ключа гарантирует, что соединение действительно удастся найти что-то.

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

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

В зависимости от вашей СУБД внешний ключ также может улучшить производительность выбора (но также ухудшает производительность обновлений, вставок и удалений)

6 голосов
/ 04 августа 2014

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

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

TblA 1:M TblB
TblB 1:M TblC

Notice there is no relationship between TblA and TblC

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

В приведенном выше случае структура настолько проста для понимания, что ее легко увидеть, вы можете присоединиться от TblA, к B, и к C, и наоборот, чтобы получить то, что вам нужно. Это также очень смутно выдвигает на первый план некоторые проблемы с этим. Теперь расширьте эту простую цепочку до 10, 20 или 50 отношений. Теперь вдруг вы начинаете предполагать необходимость именно вашего сценария. Проще говоря, соединение от А до С или наоборот, от А до F или от В до Z или что-то еще по мере роста нашей системы.

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

Решение 1. Найдите общую ссылку. Должно быть, если вы учили о причине присоединения А к С. Если это не очевидно, создайте отношения, а затем присоединяйтесь к ним. то есть, чтобы соединиться с A по B через C, должна быть некоторая общность, иначе ваше объединение приведет либо к нулевым результатам, либо к огромному числу, либо к результатам (декартово произведение). Если вы знаете эту общность, просто добавьте необходимые столбцы в A и C и свяжите их напрямую.

Правило отношений - у них просто должна быть причина существования. Ничего более. Если вы можете найти вескую причину для ссылки с А на С, сделайте это. Но вы должны убедиться, что ваша причина не является избыточной (т. Е. Она уже обработана каким-либо другим способом).

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

Это видео является одним из лучших видео, которые я встречал на эту тему. И стоит посмотреть некоторые другие его видео. Я многому у него научился.

2 голосов
/ 21 февраля 2017

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

Для этого вы используете внешнее соединение:

select tablea.code, tablea.name, tableb.location from tablea left outer join 
tableb on tablea.code = tableb.code

соединение с нашим отношением

SQL-соединение

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...