Интернет, компьютеры, софт и прочий Hi-Tech

Поддержка внешних ключей в SQLite

Содержание

1. Общие сведения об ограничениях внешнего ключа
2. Включение поддержки внешних ключей
3. Необходимые и желательные индексы базы данных
4. Продвинутые возможности внешних ключей
   1. Составные внешние ключи
   2. Отложенные внешние ключи
   3. Операции ON DELETE и ON UPDATE
5. Команды CREATE, ALTER и DROP TABLE
6. Допустимые пределы и не поддерживаемые возможности

5. Команды CREATE, ALTER и DROP TABLE

Эта глава описывает особенности выполнения команд CREATE TABLE, ALTER TABLE и DROP TABLE при наличии внешних ключей SQLite.

Команда CREATE TABLE производит одни и те же операции как при включённых внешних ключах, так и при отключённых. Объявление родительского ключа для внешнего ключа не проверяется при создании таблицы.

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

При включённом ограничении внешнего ключа команда ALTER TABLE будет работать со следующими двумя особенностями:

• Невозможно использовать синтаксис ALTER TABLE ... ADD COLUMN для добавления столбца с включённым выражением REFERENCES, кроме случая, когда значением по умолчанию для нового столбца является NULL. Такая попытка вызовет ошибку.
• Если команда ALTER TABLE ... RENAME TO используется для переименования таблицы, которая является родительской таблицей для одного или более внешних ключей, определения внешних ключей будут модифицированы и будут ссылаться на родительскую таблицу с новым именем. Текст декларации CREATE TABLE для каждой дочерней таблицы, хранящийся в таблице «sqlite_master» будет изменён соответственно новому имени родительской таблицы.

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

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

Любые ошибки «foreign key mismatch», случившиеся в ходе выполнения скрытого DELETE, игнорируются.

Рассмотренные расширения действий команд ALTER TABLE и DROP TABLE направлены на то, чтобы при включённых внешних ключах их невозможно было использовать для создания базы данных, содержащей неправильные внешние ключи.

Но есть одно исключение из этого правила. Если родительский ключ не является субъектом PRIMARY KEY или ограничения UNIQUE, объявленных как часть определения родительской таблицы, а являются субъектом ограничения UNIQUE, возникшего при создании индекса командой CREATE INDEX, то дочерняя таблица может быть заполнена без возникновения ошибки «foreign key mismatch».

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

Этого случая можно избежать, если в качестве родительских ключей в схеме базы данных использовать только PRIMARY KEY или ограничения UNIQUE, объявленные как часть определения родительской таблицы, а не внешние индексы UNIQUE.

Перечисленные выше свойства команд DROP TABLE и ALTER TABLE имеют место только при включённой поддержке внешних ключей. Если пользователь считает их нежелательными, то с помощью «PRAGMA foreign_keys» может отключить внешние ключи перед выполнением команд DROP или ALTER TABLE. Разумеется, после того как внешние ключи будут отключены, ничто не помешает пользователю нарушить ограничения внешних ключей и создать внутренние противоречия в базе данных.

6. Допустимые пределы и неподдерживаемые возможности

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

1. Нет поддержки выражения MATCH.

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

   Если указано MATCH SIMPLE, то для дочернего ключа, который содержит одно или несколько значений NULL, соответствующая строка в родительской таблице не требуется. Если указано MATCH FULL и все значения дочернего ключа имеют значение NULL, то для него также не требуется соответствующая строка родительской таблицы. В отличие от предыдущего случая все значения дочернего ключа для этого должны быть NULL.

   Наконец, если внешний ключ декларирован как MATCH PARTIAL и хотя бы одно из значений дочернего ключа есть NULL, то должна существовать хотя бы одна строка в родительской таблице, в которой для каждого не-NULL значения дочернего ключа существуют соответствующие значения родительского ключа.

   SQLite парсит выражение MATCH (т.е. не сообщает об ошибке синтаксиса, если вы его указываете), однако игнорирует его. Все внешние ключи в SQLite обрабатываются так, как если бы были объявлены MATCH SIMPLE.

2. Нет поддержки переключения ограничений между отложенным и немедленным режимами.

   Многие системы позволяют пользователям самостоятельно в режиме реального времени переключать внешние ключи между отложенным и немедленным режимами. Например, в Oracle для этого используется команда SET CONSTRAINT. SQLite этого не поддерживает. В SQLite внешние ключи при создании помечаются как отложенные или немедленные и это не изменяется.

3. Предел рекурсии в применении внешнего ключа.

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

   Установка «PRAGMA recursive_triggers» не влияет на действия внешних ключей. С ее помощью невозможно отключить рекурсивное выполнение действий внешнего ключа.

Перевод: Дмитрий Скоробогатов, 18.09.2011
Оригинальный текст доступен по адресу http://sqlite.org/foreignkeys.html.

Предыдущие публикации:

Последнее редактирование: 2011-09-18 06:01:37

Метки материала: table, sqlite, drop table, поддержка внешних ключей, документация для программиста, по, it, базы данных, софт, sql, программирование, soft, software, разработка по, программное обеспечение, db, информационные технологии, ит, программное обеспечение по

Оставьте, пожалуйста, свой комментарий к публикации

Представиться как

Антибот:

Просьба не постить мусор. Если вы хотите потестить xBB, воспользуйтесь кнопкой предварительного просмотра на панели инструментов xBBEditor-а.