Приложение к уроку № 9 - РБД и SQL

Вкратце

Приветствую, коллеги.
Этим кратким (по охвату материала - быть может, с точки зрения текстового наполнения он будет не так уж и мал) уроком я бы хотел открыть цикл статей по работе с SQL - на уровне реляционных БД. То есть - достаточно глубокий разбор операций на уровне SQL, конструкций и их применения.
Не секрет, что львиная доля нагрузки ложится именно на БД. Объясняется это простой вещью - любая программа есть не что иное, как обработчик - она принимает некоторое множество данных на входе (в некоторых случаях, пустое множество) и результатом её работы так же является некоторое множество данных. А так как БД хранит именно данные, а СУБД управляет ими, то именно в этой части приложения сосредоточены, как правило, самые сложные и затратные операции.
Разумеется, современные СУБД спроектированы и созданы с тем, чтобы максимально удовлетворить потребности в хранении и обработке данных, однако только правильное использование позволит создавать быстрые приложения.
Дальнейшие рассуждения будут относиться к СУБД MySQL версии 5 и выше. Если будет требоваться отдельно - версия будет озвучена, так как существуют некоторые весомые отличия между версиями даже внутри 5-й ветки MySQL.

Немного основ
Прежде всего, сделаю некоторое отступление в сторону математической теории и обоснований. А именно - вводные данные теории множеств с учетом рассматриваемой предметной области (т.е. теории РБД - реляционых баз данных).
Множеством я назову любую совокупность однородных по некоторому признаку/принципу объектов. Простой пример: множество волос на вашей голове. Множества обозначаются как элементы, перечисленные в фигурных скобках.
Мощностью множества называется число его элементов. Множество, не имеющее элементов вовсе, называется пустым множеством. Таким образом, если у человека пустое множество волос на голове, то он лысый.
Объединением множеств называется множество, которое содержит в себе элементы, каждый из которых принадлежит хотя бы одному из первоначальных объединяемых множеств.
Пересечением множеств называется множество, которое содержит элементы, содержащиеся сразу во всех первоначальных пересекаемых множеств. Важно - пересечение в любом случае будет множеством, даже если общих элементов нет. В этом случае такое множество попросту будет пустым.
Кортеж - это упорядоченная последовательность элементов. Обозначается как, например, (a, b, c) - кортеж из трех элементов. Упорядоченность последовательности означает, что порядок следования важен и при сравнении кортеж (a, b, c) не равен кортежу (a, c, b)
Декартовым произведением двух кортежей называется множество, содержащее попарно все элементы каждого из кортежей. Например, декартовым произведением кортежей (a, b, c) и (p, q) является множество пар {(a, p), (a, q), (b, p), (b, q), (c, p), (c, q)}
Если обощить это определение, то для трех кортежей результатом произведения будет множество троек, для четырех - четверок и т.п.
Зачем это все было нужно? В дальнейшем некоторая терминология будет встречаться и, кроме этого, базовые операции работы с упорядоченными/неупорядоченными множествами оказываются крайне полезными для понимания многих SQL-операций, так как они оперируют наборами данных, которые как раз и являются множествами.

SQL?
Итак, собственно SQL. Думаю, многие не поленились узнать, что это - Structured Query Language - структурированный язык запросов. Что же такое запрос? Простым языком - это обращение к СУБД с целью исполнить операцию. Как происходит такое обращение, зависит сугубо от реализации интерфейса обмена данными с самим сервером БД. В данном уроке я не буду освещать эту тему, ограничусь лишь тем, что классически этот обмен происходит через сетевой протокол наподобие TCP.
Для MySQL всех версий сервер БД слушает по-умолчанию на порту 3306, на этом отступление завершу.
Задумаемся, что же такое - данные и что с ними можно делать. Данные - это, разумеется, осмысленный набор информации. Его представление для СУБД - набор бит и байт. То, как СУБД хранит эти данные, зависит от storage-engine - движка хранения данных. Для MySQL, снова отступлю, есть два основных движка - это InnoDB и MyISAM. О них речь пойдет в других уроках.
Итак, данные хранятся. Но зачем просто хранить данные, ведь нужно работать с ними. Что значит работать? Классически - это читать и изменять данные. Но прежде вдумаемся в то, что мы собрались читать и изменять. То, что является осмысленным информационным набором, должно, очевидно, храниться в виде некоторой структуры. Таким образом, данные представляются в ней и с ними можно работать сообразно неё. Имея структуру данных как нечто определенное, можно уже говорить о том, чтобы в соответствии с ней данные хранились.
Для наглядности можно привести пример - городской архив. Как его организовать? Можно разобрать книги по алфивиту названий и поставить в длинный ряд. Таким образом, вся организация сведется к одной длинной полке. А можно разобрать книги по году, изданию, автору, названию и т.п. И организовать это в виде многоуровневой структуры блоков, стеллажей и полок. Отличается? Разумеется. Обратите внимание, я не указываю, что одна структура в примере чем-то лучше другой. Это - лишь пример.
Но длинная полка или структура стеллажей - это лишь структура, если в ней нет книг - то есть собственно данных, то она ничем не наполнена и потому не имеет никакой ценности. Таким образом, можно увидеть две основных вещи. Данные - это совокупность структуры и наполнения. Стркутуру также называют метаданными ("метаданные" - это "данные о данных"), потому что она описывает способ организации данных. Если подумать, то со структурой как с частным случаем собственно данных тоже возможно то, что выше мы назвали "работать с данными" (напомню - чтение/изменение). Это подводит нас к тому, что существует необходимость работы как со структурой, так и с наполнением.
Вернемся к примеру. Чтобы создать архив, сначала нужно определиться с его устройством, то есть задать структуру. И затем - уже наполнять его книгами. Это сказано к тому, что классически сначала проектируется и задается структура, которая затем наполняется. Итак, мы подошли к двум столпам SQL:
DDL - Data Definition Language - язык, задающий способы определения структур данных.
DML - Data Manipulation Language - язык, задающий способы манипуляции с данными.
Вместе эти два подмножества языка SQL образуют некоторый стандарт запросов к СУБД. Я умышленно не начал рассказывать о знакомых вещах наподобие таблиц/полей и т.п. - так как хотел, чтобы, абстрагируясь от способа представления данных даже в теории (имею ввиду РБД), было яснее видно назначение языка работы с данными. К слову, существуют не только реляционные модели хранения данных, но и там существует свой SQL, все так же состоящий из DDL и DML.

Конкретика РБД и SQL
Коротко введя в теорию SQL я уже могу перейти к некоторым - опять же теоретическим - словам о том, как организуется работа с данными в случае, если речь идет об РБД. Коротко о слове "реляционная". Оно исходит от "relation" - отношение. И означает, что данные соотносятся друг с другом на основании некоторой бизнес-логики, которая закладывается в структуре.
В РБД данные - любые - представляются в виде таблиц. С теоретической точки зрения таблица как раз и есть частный случай "отношения" (relation) данных, а точнее - способ его "визуального" представления. Не следует путать одно с другим. Здесь и далее "таблица" употребляется как теоретический термин. Тем не менее я воздержусь от изложения основ курса РБД, так как урок все же более нацелен на практическое применение.
В БД таблицы, как правило, представляют собой проекцию сущностей, заложенных логикой приложения, на структуру данных. У каждой сущности (отвлеченно от БД), разумеется, имеются некоторые свойства - которые в терминах БД будут называться атрибутами. Таким образом, таблица будет представлять собой совокупность данных, относящихся к одной сущности а потому имеющих одинаковые атрибуты. Сразу - пример. Рассмотрим сущность "окно". Какие у него могут быть атрибуты? Подумав, можно привести: ширина, высота, толщина стекла, цвет и т.п. То есть атрибуты - это то, что описывает сущность в рамках реализуемой бизнес-логики. Почему в рамках? Потому что, к примеру, может быть так, что у сущности "окно" в пределах приложения, реализующего данные по поставке окон, атрибут "предельное сопротивление материала несущих балок", скорее всего, не имеет смысла, тогда как в терминах приложения, реализующего данные по разработке и производстве - очень даже может быть.
Подведем промежуточный итог. Мы уже знаем, что таблицы - реализуют сущности для БД, а сущности берутся не из воздуха, а сообразно логике приложения. Кроме того, у сущностей есть атрибуты, которые их характеризуют. Если перейти к реализации атрибутов в БД, то они предстанут полями - визуально, как правило, представляющимися стобцами (колонками). Таким образом, структура, задаваемая сущностью, имеет в проекции на БД таблицу, описываемую полями.
Главный вопрос - откуда же берутся сущности и как их выделять на основе требуемого от приложения функционала - я вынесу за рамки данного ознакомительного урока, так как это целый пласт, касающийся, в основном, проектирования БД. Вернувшись же к таблицам и полям, остается сделать еще один шаг - рассмотреть строки - это, по сути, экземпляры той сущности, которую реализует таблица. Если вернуться к примеру с окнами - то, скорее всего, у каждого окна, которое приходит от поставщика, есть свой номер, тип и т.п. Эти данные и будут заполнять строки таблицы "окна".

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.