Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ
Шрифт:
SELECT
PL.*,
EMP.LAST_NAME
FROM V_PROJ_LEADERS PL
JOIN EKPLOYEE_PROJECT EP
ON PL.PROJ_ID = EP.PROJ_ID
JOIN EMPLOYEE EMP
ON EP.EMP_NO = EMP.EMP_NO;
PLAN JOIN (EMP NATURAL, EP INDEX (RDB$FOREIGN15) , PL P INDEX (RDB$PRIMARY12) ,
PL E INDEX (RDB$PRIMARY?) )
В этот раз индекс внешнего ключа для столбца EMP_NO таблицы EMPLOYEE_PROJECT (с алиасом EP) используется для выбора имен участников проекта из второго "элемента" - EMPLOYEE. Как и в предыдущем случае, соединение внутри просмотра использует первичный ключ таблицы EMPLOYEE
Если вы решите написать свой план для запроса, который работает с просмотром, вам нужно хорошо знать определение просмотра, понимать индексы и методы доступа.
Если вы определяете просмотр, который является объединением (union) двух или более наборов, просмотр будет вести себя неправильно при использовании в подзапросе в Firebird 1.0.x. Например, следующий запрос приведет к краху сервера:
SELECT 1 FROM Table1 WHERE EXISTS (
SELECT FIELD1 FROM UNION_VIEW WHERE <условия-поиска> )
Эта ошибка была исправлена до релиза версии 1.5.
Другие наследуемые таблицы
В настоящий момент Firebird поддерживает две другие формы наследуемых таблиц: хранимые процедуры выбора и внешние виртуальные таблицы (External Virtual Table, EVT).
Хранимые процедуры выбора
Расширения Firebird PSQL предоставляют синтаксис для определения хранимой процедуры, которая выводит наследуемый набор данных из чего угодно виртуального: из базы данных, контекстных переменных (даже только из входных переменных), из внешних таблиц или из любой их комбинации. Синтаксис SELECT В PSQL и DSQL предоставляет возможность поиска в этих виртуальных таблицах, как если бы они были реальными таблицами.
Выходной набор хранимой процедуры выбора определяется как набор выходных переменных с использованием предложения RETURNS из оператора CREATE PROCEDURE. Выходные данные создаются в результате цикла по набору курсора, определенному в операторе SELECT, В процессе чтения значений указанных столбцов в эти выходные переменные или в объявленные локальные переменные. Внутри цикла возможно выполнение практически любых операций манипулирования данными, включая использование внутренних циклов. Хранимая процедура выбора может быть вызвана из другой хранимой процедуры. Все, что может быть выбрано, вычислено или наследовано, может преобразовываться в выход.
В качестве простой иллюстрации следующее объявление хранимой процедуры содержит цикл, в котором последовательно передаются строки (по одной за раз) в выходной буфер:
CREATE PROCEDURE SHOW_JOBS_FOR_COUNTRY (
COUNTRY VARCHAR(15))
RETURNS ( /* виртуальная таблица */
CODE VARCHAR (11) ,
TITLE VARCHAR(25),
GRADE SMALLINT)
AS
BEGIN
FOR SELECT job_code, job_title, job_grade FROM job
WHERE JOB_CODNTRY = :COUNTRY
INTO :CODE, :TITLE, :GRADE
DO
BEGIN /* начало цикла */
CODE = 'CODE: ' || CODE; /* немного похулиганить с этим значением */
SUSPEND; /* выводит одну строку цикла */
END
END
После компиляции хранимой процедуры она готова к выполнению. Получение набора выполняется с помощью слегка измененного оператора SELECT, который при необходимости может принимать константные аргументы в качестве входных параметров:
SELECT * FROM SHOW_JOBS_FOR_COUNTRY ('England');
CODE TITLE GRADE
CODE: Admin Administrative Assistant 5
CODE: Eng Engineer 4
CODE: Sales Sales Co-ordinator 3
CODE: SRep Sales Representative 4
Подробнее
о создании и использовании хранимых процедур см. в части VII. Хранимые процедуры выбора детально обсуждаются в главе 30.Внешние виртуальные таблицы
Внешняя виртуальная таблица (EVT) является таблицей, которая получает данные от некоторого внешнего источника данных, а не из базы данных. Результаты запроса к EVT трактуются точно тем же образом, что и результаты любого другого запроса, они выглядят точно так же, как если бы они были получены из таблицы базы данных. Это позволяет интегрировать такие внешние данные, как источники данных реального времени, форматированные данные файлов операционной системы, другие базы данных (включая даже не реляционные базы данных), а также любые другие источники табулированных данных.
Firebird реализует внешние виртуальные таблицы с помощью предложения EXTERNAL FILE оператора CREATE TABLE. Внешние данные читаются из текстовых записей фиксированного формата в обычные столбцы данных Firebird.
Внешние таблицы Firebird могут также добавлять записи во внешние виртуальные таблицы.
См. разд. "Использование внешних файлов в качестве таблиц" главы 16.
Следующая часть книги имеет дело с ключевой и малодокументированной темой транзакций. Основной акцент относительно внутренних технических подробностей в следующих трех главах делается на том, что чем лучше вы понимаете, что происходит в процессе взаимодействия множества клиентов и сервера, тем более эффективной, интуитивной и продуктивной может быть разработка ваших приложений.
ЧАСТЬ VI. Транзакции.
ГЛАВА 25. Обзор транзакций Firebird.
В базах данных клиент-сервер, таких как Firebird, клиентское приложение никогда не касается данных, которые физически хранятся в страницах базы данных. Вместо этого клиентские приложения ведут общение с системой управления базой данных - с "сервером" - создавая пакеты запросов и ответов внутри транзакций. Эта часть книги посвящена ключевым концепциям и вопросам управления транзакциями в Firebird.
Система управления данными, которые изменяются множеством одновременно работающих пользователей, является уязвимой со стороны большого количества проблем целостности данных, если будет работать без какого-либо контроля. Перечислим такие проблемы.
* Потеря изменений (lost updates) появляется, когда два пользователя просматривают один и тот же набор, и один пользователь выполняет изменения, за которыми сразу же следуют изменения другого пользователя, перекрывающие работу первого пользователя.
* "Грязное" чтение (dirty read) позволяет одному пользователю видеть изменения, которые у другого пользователя находятся в процессе выполнения, без гарантии того, что изменения другого пользователя являются окончательными.
* Невоспроизводимое чтение (non-reproducible-reads) позволяет одному пользователю непрерывно выбирать строки, которые другие пользователи изменяют или удаляют. Эта проблема зависит от среды. Например, финансовые процессы по концу месяца или инвентаризация будут ошибочными в этих условиях, поскольку приложению продажи билетов нужно содержать все пользовательские представления синхронизированными, чтобы исключить двойные заказы.