Подтвердить что ты не робот

Зачем мне использовать внешний ключ, если я могу использовать WHERE?

Вопрос новичков о внешнем ключе в MySQL.

В w3school говорится:

ИНОСТРАННЫЙ КЛЮЧ в одной таблице указывает на PRIMARY KEY в другой таблице.

А также есть WHERE,

WHERE id = page_id

Итак, если я могу использовать WHERE для связывания таблиц, какова основная цель иметь внешний ключ?

4b9b3361

Ответ 1

Это не строго необходимо для запроса, это правда. Он существует по нескольким причинам:

  • Как ограничение на таблицу, чтобы остановить вас, вставляя что-то, что не указывает на что-либо;
  • В качестве подсказки для оптимизатора; и
  • По историческим причинам, когда это было более необходимо.

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

Тем не менее, не все базы данных поддерживают ссылочную целостность (например, таблицы MySQL/MyISAM), а те, которые это делают, не обязательно применяют ее (по соображениям производительности).

Ответ 3

Итак, если я могу использовать WHERE для связывания таблиц, какова основная цель иметь внешний ключ?

Потому что предложение WHERE не ограничено equijoins на внешних ключах.

Скажем, если у вас есть таблица, которая описывает диапазоны цен и скидки, вы используете это сложное условие для объединения таблиц:

SELECT  *
FROM    Goods
JOIN    PriceRange
ON      PriceRange.Price =
        (
        SELECT  MAX(Price)
        FROM    PriceRange
        WHERE   PriceRange.Price <= Goods.Price
        )

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

Смотрите эту запись в моем блоге для более подробной информации:

Однако привязка pk-to-pk по-прежнему важна. A FOREIGN KEY может заверить вас, что связанная вами связь описывается вашей реляционной моделью.

С конструкцией FOREIGN KEY -backed вы не можете объявить связь с объектом, чей PRIMARY KEY отсутствует в таблице, описывающей этот объект.

SQL Server может даже учитывать этот факт и оптимизировать определенные типы запросов.

Скажем, этот запрос:

SELECT  f.*
FROM    t_foreign f
WHERE   f.pid IN
        (
        SELECT  id
        FROM    t_primary p
        )

даже не рассмотрит t_primary, если отношение FOREIGN KEY определено между t_foreign и t_primary.

См. эту статью для более подробной информации:

Ответ 5

Основная цель предложения WHERE - ограничить строки, возвращаемые запросом. См. Синтаксис SELECT.

Связи первичного ключа/внешнего ключа поддерживают ссылочную целостность и с надлежащим индексированием увеличивают производительность запросов. (См. Объяснение Пита Оханлона выше и JOIN Types)

Ответ 6

оператор RESTRICT (WHERE) не имеет никакого отношения к реляционным ограничениям!

цитата из C. J. Дата Словарь реляционных баз данных

внешний ключ. Пусть R1 и R2 являются relvars, не обязательно различающимися, и пусть K является ключом для R1. Пусть FK - подмножество заголовка R2 так, что существует, возможно, пустая последовательность переименований атрибутов, которая отображает K в K '(скажем), где K' и FK содержат точно такие же атрибуты. Тогда FK является внешним ключом

ссылочная целостность. Понятно, что правило, согласно которому ни один ссылочный кортеж не может существовать, если соответствующий ссылочный кортеж не существует. Точнее, пусть FK - некоторый внешний ключ в некотором ссылочном relvar R2; пусть K - соответствующий ключ в соответствующем ссылочном relvar R1, а K '- из K, как описано в внешнем ключе. Тогда правило ссылочной целостности требует, чтобы никогда не было времени, при котором в R2 существует значение FK, которое не является значением K для некоторого (обязательно уникального) кортежа в R1 в рассматриваемое время. R1 и R2 здесь являются ссылочным relvar и ссылочным relvar, соответственно, и ограничение между ними является ссылочным ограничением.

Примеры. В relvar SP, {S#} и {P#} находятся внешние ключи, соответствующие клавишам {S#} и {P#} в реверсах S и P соответственно. Обратите внимание, что ключ в ссылочном рельефе, который соответствует данному внешнему ключу, не обязательно должен быть основным ключом.

Ответ 7

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

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

Ответ 8

Внешний ключ используется для поддержания ссылочной целостности, в то время как предложение WHERE используется для объединения таблиц в SQL-операции, например, в select. Предложение where может работать через несколько таблиц, но оно чисто в качестве фильтра.

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

Ссылочная целостность - отличный способ обеспечить совместимость связанных данных.

Ответ 9

Прежде всего. Хороший вопрос!

MySql - СУБД RDBMS - реляционная СУБД, поэтому все сущности (таблицы) связаны столбцом.

EMPLOYEE - EMPID EMPNAME DEPTID

ОТДЕЛ - DEPTID DEPTNAME

DEPTID - это ключ foriegn в таблице EMPLOYEE и первичный ключ в таблице DEPARTMENT.

Это отношение - это воображаемое отношение объектов, просто рассмотрение или вид проектирования для структурирования данных в простой форме для извлечения в будущем. НЕ ФИЗИЧЕСКОЕ ОТНОШЕНИЕ (поскольку его язык программирования)

Чтобы извлечь эти данные, нам нужно немного синтаксиса и описать создателем SQL.

SELECT * от EMPLOYEE

ВЫБЕРИТЕ * ОТ ДЕПАРТАМЕНТА

SELECT * FROM EMPLOYEE WHERE DEPTID = 5

Здесь мы выполнили две таблицы, мнимые для нашего удобства, но для требуемого результата мы использовали этот синтаксис WHERE DEPTID = 5.