Компиляция СУБД по описанию структуры базы (по аналогии с bison) – такое существует?
Вопрос на правах любопытства. Стало интересно, существует ли в природе некая «предкомпилируемая» реляционная СУБД? Правильнее будет сказать не СУБД, а «конструктор СУБД», «генератор СУБД» или «компилятор СУБД», который по заранее заданному описанию базы (структуры таблиц, всех возможных запросов к ним, хранимых процедур, триггеров, каких-либо настроек вроде формата контейнеров и размера буферов и т.д.) будет генерировать исполняемые файлы самой СУБД, «заточенной» под конкретную БД (и соответственно, работающую только с ней). Речь идёт о том, чтобы скомпилировать все SQL-запросы в нативный код, и, к примеру, каждый запрос оформить в виде отдельной экспортируемой из СУБД функции с соответствующими запросу параметрами. В общем, пожалуй, некоторая аналогия того, о чём я говорю, из области создания компиляторов – bison.
Такой подход по идее снизит накладные расходы по сравнению с традиционными СУБД (на тот же парсинг SQL-запроса, на двойное копирование данных в сокет/общую память при передаче их между приложением и СУБД, на множество «лишних» проверок, неизбежных из-за универсальности традиционных СУБД). Плюс к этому логично предположить, что существенно ускорит производительность выпиливание всей незадействованной функциональности СУБД. И к тому же ещё и сократит размер исполняемого файла, да и вообще позволит получить оттюнингованную на свой вкус и оптимизированную под свои требования СУБД, как это делают с ядром линукса.
В общем, наверняка ведь подобная идея уже реализована, вопрос – где?
«Пересобирать» СУБД, что ж ещё, и данные импортировать. Ну или должен как-то прорабатываться вопрос обратной совместимости, закладываться возможность расширять уже имеющиеся таблицы. В любом случае, проблема не является неразрешимой.
Кажется понимаю куда он клонит -
....Такой подход по идее снизит накладные расходы по сравнению с традиционными СУБД (на тот же парсинг SQL-запроса, на двойное копирование данных в сокет/общую память при передаче их между приложением и СУБД, на множество «лишних» проверок, неизбежных из-за универсальности традиционных СУБД). Плюс к этому логично предположить, что существенно ускорит производительность выпиливание всей...
А это не хранимые процедуры случайно? И кто сказал что SQL не кеширует запросы?
Нет, речь не про хранимые процедуры. Речь о том, чтобы жестко зафиксировать структуру базы (структуру таблиц, набор возможных запросов и хранимых процедур) и получить СУБД, работающую исключительно с этой базой в этом заранее заданном формате и ни с какой другой (разве что импорт-экспорт). Суть ведь в чём: в общем случае реляционные СУБД получают на вход SQL запрос в текстовом виде, и запрос этот в общем-то ничем не ограничен: это может быть и удаление таблицы, и изменение её структуры, и начало транзакции и какой-то очень хитрый составной INSERT SELECT запрос с кучей JOIN’ов внутри транзакции, затрагивающий к тому же триггеры. Насколько можно было бы упростить заложенные в СУБД алгоритмы, сколько лишних проверок убрать, если заранее (при генерации/компиляции СУБД под конкретную базу) условиться, что в конкретной базе в помине нет транзакций/триггеров/сложных запросов/чего-то ещё, да ещё и структура таблиц фиксирована? Полагаю, существенно.
Как упражнение для ума вполне подходит. Практическая ценность стремиться имхо к нулю. Такого рода жесткие бд видел только во встраиваемом ПО. Да и там используется SQLlite который и так лайт.
Ну в наше время практическая ценность много у чего стремится к нулю. :) Ибо в наш век выгоднее далеко не самые оптимальные решения экстенсивно компенсировать железом. Я ж не просто так спросил «на правах любопытства».
Резонный вопрос: а нафига? Это же сродни "ща запилю свою ос со своим ассемблером sql и компилятором" -)
Более-менее большие SQL-системы зачастую славятся именно тем, что в каждый конкретный момент времени (запрос) могут в том числе на основании статистики, памяти, загрузки построить разный план выполнения одного и того же запроса. Именно с целью его оптимизации.
Повторюсь, мне видится (утверждать, впрочем, не стану), что в случае жестко зафиксированной структуры базы можно было бы для каждого конкретного случая (ну или для некоторых случаев) существенно упростить (ускорить) заложенные в СУБД алгоритмы. Ну и заодно и получить универсальный инструмент, универсальный «генератор СУБД», которые можно было бы не только на сервера ставить, но и в слабеньких микроконтроллерах умещать.
StrVL: по-сути противоречие в "жесткой... для каждого конкретного " и "универсальный инструмент"
Сам термин СУБД подразумевает множественное число (Базами) [разных] баз, а вот некий "язык применения разных алгоритмов поиска" - может оказаться чем-то таким. В какой-то мере под такое даже натянется LINQ -)
Почему? То же ядро линукса ведь довольно универсальный инструмент, то есть его можно настроить большое число разных платформ и условий. Но в то же время когда оно компилируется под конкретную платформу и условия, то становится «жестко зафиксированным». Так и здесь.
Средний
