No SQL — no money

В процессе лекции о сетевой модели данных в качестве примера её реализации в СУБД я использую Neo4j. Авторы скромно называют свою добротную поделку "графовой", но это чистая дань маркетингу, дабы не ассоциироваться с такими монстрами, как СУБД IDS Бахмана, созданная им в Honeywell еще в районе 1966 года.

После откровений об отсутствии схемы, позволяющем наполнять базу данных информационной кашей, перекладывая ответственность за полноту и целостность данных целиком на плечи программиста, студенты слегка приуныли. Где-то на середине презентации при рассмотрении синтаксиса CQL-запросов у одного слушателя возникло желание узнать о практическом применении этой СУБД. Тут я на минутку расслабился и выдал фразу в духе "не знаю, кто использует все эти поделки уровня курсовых студенческих работ, в мире индустриального софтостроения их доля близка к нулю". Потом поправился конечно. Мол, Neo4j исходит из среды ученых-исследователей, им бывает нужно быстро наполнить БД разносортным говном набором экспериментальных данных и связей, а потом уже в них копаться-разбираться. Вышло успокоительно, не не очень убедительно.

Предварительный итог курса. По интуитивной понятности лидирует реляционная модель, за ней — иерархические модели XML с XPath (XQuery уже сложнее). Потруднее с многомерными моделями (кубами), но человеческие инструменты Microsoft задачу здорово облегчают. Поделия-изделия типа Neo4j (сетевая модель) и MongoDb (иерархическая документ-ориентированная модель) представляют реальные трудности при отсутствии схем. JSON — откровенно античеловеческий формат, придуманный для машинной обработки, но извлеченный мизантропами для ручной; не говоря уже о причудливых Jxxx-языках запросов. Модель EAV при реализации поверх РСУБД у неподготовленных студентов вызывает взрыв мозга на стадии практических задач. Не удалось попугать будущих информатиков такой СУБД, как Caché, но это было бы явным перебором.