Можем ли мы объединить две таблицы без отношения первично-внешних ключей?

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

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

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

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

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

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

Ответ 4

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

Давайте притворимся, что группа суперэйнштейновских экспертов разработала нашу базу данных. Наша супер совершенная база данных имеет 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 отношений. Теперь вы вдруг начинаете предполагать необходимость именно для своего сценария. Проще говоря, соединение от A до C или наоборот или от A до F или от B до Z или от того, как наша система растет.

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

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

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

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

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

Ответ 5

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

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

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

соединяться с внешним отношением

Соединение SQL