Бази даних-20210115T104840Z-001 / Реферат на тему _Современные СУБД_ / Using_MySql,_MS_SQL_Server_and_Oracle(1)

Пример 12: запросы на объединение и преобразование столбцов в строки

Результат выполнения первой группировки и построчного объединения:

На втором шаге набор данных о каждой книге и её авторах уже позволяет проводить группировку сразу по двум полям — book и author(s), т.к. списки авторов уже подготовлены, и никакая информация о них не будет потеряна:

Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016–2018 Стр: 80/545

Пример 12: запросы на объединение и преобразование столбцов в строки

Задание 2.2.2.TSK.A: показать все книги с их жанрами (дублирование названий книг не допускается).

Задание 2.2.2.TSK.B: показать всех авторов со всеми написанными ими книгами и всеми жанрами, в которых они работали (дублирование имён авторов, названий книг и жанров не допускается).

Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016–2018 Стр: 81/545

Пример 13: запросы на объединение и подзапросы с условием IN

2.2.3.Пример 13: запросы на объединение и подзапросы с условием IN

Очень часто запросы на объединение можно преобразовать в запросы с подзапросом и ключевым словом IN (обратное преобразование тоже возможно). Рассмотрим несколько типичных примеров:

Задача 2.2.3.a{83}: показать список читателей, когда-либо бравших в библиотеке книги (использовать JOIN).

Задача 2.2.3.b{84}: показать список читателей, когда-либо бравших в библиотеке книги (не использовать JOIN).

Задача 2.2.3.c{86}: показать список читателей, никогда не бравших в библиотеке книги (использовать JOIN).

Задача 2.2.3.d{87}: показать список читателей, никогда не бравших в библиотеке книги (не использовать JOIN).

Легко заметить, что пары задач 2.2.3.a-2.2.3.b и 2.2.3.c-2.2.3.d как раз являются предпосылкой к использованию преобразования JOIN в IN.

Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016–2018 Стр: 82/545

Пример 13: запросы на объединение и подзапросы с условием IN

Решение 2.2.3.a{83}.

4JOIN `subscriptions`

5ON `s_id` = `sb_subscriber`

4JOIN [subscriptions]

5ON [s_id] = [sb_subscriber]

4JOIN "subscriptions"

5ON "s_id" = "sb_subscriber"

Для всех трёх СУБД это решение полностью эквивалентно. Важную роль здесь играет ключевое слово DISTINCT, т.к. без него результат будет вот таким (в силу того факта, что JOIN найдёт все случаи выдачи книг каждому из читателей, а нам по условию задачи важен просто факт того, что человек хотя бы раз брал книгу):

Но у DISTINCT есть и опасность. Представьте, что мы решили не извлекать идентификатор читателя, ограничившись его именем (приведём пример только для MySQL, т.к. в MS SQL Server и Oracle ситуация совершенно идентична):

MySQL Решение 2.2.3.a (демонстрация потенциальной проблемы)

3JOIN `subscriptions`

4ON `s_id` = `sb_subscriber`

Запрос вернул следующие данные:

s_name

Иванов И.И.

Сидоров С.С.

Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016–2018 Стр: 83/545

Пример 13: запросы на объединение и подзапросы с условием IN

В правильном ожидаемом результате было три записи (в т.ч. двое Сидоровых с разными идентификаторами). Сейчас же эта информация утеряна.

Решение 2.2.3.b{82}.

MySQL Решение 2.2.3.b

1SELECT `s_id`,

2`s_name`

MS SQL Решение 2.2.3.b

1SELECT [s_id],

2[s_name]

Oracle Решение 2.2.3.b

1SELECT "s_id",

2"s_name"

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

А пока покажем графически, как работают эти два запроса. Начнём с варианта с JOIN. СУБД перебирает значения s_id из таблицы subscribers и проверяет, есть ли в таблице subscriptions записи, поле sb_subscriber которых содержит то же самое значение:

Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016–2018 Стр: 84/545

Пример 13: запросы на объединение и подзапросы с условием IN

В результате поиска совпадений получается следующая картина:

В случае с подзапросом и ключевым словом IN ситуация выглядит иначе. Сначала СУБД выбирает все значения sb_subscriber:

sb_subscriber

1

1

3

1

4

1

3

3

4

1

4

Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016–2018 Стр: 85/545

Пример 13: запросы на объединение и подзапросы с условием IN

Потом происходит устранение дубликатов:

sb_subscriber

1

3

4

Теперь СУБД анализирует каждую строку таблицы subscribers на предмет того, входит ли её значение s_id в этот набор:

Примечание: здесь, расписывая пошагово логику работы СУБД мы для простоты считаем, что устранение дубликатов происходит в самом конце. На самом деле, это не так. Внутренние алгоритмы обработки данных позволяют СУБД выполнять операции дедубликации как после завершения формирования выборки, так и прямо в процессе её формирования. Решение о применении того или иного варианта будет зависеть от конкретной СУБД, используемых методов доступа (storage engine), плана выполнения запроса и иных факторов.

Решение 2.2.3.c{82}.

MySQL Решение 2.2.3.c

1SELECT `s_id`,

2`s_name`

MS SQL Решение 2.2.3.c

1SELECT [s_id],

2[s_name]

Oracle Решение 2.2.3.c

1SELECT "s_id",

2"s_name"

Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016–2018 Стр: 86/545

Пример 13: запросы на объединение и подзапросы с условием IN

При поиске читателей, никогда не бравших книги, логика работы СУБД выглядит так. Сначала выполняется т.н. «левое (внешнее) объединение», т.е. СУБД извлекает все записи из таблицы subscribers и пытается найти им «пару» из таблицы subscriptions. Если «пару» найти не получилось (её нет), вместо значения поля sb_subscriber будет подставлено значение NULL:

Решение 2.2.3.d{82}.

MySQL Решение 2.2.3.d

1SELECT `s_id`,

2`s_name`

MS SQL Решение 2.2.3.d

1SELECT [s_id],

2[s_name]

Oracle Решение 2.2.3.d

1SELECT "s_id",

2"s_name"

Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016–2018 Стр: 87/545

Пример 13: запросы на объединение и подзапросы с условием IN

Здесь поведение СУБД аналогично решению 2.2.3.b за исключением того, что при переборе значений sb_subscriber нужно не обнаружить среди них зна-

чение s_id:

Исследование 2.2.3.EXP.A: оценка влияния DISTINCT в подзапросе на производительность операции.

Настало время поговорить о производительности. Нас будет интересовать два вопроса:

•Влияет ли на производительность наличие DISTINCT в подзапросе (для решений с IN)?

•Что работает быстрее — JOIN или IN (в обоих случаях: когда мы ищем как читателей, бравших книги, так и не бравших)?

Проводить исследование будем на базе данных «Большая библиотека». Выполним по сто раз следующие запросы:

MySQL Исследование 2.2.3.EXP.A

1-- Запрос 1: использование JOIN

2SELECT DISTINCT `s_id`,

5JOIN `subscriptions`

6ON `s_id` = `sb_subscriber`

1-- Запрос 2: использование IN (... DISTINCT ...)

2SELECT `s_id`,

3`s_name`

1-- Запрос 3: использование IN

2SELECT `s_id`,

3`s_name`

1-- Запрос 4: использование LEFT JOIN

2SELECT `s_id`,

3`s_name`

Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016–2018 Стр: 88/545

Пример 13: запросы на объединение и подзапросы с условием IN

MySQL Исследование 2.2.3.EXP.A (продолжение)

1-- Запрос 5: использование NOT IN (... DISTINCT ...)

2SELECT `s_id`,

3`s_name`

1-- Запрос 6: использование NOT IN

2SELECT `s_id`,

3`s_name`

MS SQL Исследование 2.2.3.EXP.A

1-- Запрос 1: использование JOIN

2SELECT DISTINCT [s_id],

5JOIN [subscriptions]

6ON [s_id] = [sb_subscriber]

1-- Запрос 2: использование IN (... DISTINCT ...)

2SELECT [s_id],

3[s_name]

1-- Запрос 3: использование IN

2SELECT [s_id],

3[s_name]

1-- Запрос 4: использование LEFT JOIN

2SELECT [s_id],

3[s_name]

1-- Запрос 5: использование NOT IN (... DISTINCT ...)

2SELECT [s_id],

3[s_name]

1-- Запрос 6: использование NOT IN

2SELECT [s_id],

3[s_name]

Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016–2018 Стр: 89/545