Какая разница в добавлении PK и FK, когда вы все еще можете присоединиться к общей колонке?

Question

Я полностью понимаю необходимость использования PK и FK, но при использовании реляционных баз данных. Но при использовании Mysql из терминала. Какая разница, добавляя PK и FK, когда вы можете присоединиться к общему столбцу?

Если я создаю таблицу

mysql> create table dudes (dude_id int, name varchar(30), age int);
mysql> create table pets (pet_id int, owner_id int, address varchar(30));

вместо этого

mysql> create table dudes (dude_id int primary key, name varchar(30), age int);
mysql> create table pets (pet_id int primary key, owner_id int references(dude_id), address varchar(30));

Я все еще могу правильно присоединиться к каждой таблице и делать все, что нужно. Что еще MySQL делает в фоновом режиме, что облегчает мою жизнь, явно добавляя ссылки PK и FK?

SELECT *
From dudes d
JOIN pets p ON d.dude_id=p.own_id;

Answer 1

На самом деле это очень много. Первичные ключи будут создаваться и индексироваться по этому ключу для ускорения поиска.

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

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

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

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

Answer 2

Время выполнения - это разница между ними.

Давайте предположим следующее

• Поиск по индексу - это двоичный поиск
• парни имеют 1000 строк
• домашние животные имеют 1000 строк

Таблицы без dude_id в качестве первичного ключа произведут 1 000 000 ключевых сравнений, или Декартовой продукт.Это время выполнения O (n ^ 2).

Таблицы с dude_id в качестве первичного ключа произведут 10 000 (1000 x 10 (log base2 из 1000) ключевых сравнений. Это O (n log n) время выполнения.

Если не существует плохого распределения значений dude_id в owner_id (например, если dude_id принадлежит более 50 домашних животных), второй макет должен всегда выигрывать руки.

Answer 3

PK всегда индексируются, поэтому при увеличении таблицы поиск будет на несколько порядков быстрее.FK гарантирует, что если зависимость будет нарушена или не будет выполнена, запрос будет прерывать или управлять управляемой автоматической операцией (CASCADE)

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

Answer 4

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