Чем мне не нравится SQL

Наболело. Сталкиваясь с SQL-based движками СУБД, иной раз буквально чувствуешь над собой дамоклов меч проклятия SQL. Что любые потуги что-то сделать запросто могут нарваться на "низзя". Когда-то, когда концепция SQL ещё была несерьезной из-за ресурсоемкости, к ней относились с насмешкой и мало кто верил что завтра это станет обычным делом. Однако, стало.

Условность стандарта.

Мне не нравится условность и необязательность соблюдения стандартов. Есть стандарт языка. Хуже того, он периодически перевыходит все новее и новее. Удивительно, но в нем до сих пор нет никакой привязки к реальности, ибо не определен уровень переносимости. Любая СУБД может задекларировать соответствие стандарту SQL-XX. Реклама, документация, пиар. Берем, смотрим, сравниваем. И толку? Переносимость не описана. И уровень переносимости всегда приходится определять самостоятельно. Самостоятельно изучив область пересечения функционала различных имплементаций.

Про обязательность соответствия стандарту можно наверно вообще не писать. Каждый вендор трактует необходимость соответствия стандарту самостоятельно.

Неполнота операций. Дайте два!

Мне не нравится, что меня вынуждают надстраивать над движком СУБД вторичные надстройки манипуляции данными. До сих пор остается большой тайной как не имея развитого механизма блокировок удержать при конкурентном доступе не более N записей в таблице имеющих одинаковое значение атрибута. Блокировки в стандарте отсутствуют. На те механизмы ограничения целостности которые поддерживаются каждым отдельным вендором приходится молиться чтобы они действительно работали и продолжали работать при смене версии продукта.

Как построить прикладную систему используя SQL-based движок уже давно стало поводом для огромного числа флеймов на тему многозвенной архитектуры. Заложись на использование SQL - и волоки рядом фабрику на других языках.

Что используем на самом деле - стандарт или реальную имплементацию?

Мне не нравится, что у каждого вендора присутствуют свои "особенности" имплементации. У одного нет половины аппарата триггеров, у другого задекларирована версионность но без блокировочных опций иные операции не выполнимы и так далее.

Берем и изучаем нюансы трактовки операций. Строим макеты и проверяем в какой операции каким именно образом отрабатывается конкурентный доступ. И какой расход ресурсов на это требуется реально. И не забываем повторять то же самое по полной программе при переходе на следующую версию.

Любые реальные решения практически всегда опираются не на язык, а на особенности движка определенного вендора. 100% vendor lock-in.

Повторное использование кода или копипаст?

Мне не нравится, что несколько взаимосвязанных запросов не могут использовать библиотечный подход. Если несколько запросов используют повторяющееся условие where, то приходится копипастить. Если совпадают фрагменты условия where, приходится копипастить. Не хочешь копипастить - пробуй применять view или select-procedure и молись чтобы механизм подошел и работал.

Когда более-менее реальные запросы вырастают на несколько страниц и, читая последнее условие, уже не можешь удержать в голове с чего же оно началось - начинает бить колотун. Распечатываем, раскрашиваем фрагменты маркерами, и мучительно думаем как бы в этом языке использовать вынесение повторяющегося кода в библиотечные вызовы. Никак. Плюем на все чему учили.

Самодеятельность оптимизаторов.

Мне не нравится, что программист, будь хоть семи пядей во лбу, не в состоянии использовать в запросе индексы. Исчисление хинтов становится самостоятельным занятием и областью программирования. Кроме разработки системы начинаем программировать на хинтах, влезать в нюансы тюнинга. Если есть операции с хинтами на индексы - то почему нет операций с индексами?

Сегодня оптимизатор выбрал один план - завтра выберет другой. От чего зависит производительность? Очень удобно для безответственного отношения. Всегда можно свалить проблему на особенности сервера. В рекламе - отчеты онлайн, в реале - отчеты по ночам.

В условиях 100% vendor lock-in при выходе очередной версии тщательно вычитываем что же там улучшили с оптимизатором. Шаманство становится нормой жизни.

Переносимость.

Мне не нравится, что разработчик ставится в практически безвыходное положение если желает переносимости. Поскольку в силу особенностей на одном SQL полноценную систему не напишешь, городим 2-х или 3-х звенную схему. В переносимость входит возможность заменить движок СУБД на другой.

Что на практике? Используя пересечение множеств функционала двух или более движков мы резко снижаем эффективность и без того не ахти какой системы. Используя повышение эффективности с учетом особенностей мы сужаем выбор. В реале переносимость серверного кода прикладной системы означает практически всегда разработку второго варианта.

Я понимаю, что есть особенности операционных систем и версий и переносимость практически всегда означает доработку под еще один вариант. Но тогда причем тут стандарт на язык который не привязан к операционке и вендору и оперирует данными?

Чем завалены форумы.

Мне не нравится, что на форумах программистов, использующих SQL-based СУБД, такое количество обсуждаемых проблем. Это о чем говорит, о количестве решений или о количестве проблем, недоработках вендоров и проблемах языка? Я считаю, что второе. Нормальная, доработанная, зрелая система должна давать программисту возможность решить проблемы БЕЗ обращения к сторонней информации. Если есть ошибка в движке - то ее исправляет сам вендор и об оперативности исправления и речи не идет, это само собой разумеющееся, вне зависимости от источника сообщения.

Такое количество обсуждаемых проблем SQL-based движков не может не настораживать. Читаешь форумы и видишь их эпиграф: "Примени эту СУБД - и эти проблемы станут твоими."

Ждем милости от разработчиков.

Мне не нравится, что программист SQL-based СУБД вынужден молиться на разработчиков вендора если ему не хватило какой-либо небольшой функциональности. Например, в силу решаемой задачи решение основывается на применении bitmap индексов. Но вендор их не поддерживает. Запросто получаем "низзя". Сидим курим, мечтаем. Пробуем применить другую систему - и получаем воз проблем с переносом. Дешевле не делать вообще или применить неправильные для задачи индексы.

Хотим в одной таблице иметь два или более блобов - и на тебе. Запросто можем получить "низзя".

Хотим иметь полный набор триггеров - запросто можем получить "низзя".

Хотим иметь select из хранимой процедуры с параметрами - запросто можем получить "низзя".

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

Конечно, в нашей работе нет состояния "нет проблем". Это норма. Но не настолько же...