Вопрос новичков о внешнем ключе в MySQL.
В w3school это говорит,
FOREIGN KEY в одной таблице указывает на PRIMARY KEY в другой таблице.
И также существует ТО, ГДЕ,
WHERE id = page_id
Таким образом, если я могу использовать, ГДЕ для соединения таблиц, какова основная цель наличия внешнего ключа?
Это не обязательно для запроса, это правда. Он существует по нескольким причинам:
(1), вероятно, является важным из трех. Это называется ссылочной целостностью . Это означает, что если есть значение во внешнем ключе, будет соответствующая запись с этим значением в качестве первичного ключа в родительской таблице.
При этом не все базы данных поддерживают ссылочную целостность (например, таблицы MySQL / MyISAM) и те, которые его не применяют (по соображениям производительности).
The Foreign is used for referential integrity.
See An introduction to foreign keys and referential integrity in MySQL
оператор RESTRICT (WHERE) не имеет ничего общего с ссылочными ограничениями!
цитата из внешнего ключа CJ Date Relational Database Dictionary
Пусть R1 и R2 будут относительными, не обязательно разными, и пусть K будет ключом для R1 . Пусть FK будет подмножеством заголовка R2 , так что существует, возможно, пустая последовательность переименований атрибутов, которая отображает K в K ' (скажем), где K ' и FK содержат точно такие же атрибуты. Тогда FK - это внешний ключ
ссылочная целостность В общих чертах, правило, согласно которому ссылочный кортеж не может существовать, если соответствующий ссылочный кортеж не существует. Точнее, пусть FK будет некоторым внешним ключом в некоторой ссылающейся relvar R2 ; пусть K будет соответствующим ключом в соответствующей ссылочной relvar R1 , и пусть K ' будет производным от K , как описано в ] внешний ключ . Тогда правило ссылочной целостности требует, чтобы никогда не было времени, когда существует значение FK в R2 , которое не является значением K ' для некоторых ( обязательно уникальный) кортеж в R1 в рассматриваемое время. R1 и R2 здесь - ссылочная relvar и ссылочная relvar, соответственно, и ограничение между ними является ссылочным ограничением.
Примеры : В relvar SP, {S #}
и {P #}
- внешние ключи, соответствующие ключам {S #}
и {P #}
в релварах S и P соответственно. Обратите внимание, что ключ в указанной relvar, который соответствует данному внешнему ключу, не обязательно должен быть конкретно первичным ключом.
{S #}
и {P #}
- внешние ключи, соответствующие ключам {S #}
и {P #}
в relvar S и P соответственно. Обратите внимание, что ключ в указанной relvar, который соответствует данному внешнему ключу, не обязательно должен быть конкретно первичным ключом. {S #}
и {P #}
- внешние ключи, соответствующие ключам {S #}
и {P #}
в relvar S и P соответственно. Обратите внимание, что ключ в указанной relvar, который соответствует данному внешнему ключу, не обязательно должен быть конкретно первичным ключом. У меня есть еще одна веская причина добавить ключевые отношения в вашу базу данных. Существуют различные генераторы кода, которые используют эту информацию для создания объектной модели из вашей базы данных. Одним из наиболее широко используемых шаблонов является шаблон ActiveRecord. Без ключевых отношений шаблон ActiveRecord не будет знать, как связаны сущности вашей базы данных, поэтому он будет генерировать гораздо менее полезную объектную модель.
Генерация кода не подходит для каждого программного проекта. Но это полезно для большого количества проектов. Если вы не используете генерацию кода, вы должны сами хотя бы разобраться в этом.
Основная цель предложения WHERE - ограничить количество строк, возвращаемых запросом. См. Синтаксис SELECT .
Отношения первичный / внешний ключ поддерживают ссылочную целостность и при правильном индексировании повышают производительность запросов. (См. Объяснение Пита Оханлона выше и Типы JOIN )
Внешний ключ используется для поддержания ссылочной целостности, а предложение WHERE используется для объединения таблиц в операции SQL, такой как выбор. Предложение where может работать с несколькими таблицами, но оно здесь чисто как фильтр.
Строго говоря, вы можете обойтись без ссылочной целостности, но это не очень хорошая идея. Без ссылочной целостности вы в конечном итоге полагаетесь на то, что ваше клиентское приложение не удалит или не обновит что-то неправильно на одном конце цепочки отношений, что может повлиять на данные, например, изменение значения ключа, чтобы указать на то, чего нет.
Ссылочная целостность - отличный способ гарантировать единообразное хранение связанных данных.
Прежде всего. Хороший вопрос !!
MySql - это РСУБД - реляционная СУБД, поэтому все сущности (таблицы) связаны столбцом.
СОТРУДНИК - EMPID EMPNAME DEPTID
ОТДЕЛ - DEPTID DEPTNAME
DEPTID является внешним ключом в таблице EMPLOYEE и первичный ключ в таблице DEPARTMENT.
Это отношение является воображаемым отношением объектов, просто соображением или своего рода разработкой для структурирования данных таким образом, чтобы их можно было легко получить в будущем. НЕ ФИЗИЧЕСКАЯ СВЯЗЬ (потому что это язык программирования)
Чтобы получить эти данные, нам нужно немного синтаксиса, описанного Создателем SQL.
SELECT * from EMPLOYEE
SELECT * FROM DEPARTMENT
SELECT * FROM EMPLOYEE WHERE DEPTID = 5
Здесь мы создали две воображаемые таблицы для нашего убедителя,
Дисплеи управляются с помощью / Library / Preferences / com.apple.windowserver.plist
файл настроек:
DisplayMainOnInternal
. DisplaySets
содержит список наборов дисплеев. Первый набор используется (факт для проверки). IOFlags
, похоже, указывает, является ли дисплей основным (значение 7) или нет (значение 3). Перед тем, как перейти к сценарию Apple Script, вы можете вручную изменить конфигурацию дисплея и сохраните копию файла /Library/Preferences/com.apple.windowserver.plist
, чтобы изучить его.
SELECT *
FROM Goods
JOIN PriceRange
ON PriceRange.Price =
(
SELECT MAX(Price)
FROM PriceRange
WHERE PriceRange.Price <= Goods.Price
)
Вы не можете связать эти таблицы с отношениями внешнего ключа, но вы можете легко присоединиться к ним.
См. Эту запись в моем блоге для более подробной информации:
The pk- Однако привязка to-pk по-прежнему важна. FOREIGN KEY
может гарантировать вам, что объект, который вы связываете, описывается вашей реляционной моделью.
С дизайном, поддерживаемым FOREIGN 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
.
Подробнее см. В этой статье: