The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Каталог документации / Раздел "Базы данных, SQL" / Оглавление документа
Глава 11. Ограничения свойств

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

11.1. Ограничения на сохраненные подпрограммы и триггеры

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

Сохраненные подпрограммы не могут содержать произвольные инструкции SQL. Следующие инструкции отвергнуты:

Для сохраненных функций (но не для процедур) следующие дополнительные инструкции или операции отвергнуты:

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

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

CREATE PROCEDURE p (i INT)
BEGIN
  DECLARE i INT DEFAULT 0;
  SELECT i FROM t;
  BEGIN
    DECLARE i INT DEFAULT 1;
    SELECT i FROM t;
  END;
END;

В таких случаях идентификатор неоднозначен, и следующие правила старшинства применяются:

Поведение, что столбцы таблицы не имеют приоритет над переменными, ненормативно.

Использование сохраненных подпрограмм может вызывать проблемы дублирования. Эта проблема рассмотрена далее.

INFORMATION_SCHEMA еще не имеет таблицу PARAMETERS, так что прикладные программы, которым надо собирать стандартную информацию параметров во время выполнения должны использовать методы типа синтаксического анализа вывода инструкций SHOW CREATE.

Не имеется никакой системы отладки сохраненных подпрограмм.

Инструкции CALL не могут быть подготовлены.

Драйверы UNDO не обеспечиваются.

Циклы FOR не обеспечиваются.

Чтобы предотвращать проблемы взаимодействия между потоками сервера, когда пользователь выдает инструкцию, сервер использует кадр подпрограмм и вызывает доступные для выполнения инструкции. То есть, сервер вычисляет список процедур, функций и триггеров, который может использоваться в течение выполнения инструкции, загружает их, и затем продолжает выполнять инструкцию. Это означает, что, в то время как инструкция выполняется, она не будет видеть изменения для подпрограмм, выполняемых другими потоками сервера.

Инструкция RENAME DATABASE не перемещает сохраненные подпрограммы к новому имени схемы.

Для триггеров следующие дополнительные инструкции или операции отвергнуты:

11.2. Ограничения на курсоры сервера

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

В MySQL серверные курсоры осуществлены сквозь временную таблицу. Первоначально это таблица MEMORY, но преобразованная в таблицу MyISAM, если размер достигает значения переменной системы max_heap_table_size. Одно ограничение реализации в том, что для большого набора результатов получение строк через курсор может быть медленным.

Курсоры предназначены пока только для чтения: Вы не можете использовать курсор, чтобы модифицировать строки. А поэтому обновляемые курсоры не обеспечиваются. Следовательно, UPDATE WHERE CURRENT OF и DELETE WHERE CURRENT OF не выполнены.

Курсоры не сохраняются открытыми после передачи.

Курсоры не прокручиваемые.

Курсоры не именованы. Операторный драйвер действует как курсор ID.

Вы можете иметь открытым только один курсор на подготовленную инструкцию. Если Вы нуждаетесь в нескольких курсорах, Вы должны подготовить несколько инструкций.

Вы не можете использовать курсор для инструкции, которая генерирует набор результатов, если инструкция не обеспечивается в подготовленном режиме. Это включает инструкции типа CHECK TABLES, HANDLER READ и SHOW BINLOG EVENTS.

11.3. Ограничения на подзапросы

11.4. Ограничения на Views

Обработка View не оптимизирована:

Подзапросы не могут использоваться в предложении FROM view. Это ограничение будет сниматься в будущем.

Имеется общий принцип, что Вы не можете изменять таблицу и выбирать из той же самой таблицы в подзапросе.

Тот же самый принцип также применяется, если Вы выбираете из view, который выбирает из таблицы, если выбор view из таблицы в подзапросе и view оценены, используя объединяющий алгоритм. Пример:

CREATE VIEW v1 AS SELECT * FROM t2 WHERE EXISTS (SELECT 1 FROM t1 WHERE
       t1.a = t2.a);
UPDATE t1, v2 SET t1.a = 1 WHERE t1.b = v2.b;

Если view оценен, используя временную таблицу, Вы можете выбирать из таблицы в view подзапросом и менятт ту таблицу во внешнем запросе. В этом случае view будет сохранен во временной таблице, и таким образом Вы действительно не выбираете из таблицы в подзапросе и изменяете таблицу в то же самое время. Можно принудительно предписать MySQL использовать алгоритм temptable, определяя ALGORITHM = TEMPTABLE в определении view.

Вы можете использовать DROP TABLE или ALTER TABLE, чтобы удалять или изменять таблицу, которая используется в определении view (это объявляет неверным view), и никакого предупреждения не последует. Ошибка происходит позже, когда view используется.

Определение view заморожено некоторыми инструкциями:

Относительно обновляемых view: полная цель для view состоит в том, что, если любой view является теоретически обновляемым, это должно быть обновляемым и практически. Это включает view, которые имеют UNION в их определении. В настоящее время не все просмотры, которые являются теоретически обновляемыми, таковы на деле (могут модифицироваться). Начальная реализация view была преднамеренно написана этим способом, чтобы стать пригодной для использования, обновляемые view в MySQL будут сделаны настолько быстро, насколько возможно. Многие теоретически обновляемые view могут модифицироваться теперь, но ограничения все еще существуют:

Если пользователю предоставляют базисные привилегии, необходимые, чтобы создавать view (привилегии CREATE VIEW и SELECT), этот пользователь будут не способен вызвать SHOW CREATE VIEW на этом объекте, если пользователю не предоставляют также привилегию SHOW VIEW.

Этот недостаток может привести к проблемам при копировании базы данных с помощью mysqldump, которая может терпеть неудачу из-за недостаточных привилегий. Эта проблема описана в Глюке #22062.

Обход: чтобы администратор вручную предоставил привилегию SHOW VIEW пользователям, которым предоставляется CREATE VIEW, так как MySQL не предоставляет это неявно, когда создан view.

11.5. Ограничения на Join

Максимальное число таблиц, которые могут быть названы в одиночном объединении, составляет 61. Это также применяется к числу таблиц, которые могут быть названы в определении view.




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2021 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру