Comments 15
под прицелом «database as code»
Переведите, пожалуйста, что понимаете под «database as code» — из статьи это не получается определить.
А от этого и весь смысл статьи как-то утекает.
Вы хотели показать как можно работать с различными СУБД при помощи запросов SQL?
При этом упомянули ORM, но главную проблему ORM (попытка объединить два мира: множеств и скаляров), которую по-человечески не решили и вряд ли решат когда-нибудь, не затронули.
Непонятно что хотели сказать.
Я тогда просто ссылку положу здесь.
Читали такое?
Вьетнам компьютерной науки
Если нет, то очень рекомендую.
Переведите, пожалуйста, что понимаете под «database as code» — из статьи это не получается определить.
Это мое небольшое хобби. Идея простая — если есть «infrastructure as code», «configuration as code» и пр., то где «database as code»? Причем в случае с БД даже не надо выдумывать никаких yml-ов, ведь уже есть настоящий код — это SQL.
Если интересно, то у меня есть еще одна статья на Хабре на эту тему, и небольшой доклад.
Готов ответить на любые вопросы (если они будут).
Так вы на вопрос не ответили. Что вы хотели сказать-то? Ну вот допустим программист или сисадмин проникся концепцией "database as code", что конкретно должно измениться в его работе, что он должен начать делать по-другому?
Раз автор не отвечает, прокомментирую тезисы из статьи.
Модель обвешена умными аннотациями, а где-то за кулисами доблестный ORM генерирует и выполняет тонны какого-то SQL-кода.
А что вы предлагаете, писать SQL вручную? Нет, спасибо, это сложно в поддержке.
А что если взять лучшее из двух миров? Как это сделано в замечательном инструменте с жизнеутверждающим названием Yesql.
а затем прочитайте этот файл, превратив его в обычную Clojure функцию
В PHP можно строки с SQL задавать, без всяких файлов. Это пишет каждый начинающий PHP-шник, который не умеет пользоваться фреймворками с ORM. Или опытный, который точно знает, что делает.
Часто нам приходится искать какие-либо объекты в БД, например, найти таблицу в схеме и изучить ее структуру (какие используются колонки, ключи, индексы, констрейнты и прочее). И от любой графической IDE или маломальского DB-manager'а, в первую очередь, мы ждем именно этих способностей.
В большинстве СУБД нужного результата можно добиться вот таким нехитрым запросом из information_schema
Так IDE именно такой код и выполняют. И ORM тоже.
От IDE и DB-менеджеров мы ждем наглядного представления и удобного редактирования, а не просто текстовые названия чего-то. И да, их используют чтобы такой запрос не писать самому.
Про information_schema знают практически все, в том числе и начинающие, потому что она как раз выводится в любом DB-менеджере.
В итоге такой способ навигации и поиска объектов гораздо более гибок, экономит много времени, позволяет получить именно ту информацию и в том виде, в котором сейчас необходимо
Такой способ занимает много времени, потому что это надо руками писать, даже со сниппетами. Ну и как бы нет, не в том виде, в котором необходимо. Структура БД обычно нужна в наглядном графическом виде, со связями и прочим, с выпадающими списками для редактирования, а не в текстовом результате запроса.
Ну и да, то, что к базе можно сделать запрос, знают практически все.
В то же время правильно и вовремя написанный оператор create table позволит без труда воспользоваться всеми из них
Ввод вручную в правильном синтаксисе это тоже труд. Именно его и избегают использованием графических клиентов. Все знают, что в базе есть CREATE TABLE, просто не все хотят писать его вручную.
Причем мы можем выполнять операции не только над объектами БД, но и над самой СУБД, например "убить" процесс, освободить какую-либо область памяти, включить трассировку
Я что-то сомневаюсь, что SHOW PROCESSLIST или аналог это команда, неизвестная для большинства разработчиков. А из знания о ней можно предположить и существование других функций.
Ну а информацию об объектах и связях между ними мы уже знаем как получить.
Приведем небольшой пример того, как это могло бы выглядеть, с использованием PlantUML и демонстрационной база данных для PostgreSQL (слева SQL-запрос, который сгенерирует нужную инструкцию для PlantUML, а справа результат)
Да, только это дольше.
Вместо того, чтобы воспользоваться IDE, надо изучить синтаксис PlantUML, составить запрос, и воспользоваться PlantUML. Какая в этом цель?
А если немного постараться, то на основе ER-шаблона для PlantUML можно получить что-то сильно похожее на настоящую ER-диаграмму
А если использовать DB-manager, то даже и стараться не надо. MySQL Workbench это точно умеет, MS SQL тоже, для остальных СУБД наверно тоже кто-то аналогичные инструменты сделал.
Т.о., вооружившись каким-либо сборщиком метрик (Telegraf, Metricbeat, Collectd), который умеет выполнять кастомные sql-запросы, хранилищем этих метрик (InfluxDB, Elasticsearch, Timescaledb) и визуализатором (Grafana, Kibana), можно получить достаточно легкую и гибкую систему мониторинга. Как, например, это сделано в pgwatch2
Что все и делают. Либо сами, либо используют инструменты типа pgwatch2 или Enterprise Manager. А если сами не делают, значит не понимают, что эта информация означает, и визуализатор это не исправит.
Итого, все что описано в статье, давно всем известно и везде применяется.
Итого, все что описано в статье, давно всем известно
Данная статья задумывалась как обновленная и более развернутая расшифровка одной из частей моего доклада с одноименным названием. Если здесь все понятно, то это хорошо.
и везде применяется
Идея не только в том, что везде используется SQL-код, а что относиться к нему стоит как к настоящему коду.
А что мы делаем с кодом — храним его в git'е, настраиваем всякие пайплайны чтобы им управлять, делаем ревью и вот это все. При чем это относится и к коду приложений и инфраструктурному коду.
В database as code тоже идея состоит в том, что весь SQL-код проходит через репозиторий (не только миграции). Написали запрос, закомитили, сделали merge request и он пошел по пайплайну.
А именно:
— запустились какие-то линтеры
— сделали ревью
— автотесты (почему бы и нет — github.com/dimitri/regresql)
— обновились доки и диаграммы в них
— в IDE/Manager добавилась новая закладка, где смотреть его результаты в более удобном виде, делать выгрузки всякие
— при необходимости начали собираться метрики на базе результатов запроса
— появился новый дашборд в Графане/Кибане на основании этих метрик
— и пр.
А что мы делаем с кодом — храним его в git'е, настраиваем всякие пайплайны чтобы им управлять, делаем ревью
В database as code тоже идея состоит в том, что весь SQL-код проходит через репозиторий
Так собственно об этом и был изначальный вопрос — какой конкретно код вы предлагаете программисту хранить в git-е? Тот, который ORM генерирует? Это никому не нужно. Его именно потому и сделали генерируемым, а не захардкоженным, потому что это удобно.
Это не говоря уже про динамический SQL, где число джойнов и условий в WHERE зависит от фильтров, заданных в интерфейсе. Предлагаете в репозитории хранить все возможные варианты?
запустились какие-то линтеры
Линтеры нужны, чтобы найти ошибку до выполнения кода, причем в основном ошибку в типах. В SQL довольно сложно сделать ошибку в типах, а уж коммитить SQL, который ни разу не запускался, это какая-то крайне исключительная ситуация.
сделали ревью
Ревью не надо делать, если генератор запросов проверен и протестирован. Ревью логики построения запроса лучше проверять в виде кода на языке программирования. Кстати про ревью, сырой SQL сложен в поддержке, вы почему-то это упорно игнорируете.
автотесты
Автотесты прекрасно работают с кодом, который этот SQL генерирует, для этого не надо хранить его в репозитории.
при необходимости начали собираться метрики на базе результатов запроса
Метрики нужны во время выполнения запроса, а не во время появления его в репозитории. И обычно нужны не все подряд, а вполне определенные, что задается кодом.
в IDE/Manager добавилась новая закладка, где смотреть его результаты в более удобном виде, делать выгрузки всякие
Да, получится несколько сотен закладок, и быстрее руками скопировать в редактор, чем искать среди них. Тем более что 99% запросов используют параметры — конкретные id или строки, и все равно без редактирования его не запустить.
обновились доки и диаграммы в них
Я не очень понимаю, что вы имеете в виду, и почему нельзя сделать то же самое для любого другого кода.
В литературе этот прием называется гиперболой.Гипербола это преувеличение, а не использование несоответствующих фактов. У допетровской эпохи есть конкретные даты, и именно поэтому у Вас поинтересовались достаточностью образования.
С литературной же точки зрения можно было использовать формулировки «предыдущей эпохи», «доГейсовой эпохи» (или иное значимое в обсуждаемой категории имя).
После фразы «допетровской» по ссылке ожидался некий исторический каламбур восходящий к 17 веку. Но увы.
9 лет для IT срок конечно не малый, но, в обсуждаемой области ORM каких то прорывных тенденций я не вижу.
Да, и это одна из главных идей поста (по крайней мере я так планировал).
Гипербола это преувеличение, а не использование несоответствующих фактов.
Т.е. фразу «мы не виделись сто лет» могут употреблять только долгожители? Я уже молчу про «со скоростью пули», «задушить в объятьях» и пр.
После фразы «допетровской» по ссылке ожидался некий исторический каламбур восходящий к 17 веку. Но увы.
Приношу «тысячу извинений», что не оправдал Ваших надежд.
Вообще не думал, что такой безобидный речевой оборот вызовет столько полемики.
Вообще хорошо что появляются такие статьи. Через год об авторах уже никто не вспомнит, а зерно сомнения уже посажено и ростки здравого смысла уже всходят.
Ой, опять литературный прием, да еще и заезженный…
«Database as Сode» Experience