UNION, содержащий SELECT * FROM таблица, не будет работать, поскольку структуры таблиц различны - вторая таблица не содержит колонки ISBN.
Использование столбцов времени выполнения в объединениях
Идентификаторы столбцов выходного набора данных задаются в первой спецификации SELECT. Если вы хотите использовать альтернативные имена столбцов, алиасы столбцов могут быть использованы в выходном списке первой спецификации SELECT. Дополнительно, если необходимо, поля, полученные из констант или переменных, могут быть включены в предложение SELECT каждого объединяемого потока. Следующий запрос содержит наиболее удобный список публикаций из наших двух таблиц:
SELECT
ID,
TITLE as PUBLICATION,
'BOOK ' AS PUBLICATION_TYPE,
CAST (AUTHOR_LAST_NAME || ' ' || AUTHOR_FIRST_NAMES AS VARCHAR (50) )
AS AUTHOR_EDITOR,
EDITION AS EDITION_OR_ISSUE,
PUBLICATION_DATE DATE,
PUBLISHER_ID,
CAST(ISBN AS VARCHAR(14)) AS ISBN,
LIST_PRICE
FROM CURRENT_TITLES
WHERE ...
UNION SELECT
ID,
TITLE,
'PERIODICAL',
EDITOR_LAST_NAME || ' , ' || EDITOR_FIRST_NAMES AS AUTHOR_EDITOR,
CAST (AUTHOR_LAST_NAME || ', ' || AUTHOR_FIRST_NAMES AS VARCHAR(50)),
ISSUE_NUMBER,
PUBLICATION_DATE,
PUBLISHER_ID, 'Not applicable',
LIST_PRICE
FROM PERIODICALS
WHERE ...
ORDER BY 2;
Условия поиска и упорядочивания
Обратите внимание в предыдущем примере, что условия поиска возможны в каждой объединяемой спецификации SELECT. Они являются обычными выражениями поиска, которые должны соответствовать объединяемому набору, управляемому текущим выражением SELECT. Не существует способа коррелировать условия поиска в пределах поднаборов.
Допустимо только одно предложение упорядочения, оно должно следовать после всех поднаборов. Синтаксис ORDER BY номер (т. е. упорядочение по номеру столбца) требуется для упорядочения объединяемых наборов.
Реентерабельные запросы UNION
Возможно обращение к реентерабельной технике для создания объединяющего запроса, который извлекает несколько поднаборов из одной таблицы. Алиасы таблиц требуются в предложениях FROM, но ссылки на колонки не обязательно должны быть полностью специфицированы. Возвращаясь к нашей таблице CURRENT_TITLES, предположим, что мы хотим получить список заголовков книг в зависимости от цены. Реентерабельный запрос должен выглядеть приблизительно следующим образом:
SELECT
ID,
TITLE,
CAST ('UNDER $20' AS VARCHAR(IO)) AS RANGE,
CAST (AUTHOR_LAST_NAME || ', ' || AUTHOR_FIRST_NAMES AS VARCHAR (50) )
AS AUTHOR,
EDITION,
LIST_PRICE
FROM CURRENT_TITLES CT1
WHERE LIST_PRICE < 20.00
UNION SELECT
ID,
TITLE,
CAST ('UNDER $40' AS VARCHAR(IO),
CAST (AUTHOR_LAST_NAME || ', ' || AUTHOR_FIRST_NAMES AS VARCHAR(50) ) ,
EDITION,
LIST_PRICE
FROM CURRENT_IITLES CT2
WHERE LIST_PRICE >= 20.00 AND LIST_PRICE < 40.00
UNION SELECT
ID,
TITLE,
CAST ('$40 PLUS' AS VARCHAR(IO) ) ,
CAST (AUTHOR_LAST_NAME || ', ' || AUTHOR_FIRST_NAMES AS VARCHAR(50) ) ,
EDITION,
LIST_PRICE
FROM CURRENT_TITLES CT3
WHERE LIST PRICE >= 40.00;
UNION ALL
Если в процессе создания объединенного набора были сформированы дублированные строки, то поведение по умолчанию - исключение из набора дублированных строк. Для включения дубликатов используйте UNION ALL вместо UNION.
Темы оптимизации: планы запросов и оптимизатор
В этом разделе рассматривается подсистема оптимизатора Firebird и те стратегии, применяемые им для создания планов запроса, которые будут использованы сервером для операторов SELECT и подзапросов во время выполнения. Мы вкратце рассмотрим синтаксис плана запроса, а также некоторые способы передачи ваших собственных планов серверу.
Планы и оптимизатор запросов Firebird
Для выполнения оператора SELECT или условия поиска сервер Firebird преобразует оператор в набор внутренних алгоритмов, называемых оптимизированным запросом. Каждый раз, когда оператор подготавливается для выполнения, оптимизатор вычисляет план поиска.
План запроса создает некий вид дорожной карты, которая сообщает серверу наименее дорогостоящую дорогу для требуемого процесса поиска, сортировки и поиска соответствия запрашиваемому результату. Чем более эффективный план сконструирует оптимизатор, тем быстрее оператор начнет возвращать результаты.
План создается в соответствии с наличием доступных индексов, с тем способом, каким индексы или потоки соединяются или сливаются, а также с методом поиска (методом доступа).