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

Пример 27: выборка данных с использованием кэширующих представлений и таблиц

Увеличим на пять единиц количество экземпляров книги, которой сейчас в библиотеке зарегистрировано 10 экземпляров (такая книга у нас одна):

3WHERE "b_quantity" = 10;

4COMMIT; -- И подождать минуту.

Удалим книгу, оба экземпляра которой сейчас находится на руках у читателей (книга с идентификатором 1).

1DELETE FROM "books"

2WHERE "b_id" = 1;

3COMMIT; -- И подождать минуту.

Отметим, что по выдаче с идентификатором 3 книга возвращена:

3WHERE "sb_id" = 3;

4COMMIT; -- И подождать минуту.

Отменим эту операцию (снова отметим книгу как невозвращённую):

3WHERE "sb_id" = 3;

4COMMIT; -- И подождать минуту.

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

Пример 27: выборка данных с использованием кэширующих представлений и таблиц

Добавим в базу данных информацию о том, что читатель с идентификатором 2 взял в библиотеке книги с идентификаторами 5 и 6:

1INSERT ALL

2INTO "subscriptions" ("sb_subscriber",

22SELECT 1 FROM "DUAL";

23COMMIT; -- И подождать минуту.

Удалим информацию о выдаче с идентификатором 42 (книга по этой выдаче уже возвращена):

1DELETE FROM "subscriptions"

2WHERE "sb_id" = 42;

3COMMIT; -- И подождать минуту.

Удалим информацию о выдаче с идентификатором 62 (книга по этой выдаче ещё не возвращена):

1DELETE FROM "subscriptions"

2WHERE "sb_id" = 62;

3COMMIT; -- И подождать минуту.

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

Пример 27: выборка данных с использованием кэширующих представлений и таблиц

Наконец, удалим все книги (что также приведёт к каскадному удалению всех выдач):

1DELETE FROM "books";

2COMMIT; -- И подождать минуту.

Итак, все операции модификации данных в таблицах books и subscriptions вызывают соответствующие изменения в материализованном представле-

нии books_statistics.

Решение 3.1.2.b{215}.

Если вы пропустили решение{216} задачи 3.1.2.a{215}, настоятельно рекомендуется ознакомиться с ним перед тем, как продолжить чтение, т.к. многие неочевидные моменты, которые встретят в данном решении, были рассмотрены ранее.

По сравнению с предыдущей задачей{215} здесь всё будет намного проще, т.к. запрос, формирующий необходимый набор данных, не содержит выражений, подпадающих под ограничения индексированных представлений MS SQL Server и материализованных представлений Oracle.

Проблема будет только с MySQL, т.к. в нём подобных представлений нет как явления, и нам снова придётся создавать кэширующую таблицу и триггеры.

Создадим кэширующую таблицу (именно кэширующую, а не агрегирующую, как в задаче 3.1.2.a{215}, т.к. здесь мы ничего не агрегируем, а лишь сохраняем готовый результат). Код её создания можно почти полностью взять из кода создания таблицы subscritions, а для полей sb_subscriber и sb_book взять их опреде-

ления из таблицы subscribers и books.

MySQL Решение 3.1.2.b (создание кэширующей таблицы)

1CREATE TABLE `subscriptions_ready`

2(

3`sb_id` INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,

4`sb_subscriber` VARCHAR(150) NOT NULL,

5`sb_book` VARCHAR(150) NOT NULL,

6`sb_start` DATE NOT NULL,

7`sb_finish` DATE NOT NULL,

8`sb_is_active` ENUM ('Y', 'N') NOT NULL,

9CONSTRAINT `PK_subscriptions` PRIMARY KEY (`sb_id`)

10)

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

Пример 27: выборка данных с использованием кэширующих представлений и таблиц

Проинициализируем данные в созданной таблице:

MySQL Решение 3.1.2.b (очистка таблицы и инициализация данных)

1-- Очистка таблицы:

2TRUNCATE TABLE `subscriptions_ready`;

3

4-- Инициализация данных:

5INSERT INTO `subscriptions_ready`

12SELECT `sb_id`,

13`s_name` AS `sb_subscriber`,

14`b_name` AS `sb_book`,

15`sb_start`,

16`sb_finish`,

17`sb_is_active`

18 FROM `books`

19JOIN `subscriptions`

20ON `b_id` = `sb_book`

21JOIN `subscribers`

22ON `sb_subscriber` = `s_id`;

Напишем триггеры, модифицирующие данные в кэширующей таблице. Источником данных являются таблицы books, subscribers и subscriptions, потому придётся создавать триггеры для всех трёх таблиц.

Поскольку MySQL версии 5.6 не позволяет создавать несколько однотипных триггеров на одной и той же таблице, перед выполнением следующего кода придётся удалить созданные в задаче 3.2.1.a{215} триггеры с таблиц books и subscriptions.

Регистрация в библиотеке новых книг и читателей никак не влияет на содержимое таблицы subscriptions, потому нет необходимости создавать INSERT- триггеры на таблицах books и subscribers — достаточно DELETE- и UPDATE- триггеров.

Обратите внимание на несколько важных моментов в представленном ниже

коде:

•внутри триггера в MySQL мы не можем явно или неявно подтверждать транзакцию, а потому не можем использовать для очистки таблицы оператор TRUNCATE (он является «нетранзакционным», и потому приводит к неявному подтверждению транзакции);

•мы не храним в нашей кэширующей таблице идентификаторы книг, и потому не можем найти и удалить только отдельные записи (искать и удалять по названию книги тоже нельзя — несколько разных книг могут иметь одинаковое название), потому мы вынуждены каждый раз очищать всю таблицу и заново наполнять её данными;

•в задаче 3.2.1.a{215} мы использовали BEFORE-триггеры, хотя могли использовать и AFTER — там это не имело значения, здесь же мы обязаны использовать только AFTER-триггеры, т.к. в противном случае в силу особенностей логики транзакций поведение MySQL отличается от ожидаемого, и информация в кэширующей таблице может не обновиться.

За исключением только что рассмотренных нюансов код тела обоих триггеров совершенно тривиален и представляет собой два запроса — на удаление всех

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

Пример 27: выборка данных с использованием кэширующих представлений и таблиц

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

В триггере, реагирующем на обновление информации о книге, есть проверка (строка 45) того, поменялось ли название книги. Если не поменялось, то нет необходимости обновлять закэшированные данные.

MySQL Решение 3.1.2.b (триггеры для таблицы books)

1-- Удаление старых версий триггеров

2-- (удобно в процессе разработки и отладки):

3DROP TRIGGER `upd_sbs_rdy_on_books_del`;

4DROP TRIGGER `upd_sbs_rdy_on_books_upd`;

5

6-- Переключение разделителя завершения запроса,

7-- т.к. сейчас запросом будет создание триггера,

8-- внутри которого есть свои, классические запросы:

9DELIMITER $$

10

11-- Создание триггера, реагирующего на удаление книг:

12CREATE TRIGGER `upd_sbs_rdy_on_books_del`

13AFTER DELETE

14ON `books`

15FOR EACH ROW

16BEGIN

17DELETE FROM `subscriptions_ready`;

18INSERT INTO `subscriptions_ready`

36END;

37$$

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

Пример 27: выборка данных с использованием кэширующих представлений и таблиц

MySQL Решение 3.1.2.b (триггеры для таблицы books) (продолжение)

38-- Создание триггера, реагирующего на

39-- изменение данных о книгах:

40CREATE TRIGGER `upd_sbs_rdy_on_books_upd`

41AFTER UPDATE

42ON `books`

43FOR EACH ROW

44BEGIN

45IF (OLD.`b_name` != NEW.`b_name`)

46THEN

47DELETE FROM `subscriptions_ready`;

48INSERT INTO `subscriptions_ready`

66END IF;

67END;

68$$

69

70-- Восстановление разделителя завершения запросов:

71DELIMITER ;

Вся логика проверки работы таких триггеров подробно показана в решении{216} задачи 3.1.2.a{215}. Вы можете самостоятельно провести эксперимент, изменяя произвольным образом данные в таблице books и отслеживая соответствующие изменения в таблице subscriptions_ready.

Триггеры на таблице subscribers отличаются от триггеров на таблице books только своими именами, названиями своих таблиц и именем поля, изменение значения которого проверяется для определения необходимости обновления закэшированных данных (в коде выше проверяется поле b_name, в коде ниже — s_name).

MySQL Решение 3.1.2.b (триггеры для таблицы subscribers)

1-- Удаление старых версий триггеров

2-- (удобно в процессе разработки и отладки):

3DROP TRIGGER `upd_sbs_rdy_on_subscribers_del`;

4DROP TRIGGER `upd_sbs_rdy_on_subscribers_upd`;

5

6-- Переключение разделителя завершения запроса,

7-- т.к. сейчас запросом будет создание триггера,

8-- внутри которого есть свои, классические запросы:

9DELIMITER $$

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

Пример 27: выборка данных с использованием кэширующих представлений и таблиц

MySQL Решение 3.1.2.b (триггеры для таблицы subscribers) (продолжение)

10-- Создание триггера, реагирующего на удаление книг:

11CREATE TRIGGER `upd_sbs_rdy_on_subscribers_del`

12AFTER DELETE

13ON `subscribers`

14FOR EACH ROW

15BEGIN

16DELETE FROM `subscriptions_ready`;

17INSERT INTO `subscriptions_ready`

35END;

36$$

37

38-- Создание триггера, реагирующего на

39-- изменение данных о книгах:

40CREATE TRIGGER `upd_sbs_rdy_on_subscribers_upd`

41AFTER UPDATE

42ON `subscribers`

43FOR EACH ROW

44BEGIN

45IF (OLD.`s_name` != NEW.`s_name`)

46THEN

47DELETE FROM `subscriptions_ready`;

48INSERT INTO `subscriptions_ready`

66END IF;

67END;

68$$

69

70-- Восстановление разделителя завершения запросов:

71DELIMITER ;

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

Пример 27: выборка данных с использованием кэширующих представлений и таблиц

На таблице subscriptions придётся создавать все три триггера (INSERT, UPDATE и DELETE), т.к. каждая из этих операций может повлиять на содержимое кэширующей таблицы subscriptions_ready. И код всех этих трёх триггеров будет сильно различаться.

MySQL Решение 3.1.2.b (триггеры для таблицы subscriptions)

1-- Удаление старых версий триггеров

2-- (удобно в процессе разработки и отладки):

3DROP TRIGGER `upd_sbs_rdy_on_subscriptions_ins`;

4DROP TRIGGER `upd_sbs_rdy_on_subscriptions_del`;

5DROP TRIGGER `upd_sbs_rdy_on_subscriptions_upd`;

6

7-- Переключение разделителя завершения запроса,

8-- т.к. сейчас запросом будет создание триггера,

9-- внутри которого есть свои, классические запросы:

10DELIMITER $$

11

12-- Создание триггера, реагирующего на добавление выдачи книг:

13CREATE TRIGGER `upd_sbs_rdy_on_subscriptions_ins`

14AFTER INSERT

15ON `subscriptions`

16FOR EACH ROW

17BEGIN

18INSERT INTO `subscriptions_ready`

38END;

39$$

40

41-- Создание триггера, реагирующего на удаление выдачи книг:

42CREATE TRIGGER `upd_sbs_rdy_on_subscriptions_del`

43AFTER DELETE

44ON `subscriptions`

45FOR EACH ROW

46BEGIN

47DELETE FROM `subscriptions_ready`

48WHERE `subscriptions_ready`.`sb_id` = OLD.`sb_id`;

49END;

50$$

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

Пример 27: выборка данных с использованием кэширующих представлений и таблиц

MySQL Решение 3.1.2.b (триггеры для таблицы subscriptions) (продолжение)

51-- Создание триггера, реагирующего на обновление выдачи книг:

52CREATE TRIGGER `upd_sbs_rdy_on_subscriptions_upd`

53AFTER UPDATE

54ON `subscriptions`

55FOR EACH ROW

56BEGIN

57UPDATE `subscriptions_ready`

58JOIN (SELECT `sb_id`,

70`subscriptions_ready`.`sb_subscriber` = `new_data`.`s_name`,

71`subscriptions_ready`.`sb_book` = `new_data`.`b_name`,

72`subscriptions_ready`.`sb_start` = NEW.`sb_start`,

73`subscriptions_ready`.`sb_finish` = NEW.`sb_finish`,

74`subscriptions_ready`.`sb_is_active` = NEW.`sb_is_active`

75WHERE `subscriptions_ready`.`sb_id` = OLD.`sb_id`;

76END;

77$$

78

79-- Восстановление разделителя завершения запросов:

80DELIMITER ;

Код INSERT-триггера (строки 12-39) очень похож на код аналогичного триггера на таблице books. Отличие состоит в том, что в данном случае мы знаем идентификаторы читателя и книги, и это избавляет нас от необходимости формировать полную выборку.

Код DELETE-триггера (строки 41-50) получаемся самым компактным: нам нужно просто удалить из таблицы subscriptions_ready записи, идентификаторы которых совпадают с идентификаторами записей, удаляемых из таблицы subscriptions.

Код UPDATE-триггера (строки 51-77) — самый нетривиальный. Сам по себе синтаксис обновления на основе выборки выглядит непривычно (мы вынуждены объединять результаты выборки из обновляемой таблицы и выборки-источника — строки 57-68).

Условия в строках 66-67 позволяют сократить количество выбираемых рядов, а условие в строке 68 гарантирует, что мы получим данные о новой записи таблицы subscriptions, даже если у неё изменился первичный ключ. Следуя этой же логике, мы не указываем условие объединения `subscriptions_ready` JOIN ... `new_data`, т.к. единственным здравым условием объединения здесь может быть совпадение значений sb_id, но если первичный ключ записи в таблице subscriptions поменялся, то такого совпадения не будет, т.к. в таблице subscriptions_ready всё ещё хранится старое значение первичного ключа обновляемой записи.

В строках 69-74 новые данные для обновления полей мы берём из двух источников: из явно переданных данных через ключевое слово NEW (все значения, которые мы можем получить напрямую) и из результатов выборки new_data (имя читателя и название книги, т.к. их нет и не может быть в явно переданных данных, доступных через ключевое слово NEW).

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

Пример 27: выборка данных с использованием кэширующих представлений и таблиц

Условие в строке 75 гарантирует, что мы обновим нужную запись: здесь необходимо сравнение идентификатора обновляемой записи именно с OLD.`sb_id`, а не с NEW.`sb_id`, т.к. у обновляемой записи в таблице subscriptions мог поменяться первичный ключ, и нам нужно найти его старое значение в таблице subscriptions_ready (благодаря выражению в строке 69 это значение тоже обновится, если оно изменилось).

Вся логика проверки работы таких триггеров подробно показана в решении{216} задачи 3.1.2.a{215}. Вы можете самостоятельно провести эксперимент, изменяя произвольным образом данные в таблице books, subscribers и subscriptions и отслеживая соответствующие изменения в таблице subscriptions_ready.

По сравнению с решением для MySQL, решения для MS SQL Server и Oracle предельно просты. В их основе лежит обычный запрос на выборку, который можно выполнить и сам по себе.

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

1-- Удаление старой версии индексированного представления

2-- (удобно при разработке и отладке):

3DROP VIEW [subscriptions_ready];

4

5-- Создание представления:

6CREATE VIEW [subscriptions_ready]

7WITH SCHEMABINDING

8AS

9SELECT [sb_id],

10[s_name] AS [sb_subscriber],

11[b_name] AS [sb_book],

12[sb_start],

13[sb_finish],

14[sb_is_active]

15 FROM [dbo].[books]

16JOIN [dbo].[subscriptions]

17ON [b_id] = [sb_book]

18JOIN [dbo].[subscribers]

19ON [sb_subscriber] = [s_id];

20

21-- Создание уникального кластерного индекса на представлении.

22-- Именно эта операция "включает" автоматическое обновление

23-- представления при изменении данных в таблицах,

24-- на которых оно построено:

25CREATE UNIQUE CLUSTERED INDEX [idx_subscriptions_ready]

26ON [subscriptions_ready] ([sb_id]);

Чтобы данные в представлении subscriptions_ready обновлялись автоматически, его нужно сделать индексированным, т.е. создать на нём уникальный кластерный индекс (строки 25-26).

Необходимым условием создания такого индекса на представлении является привязка представления к схеме базы данных (строка 7), указывающая СУБД на необходимость установить и отслеживать соответствие между использованием в коде представления объектов базы данных и реальным состоянием таких объектов (их существованием, доступностью и т.д.) не только в момент создания представления, но и в момент любой модификации объектов базы данных, на которые ссылается представление.

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