MySQL: руководство профессионала

Паутов Алексей В.

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

в определении view.

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

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

Если инструкция, подготовленная PREPARE, обращается к view, то содержание этого view какждый раз при выполнении инструкции будет точно соответствовать моменту ее подготовки. Это истинно, даже если определение view изменен после того, как инструкция подготовлена, но прежде, чем она выполнена. Пример:

CREATE VIEW v AS SELECT 1;

PREPARE s FROM 'SELECT * FROM v';

ALTER VIEW v AS SELECT 2;

EXECUTE s;

Результат, возвращенный инструкцией EXECUTE, 1, а не 2.

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

CREATE VIEW v AS SELECT 1;

delimiter //

CREATE PROCEDURE p

BEGIN

DECLARE i INT DEFAULT 0;

WHILE i < 5 DO

SELECT * FROM v;

SET i = i + 1;

ALTER VIEW v AS SELECT 2;

END WHILE;

END;

//

delimiter ;

CALL p;

Когда процедура p вызвана, SELECT возвращает 1 каждый раз в цикле, даже при том, что определение view изменено внутри цикла.

Относительно

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

Обновляемые view с подзапросами где-нибудь не в предложении WHERE. Некоторые view, которые имеют подзапросы в списке SELECT, могут быть обновляемыми.

Вы не можете использовать UPDATE, чтобы модифицировать больше, чем одну основную таблицу view, который определен как объединение.

Вы не можете использовать DELETE, чтобы модифицировать view, который определен как объединение.

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

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

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

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

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