• Компиляция СУБД по описанию структуры базы (по аналогии с bison) – такое существует?

    @StrVL Автор вопроса
    Почему? То же ядро линукса ведь довольно универсальный инструмент, то есть его можно настроить большое число разных платформ и условий. Но в то же время когда оно компилируется под конкретную платформу и условия, то становится «жестко зафиксированным». Так и здесь.
  • Компиляция СУБД по описанию структуры базы (по аналогии с bison) – такое существует?

    @StrVL Автор вопроса
    Ну в наше время практическая ценность много у чего стремится к нулю. :) Ибо в наш век выгоднее далеко не самые оптимальные решения экстенсивно компенсировать железом. Я ж не просто так спросил «на правах любопытства».
  • Компиляция СУБД по описанию структуры базы (по аналогии с bison) – такое существует?

    @StrVL Автор вопроса
    «Пересобирать» СУБД, что ж ещё, и данные импортировать. Ну или должен как-то прорабатываться вопрос обратной совместимости, закладываться возможность расширять уже имеющиеся таблицы. В любом случае, проблема не является неразрешимой.
  • Компиляция СУБД по описанию структуры базы (по аналогии с bison) – такое существует?

    @StrVL Автор вопроса
    Повторюсь, мне видится (утверждать, впрочем, не стану), что в случае жестко зафиксированной структуры базы можно было бы для каждого конкретного случая (ну или для некоторых случаев) существенно упростить (ускорить) заложенные в СУБД алгоритмы. Ну и заодно и получить универсальный инструмент, универсальный «генератор СУБД», которые можно было бы не только на сервера ставить, но и в слабеньких микроконтроллерах умещать.
  • Компиляция СУБД по описанию структуры базы (по аналогии с bison) – такое существует?

    @StrVL Автор вопроса
    Нет, речь не про хранимые процедуры. Речь о том, чтобы жестко зафиксировать структуру базы (структуру таблиц, набор возможных запросов и хранимых процедур) и получить СУБД, работающую исключительно с этой базой в этом заранее заданном формате и ни с какой другой (разве что импорт-экспорт). Суть ведь в чём: в общем случае реляционные СУБД получают на вход SQL запрос в текстовом виде, и запрос этот в общем-то ничем не ограничен: это может быть и удаление таблицы, и изменение её структуры, и начало транзакции и какой-то очень хитрый составной INSERT SELECT запрос с кучей JOIN’ов внутри транзакции, затрагивающий к тому же триггеры. Насколько можно было бы упростить заложенные в СУБД алгоритмы, сколько лишних проверок убрать, если заранее (при генерации/компиляции СУБД под конкретную базу) условиться, что в конкретной базе в помине нет транзакций/триггеров/сложных запросов/чего-то ещё, да ещё и структура таблиц фиксирована? Полагаю, существенно.
  • Где найти плату защиты от КЗ для AC 220V с настраиваемым током?

    @StrVL Автор вопроса
    А самим сделать не было идеи? У меня уже как минимум две.

    Конкретно данная задача, как, скажем, разработка и конструирование самодельного паяльника, мультиметра, ЛАТРа, лично у меня не вызывает энтузиазма, хочется купить готовое изделие и не «распыляться». Каждому своё. :)

    От чего? :)

    Да хоть от того, чтобы сдуру в четыре часа ночи запаять диод не той стороной и не заметить это недоразумение даже перепроверив всё два раза. Если вы никогда не совершаете ошибок, то могу за вас только порадоваться. :)

    высоковольтных 220V

    Для микроконтроллера и цифровой логики, да и для человека 220V вполне себе «высоковольтные». Во всяком случае «спецэффекты» в случае чего будут весьма неприятными и небезопасными.