Материал: Using_MySql,_MS_SQL_Server_and_Oracle
Пример 20: все разновидности запросов на объединение в трёх СУБД
В задаче 2.2.10.m{179} (OUTER APPLY):
Задание 2.2.10.TSK.A: показать информацию о том, кто из читателей и когда брал в библиотеке книги.
Задание 2.2.10.TSK.B: показать информацию обо всех читателях и датах выдачи им в библиотеке книг.
Задание 2.2.10.TSK.C: показать информацию о читателях, никогда не бравших в библиотеке книги.
Задание 2.2.10.TSK.D: показать книги, которые ни разу не были взяты никем из читателей.
Задание 2.2.10.TSK.E: показать информацию о том, какие книги в принципе может взять в библиотеке каждый из читателей.
Задание 2.2.10.TSK.F: показать информацию о том, какие книги (при условии, что он их ещё не брал) каждый из читателей может взять в библиотеке.
Задание 2.2.10.TSK.G: показать информацию о том, какие изданные до 2010-го года книги в принципе может взять в библиотеке каждый из читателей.
Задание 2.2.10.TSK.H: показать информацию о том, какие изданные до 2010-го года книги (при условии, что он их ещё не брал) может взять в библиотеке каждый из читателей.
Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016-2018 Стр: 191/545
Пример 21: вставка данных
2.3. Модификация данных
2.3.1. Пример 21: вставка данных
Очень полезным источником хороших примеров выполнения вставки данных для
любой |
СУБД |
является |
примеров SQL-конструкций по созданию таблиц, связей, триггеров и |
изучение дампов
баз дальнейшие рассуждения относительно способа передачи строкоданных построены на предположении, что базы данных созданы в
данных (там же вы увидите множество готовых т.д.) Все вых следующих кодировках:
•MySQL: utf8 / utf8_general_ci;
•MS SQL Server: UNICODE / Cyrillic_General_CI_AS;
•Oracle: AL32UTF8 / AL16UTF16.
Тема кодировок и работы с ними огромна, очень специфична для каждой СУБД и почти не будет рассмотрена в этой книге (кроме задач 7.3.2.a{525} и 7.3.2.b{525})
— обратитесь к документации по соответствующей СУБД.
Задача 2.3.1.a{182}: добавить в базу данных информацию о том, что читатель с идентификатором 4 взял 15-го января 2016-го года в библиотеке книгу с идентификатором 3 и обещал вернуть её 30-го января 2016-го года.
Задача 2.3.1.b{185}: добавить в базу данных информацию о том, что читатель с идентификатором 2 взял 25-го января 2016-го года в библиотеке книги с идентификаторами 1,3, 5 и обещал вернуть их 30-го апреля 2016го года.
Ожидаемый результат 2.3.1.a: в таблице subscriptions должна появиться такая новая запись.
sb_id |
sb_subscriber |
sb_book |
sb_start |
sb_finish |
sb_is_active |
101 |
4 |
3 |
2016-01-15 |
2016-01-30 |
N |
Ожидаемый результат 2.3.1.b в таблице subscriptions должны появиться три таких новых записи.
sb_id |
sb_subscriber |
sb_book |
sb_start |
sb_finish |
sb_is_active |
102 |
2 |
1 |
2016-01-25 |
2016-04-30 |
N |
103 |
2 |
3 |
2016-01-25 |
2016-04-30 |
N |
104 |
2 |
5 |
2016-01-25 |
2016-04-30 |
N |
Ч? Решение 2.3.1 .a{182}.
Во всех трёх СУБД в таблице subscriptions у нас созданы автоинкрементируемые первичные ключи, потому их значение указывать не надо. Остаётся только передать известные нам данные.
Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016-2018 Стр: 192/545
Пример 21: вставка данных
MySQL |
Решение 2.3.1 .а |
||
1 |
INSERT INTO 'subscriptions' |
||
2 |
|
|
('sb_id', |
3 |
|
|
'sb_subscriber' |
4 |
|
|
'sb_book', |
5 |
|
|
'sb_start', |
6 |
|
|
'sb_finish', |
7 |
|
|
'sb_is_active') |
8 |
VALUES |
(NULL, |
|
9 |
|
|
4, |
10 |
|
|
3, |
11 |
|
|
'2016-01-15', |
12 |
|
|
'2016-01-30', |
13 |
|
|
'N') |
Если вставка выполняется во все поля таблицы, часть запроса в строках 2-7 можно не писать, в противном случае эта часть является обязательной.
Если мы не хотим явно указывать значение автоинкрементируемого первичного ключа, в MySQL можно вместо его значения передать NULL или исключить это поле из списка передаваемых полей и не передавать никаких данных (т.е. убрать имя поля в строке 2 и значение NULL в строке 8).
MS SQL I Решение 2.3.1.a |
1 |
INSERT INTO [subscriptions] |
|
||
2 |
|
([sb subscriber], |
|
|
3 |
|
[sb |
book] |
|
4 |
|
[sb |
start], |
|
5 |
|
[sb |
finish], |
|
6 |
|
[sb |
is active]) |
|
7 |
VALUES |
4 , |
|
|
8 |
|
3 , |
|
|
9 |
|
CAST(N'2016-01- |
AS DATE), |
|
10 |
|
CAST(N'2016-01- |
AS DATE), |
|
11 |
|
N'N') |
|
|
|
|
|
|
|
В MS SQL Server автоинкрементация первичного ключа осуществляется за счёт того, что соответствующее поле помечается как IDENTITY. Вставка значений NULL и DEFAULT в такое поле запрещена, потому мы обязаны исключить его из
списка полей и не передавать в него никаких значений.
Даже если бы мы точно знали значение первичного ключа этой вставляемой записи, всё равно для его вставки нам пришлось бы выполнить две дополнительных операции:
•перед вставкой данных выполнить команду SET IDENTITY_INSERT [sub-
scriptions] ON;
• после вставки данных выполнить команду SET [subscriptions] OFF.
Эти команды соответственно разрешают и снова запрещают вставку в IDEN- TITY-ПОЛЄ явно переданных значений.
В строках 9-10 запроса производится явное преобразование строки, содержащей дату, к типу данных DATE. MS SQL Server позволяет этого не делать (кон-
вертация происходит автоматически), но из соображений надёжности рекомендуется использовать явное преобразование.
Теми же соображениями надёжности вызвана необходимость ставить букву N перед строковыми константами (строки 9-11 запроса), чтобы явно указать СУБД на то, что строки представлены в т.н. «национальной кодировке» (и юникоде как форме представления символов). Для символов английского алфавита и символов,
Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016-2018 Стр: 193/545
Пример 21: вставка данных
из которых состоит дата, этим правилом можно пренебречь, но как только в строке
Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016-2018 Стр: 194/545