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

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

t3 t4

Продавец № 1 продает три рубашки

Продавец № 1 уменьшает количество рубашек на три штуки

quantity - 3 WHERE

UPDATE inventory SET quantity Item = shirt

Продавец № 2 продает две рубашки

Продавец № 2 уменьшает количество рубашек на две штуки

UPDATE inventory SET quantity = quantity - 2 WHERE Item = shirt

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

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

UPDATE account SET balance = balance - 100 WHERE name = Bill UPDATE account SET balance = balance + 100 WHERE name = Bob

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

туацией. (По крайней мере теоретически Можно будет определить, какая из транзакций не отработала и повторить ее, но по крайней мере, нет причин волноваться о незавершенности транзакции ) В СУБД MySQL остается возможность проверить состояние транзакций в журнале изменений, но это требует проверки журнала вручную.

Внешние ключи и ссылочная целостность. Внешний ключ позволяет объявить, что ключ одной таблицы связан с ключом другой таблицы, а ссылочная целостность позволяет наложить ограничения на операции над таблицами, имеющими внешний ключ Например, таблица score базы данных sampdb имеет столбец student id, который можно использовать для связывания данных по результатам с результатами из таблицы student. В базах данных, подцерживаюших концепцию внешних ключей, столбец score. student id можно назвать внешним ключом. Это позволит наложить на этот внешний ключ в таблицу score следующее ограничение: в таблицу не может быть добавлен результат учащегося, чей идентификатор отсутствует в таблице student Кроме того, появится возможность сделать удаление каскадного типа, т е. такое удаление, когда при удалении учащегося из таблицы student будут удалены все записи с его результатами из таблицы score.

Внешние ключи обеспечивают целостность данных и достаточную степень удобства работы с базой данных В перечне причин того, почему СУБД MySQL не поддерживает их, можно назвать отрицательное влияние внешних ключей на производительность и процесс поддержки базы данных. (В справочном руководстве по СУБД MySQL приведен полный перечень этих причин.) Обратите внимание, что такой взгляд на внешние ключи несколько отличается от взгляда, который можно найти в различной литературе по базам данных, где внешние ключи называют не иначе как существенные возможности . Разработчики СУБД MySQL не могут согласиться с этим мнением. Например, при очень сложных взаимосвязях между данными разработчик приложения не должен возлагать на себя всей ответственности за реализацию таких зависимостей (даже если это заключается в добавлении нескольких операторов DELETE).

СУБД MySQL не поддерживает внешних ключей, но включение предложения FOREIGN KEY в оператор CREATE TABLE не приводит к ошибке. (Это сделано для переносимости кода SQL из других баз данных в СУБД MySQL.) СУБД MySQL не накладывает офаничений по внешним ключам и не обеспечивает возможностей каскадного удаления.

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

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

DELETE FROM student WHERE student id = 13

Bee записи об учащемся с кодом 13 из таблицы score будут автоматически удалены. В СУБД MySQL этого эффекта можно добиться явным образом, указывая оператор DELETE в таблице score

DELETE FROM student WHERE student id = 13 DELETE FROM score WHERE student id = 13

Ш Хранимые процедуры и триггеры. Хранимая процедура представляет собой SQL-код, хранящийся на сервере. При выполнении ее не надо повторно посылать запрос от клиента и анализировать его синтаксис. Редактирование хранимой процедуры сразу же влияет на все клиентские приложения, использующие ее в своей работе. Триггер активизирует хранимую процедуру в тот момент, когда с таблицей происходит какое-то событие, к примеру, удаление записи. Такая возможность может потребоваться для перегенерирования какого-нибудь сложного отчета, который всегда должен содержать самые актуальные данные. Обработка хранимых процедур будет реализована в следующих версиях СУБД MySQL.

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

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

8-1729