Есть ли смысл вышеать foreign key для ER когда все запросы на чистом SQL?

Question

[BonBon Slick]

По скольку по стольку джойны и прочее идут на прямую, то есть

SELECT column_name(s)
FROM table1
INNER JOIN table2
ON table1.column_name = table2.column_name;

То есть ли какой смысл вешать foreign key

FOREIGN KEY (PersonID) REFERENCES Persons(PersonID)

ведь как я понимаю это надо для маппинга сущностей в коде когда он есть.
К примеру Doctrine 2 и Entity

class User{
// foreign key post.owner_id on user.id
public $posts;
// foreign key comments.owner_id on user.id
public $comments;
}

Что бы автоматом просто делать джойн
$query->(User::class)->join(Post::class)

Но мне все же интересно будет ли буст к скорости какой или какие иные преимущества?

Comments

[AVKor]

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

Answer 1

[Лентюй]

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

Comments

[BonBon Slick]

То есть выходит все же выборка быстрее будет.
Про целостность, я не встречал артефактов или чего иного как при использовании нативного SQL так и orm
с dbal. Поетому не понятно что может пойти не так.
На счет индекса, его ведь отдельно можно повесить или FK считается уже индексом?

[Лентюй]

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

[Dr. Bacon]

Лентюй, там еще проблема как я и предполагал Есть ли смысл вышеать foreign key для ER когда все запросы на чистом SQL?

Answer 2

[Дмитрий Шицков]

FOREIGN KEY необходим для введения ограничений(CONSTRAINT). Если у вас есть связь между таблицами, стоит их установить.
К примеру, разъяснение в документации к MySQL https://metanit.com/sql/mysql/2.5.php

Comments

[Лентюй]

не всегда стоит. особенно на мускуле

Answer 3

[Dr. Bacon]

FOREIGN KEY как бы из чистого SQL и появился, а кому-то надо почитать основы реляционной БД и что такое нормализация (из вопроса не понятно, может ты там по обычным полям, а не про ключам джойнишь)

Comments

[Лентюй]

и какое отношение внешние ключи имеют к нормализации?

[Dr. Bacon]

Лентюй, из вопроса не понятно, может он там по обычным полям, а не про ключам джойнит

[BonBon Slick]

Dr. Bacon, разве поле не есть ключом? Разница между id и email? Что если PK есть email, а поля id нет?

[Dr. Bacon]

BonBon Slick, "если PK есть email" то всё плохо с нормализаций.

[BonBon Slick]

Dr. Bacon, а если ПК состоит из двух и более полей?

[Dr. Bacon]

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

[BonBon Slick]

Dr. Bacon, мне хотелось бы узнать до того как я столкнусь с ними. Ради этого вопрос и весь сайт.

[Дмитрий Шицков]

BonBon Slick, Действительно, стоит использовать суррогатный id, так id будет гарантированно уникальным.
Плюс числового id - выборка по нему, как правило, значительно быстрее чем по строковому.

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

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

[BonBon Slick]

Дмитрий Шицков, спасибо.