6.4.8.JOIN’ы и NULL’ы

Q:Когда и где NULL’ы (реально содержащиеся в полях, по которым происходит объединение) сохраняются и пропадают при использовании JOIN?

A:Пропадают при JOIN, FULL JOIN, INNER JOIN, CROSS JOIN, “,”. Сохраняются при LEFT [OUTER] JOIN, RIGHT [OUTER] JOIN.

Q: Не понятно .

A: Жаль . Т.е. сейчас рассмотрим пример.

Пусть у нас есть таблицы `in` и `out`, фиксирующие приход на работу и уход с работы сотрудника. Для полноты картины представим, что данные вносятся вручную, и нерадивый вахтёр часто забывает, как сотрудника зовут. Тогда мы получим, например, такое:

Теперь напишем запросы, с помощью которых постараемся выяснить ситуации вида

(А) «пришёл и ушёл»;

(Б) «(А) + пришёл, но не ушёл»;

(В) «(А) + не приходил, но ушёл».

Стр: 200/248

Базы данных БГУИР, ПОИТ

«Пришёл и ушёл»

SELECT * FROM `in` FULL JOIN `out` USING (`name`)

SELECT * FROM `in` INNER JOIN `out` USING (`name`)

SELECT * FROM `in` CROSS JOIN `out` USING (`name`)

Результат

«Пришёл и ушёл + пришёл, но не ушёл»

SELECT * FROM `in` LEFT OUTER JOIN `out` USING (`name`)

Результат

«Пришёл и ушёл + не приходил, но ушёл»

SELECT * FROM `in` RIGHT OUTER JOIN `out` USING (`name`)

Результат

Стр: 201/248

6.4.9.JOIN’ы и дублирование имён полей

Q:Во всех предыдущих примерах дублируется поле `id`. Это отвратительно! Как от этого избавиться!?

A:Использовать AS в запросе для переименования полей. Вот так:

Стр: 202/248

6.4.10.Нетривиальные случаи, вопросы и примеры

Итак, всё типичное с JOIN’ами мы рассмотрели. Теперь рассмотрим нетипичное.

Рекурсивные JOIN’ы

Q: Как сделать "рекурсивный JOIN"? Например, чтобы скопировать ветку дерева.

A:

хранимую процедуру, которая «выполнит рекурсию» в виде цикла, или написать рекурсивную хранимую процедуру (не функцию, т.к. они не поддерживаются).

Подробности: http://stackoverflow.com/questions/3536538/mysql-does-not- support-recursive-functions-why-since-when

См. также альтернативные способы хранения и обработки иерархических структур в реляционных БД: http://www.slideshare.net/billkarwin/models-for- hierarchical-data

Как исследование запросов влияет на модель БД

Представим классический пример части модели БД «Деканат». Эта часть описывает студентов, преподавателей и предметы.

Мы можем выполнить здесь несколько примитивных запросов в стиле «показать, кто у кого учится», «показать, кто что изучает», «показать, кто что ведёт».

Например, вот запрос, показывающий «какие студенты изучают какие предметы и какие у них оценки».

SELECT `st_name`, `sb_name`, `mark` from `students`, `subjects`, `m2m_st_sb`

WHERE `students`.`st_id` = `m2m_st_sb`.`st_id` AND `m2m_st_sb`.`sb_id` = `subjects`.`sb_id`

Или так (запросы эквивалентны):

SELECT `st_name`, `sb_name`, `mark` from

`students` JOIN `m2m_st_sb` ON `students`.`st_id` = `m2m_st_sb`.`st_id` JOIN `subjects` ON `m2m_st_sb`.`sb_id` = `subjects`.`sb_id`

Но! Как только возникает вопрос в стиле «Вывести среднее значение всех оценок, выставленных конкретным преподавателем», выясняется, что БД не содержит этой информации. Т.е. мы знаем, что такие-то преподаватели ведут такие-

Стр: 203/248

то предметы у таких-то студентов, но кто конкретно выставлял оценку – выяснить нельзя.

Более того, анализ модели показывает её полное несоответствие реальности (как показать пересдачу, повторное обучение после отчисления и восстановления, как отличать курсовые (одна оценка) и лабораторные (много оценок) и т.д.)

Если модель переработать, получается вот так (да-да, эту модель можно ещё дорабатывать и дорабатывать):

Теперь ответ на вопрос «Как вывести среднее значение всех оценок, выставленных конкретным преподавателем?» выглядит так:

Стр: 204/248

Ещё более нетипичные модель БД и JOIN’ы

Представим, что модель БД интернет-магазина построена по следующей логике: есть единая таблица, в которой хранятся универсальные характеристики товаров (наименование, цена, количество и т.д.), а все уникальные характеристики хранятся в отдельных таблицах, каждая из которых описывает одну категорию товаров. Далее между «единой» и «дополнительными» таблицами проведены связи типа «один к одному».

Да, в реальности с такой моделью могут быть проблемы. Но если реализовать её вдумчиво и аккуратно, всё будет в порядке.

Итак, вот эта модель:

Наполним таблицы данными:

`ctg_cpu`

`ctg_printers`

Стр: 205/248

Показать все товары заданной категории (id категории мы знаем):

Показать все топовые товары по убыванию цены с их категориями:

Хотите поэкспериментировать? Вот дампы баз!

Стр: 206/248

Базы данных БГУИР, ПОИТ

CREATE TABLE IF NOT EXISTS `time` (

`t_id` int(11) NOT NULL, `t_start` date NOT NULL, `t_end` date NOT NULL, `t_descr` varchar(255) NOT NULL, PRIMARY KEY (`t_id`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

--

-- Dumping data for table `time`

--

INSERT INTO `time` (`t_id`, `t_start`, `t_end`, `t_descr`) VALUES

(0, '2012-11-14', '2012-11-24', '');

-- --------------------------------------------------------

--

-- Table structure for table `tutors`

--

CREATE TABLE IF NOT EXISTS `tutors` ( `tt_id` int(11) NOT NULL AUTO_INCREMENT,

`tt_name` varchar(255) NOT NULL,

PRIMARY KEY (`tt_id`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=7 ;

--

-- Dumping data for table `tutors`

--

INSERT INTO `tutors` (`tt_id`, `tt_name`) VALUES (1, 'TT_Strict_A'),

(2, 'TT_Strict_B'), (3, 'TT_Kind_A'), (4, 'TT_Kind_B'),

(5, 'TT_Spontanuous'), (6, 'TestTutor');

-- --------------------------------------------------------

--

-- Table structure for table `types`

--

CREATE TABLE IF NOT EXISTS `types` (

`t_id` int(11) NOT NULL AUTO_INCREMENT, `t_type`

enum('lecture','lab','practice','course','diploma','d_practice','p_practi ce') NOT NULL,

PRIMARY KEY (`t_id`),

UNIQUE KEY `t_type` (`t_type`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=6 ;

--

-- Dumping data for table `types`

--

INSERT INTO `types` (`t_id`, `t_type`) VALUES (1, 'lecture'),

(2, 'lab'),

(3, 'practice'), (4, 'course'), (5, 'diploma');

--

-- Constraints for dumped tables

--

--

-- Constraints for table `facts`

--

ALTER TABLE `facts`

ADD CONSTRAINT `facts_ibfk_5` FOREIGN KEY (`f_time`) REFERENCES `time` (`t_id`) ON DELETE CASCADE ON UPDATE CASCADE,

ADD CONSTRAINT `facts_ibfk_1` FOREIGN KEY (`st_id`) REFERENCES `students` (`st_id`) ON DELETE CASCADE ON UPDATE CASCADE,

ADD CONSTRAINT `facts_ibfk_2` FOREIGN KEY (`tt_id`) REFERENCES `tutors` (`tt_id`) ON DELETE CASCADE ON UPDATE CASCADE,

ADD CONSTRAINT `facts_ibfk_3` FOREIGN KEY (`sb_id`) REFERENCES `subjects` (`sb_id`) ON DELETE CASCADE ON UPDATE CASCADE,

ADD CONSTRAINT `facts_ibfk_4` FOREIGN KEY (`type`) REFERENCES `types`

(`t_id`) ON DELETE CASCADE ON UPDATE CASCADE;

--

-- Constraints for table `marks`

--

ALTER TABLE `marks`

ADD CONSTRAINT `marks_ibfk_1` FOREIGN KEY (`m_fact`) REFERENCES `facts`

(`f_id`) ON DELETE CASCADE ON UPDATE CASCADE;

/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;

/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */; /*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;

Стр: 208/248