Comments 7
А точно нужен компилятор? Имхо это можно было бы реализовать куда меньшими затратами в виде EDSL-библиотеки на любом существующем языке программирования, например на C#:
var (e1, e2) = CreateEntities("entity1", "entity2");
var ref1 = CreateReference("ref1", "nvarchar");
Entity(e1).HasAttribute("attr", "int");
var rel = CreateRelationship("rel", e1, ref1);
DSL предназначен для системных аналитиков, которые хорошо владеют SQL, но в лучшем случае имеют поверхностное представление о C#. Не хотелось бы даже привлекать Python, котрым системные аналитики (в отличие от аналитиков данных) владеют плохо. Лучше всего было бы оставаться в экосистеме SQL, а именно, внедрить DSL в PostgreSQL
Неидеальное решение, реализуемое за пару вечеров, лучше, чем идеальное, которое скорее всего никто никогда не сделает
Чувствуется, что Вы вообще не в теме, и не смотрели репозиторий по ссылке в статье. 6NF экономит огромные человеческие и вычислительные ресурсы при внесении изменений в хранилища данных. И это веский стимул для разработки DSL! Но из-за отсутствия удобных инстпрументов 6NF используется в очень небольшом количестве компаний. Писать километровые запросы для 6NF на SQL очень трудоемко и чревато ошибками.
А то, что Вы предложили, - вообще не решение, а ухудшение,так как вместо километровых запросов на SQL Вы по сути предлагаете писать еще более трудоемкие программы на C# при отсутствии разработчиков на C# в штате. Ни за какую пару вечеров это сделать невозможно. Каждое изменение в структуре данных придется анализировать и программировать заново, так как набор параметров будет всякий раз совершенно разный. Плюс к тому, СУБД не понимает C#, а значит всё-таки придется делать транслятор с C# на SQL или другие языки, которые поддерживает СУБД, либо вносить изменения в ядро СУБД на языке C (для PostgreSQL), что равно по трудоемкости разработке транслятора с DSL.
Я посмотрел репозиторий по ссылке и прочитал все примеры, которые вы привели. DSL действительно выглядит гораздо лаконичнее. У меня, однако, возникают вопросы к вашей аргументации.
Вы говорите, что эта штука "экономит огромные ресурсы", но никто ей не пользуется, потому что нет тулинга. Так не бывает! Если бы этот подход действительно так хорошо работал, кто-нибудь бы уже написал весь необходимый тулинг и сэкономил бы своей компании миллионы. Ну или разбогател бы, продавая коробочный продукт. Ситуация, что среди всех разработчиков мира просто никто не догадался, но вот вы открыли миру глаза, и сейчас народ побежит бесплатно реализовывать вашу задумку, представляется маловероятной. Скорее всего, это узкоспециализированная задача, нужная малому кругу лиц. Отсутствие активности вокруг вашей статьи косвенно подтверждает эту версию.
Если вы прочитаете мой первый коммент более внимательно, увидите, что я не предлагаю писать конкретно на C# - я взял его исключительно в качестве примера. Подойдет любой популярный язык, будь то Python, JS, Haskell или что угодно еще. Вы просто пишете несколько библиотечных функций, и:
Трансляция становится тривиальной - вам не нужны ни лексер, ни парсер, просто собираете SQL-запрос в виде строки
IDE автоматом будет подсказывать ваши функции, проверять типы и т.д.
Выхлоп SQL-билдера из пункта 1 можно скормить в любой ORM или БД-адаптер
В противном же случае вам понадобится сделать не только полноценный транслятор (это не очень сложно, за несколько дней работы средний специалист управится), но и поддержку со стороны IDE (подсказки, проверки) - а это уже на порядок сложнее. Про то, чтобы заставить существующую RDBMS принимать ваш DSL нативно, я вообще молчу. Если вы хотите действительно реализовать нечто подобное - наиболее реалистичный вариант это нанять человека и заплатить ему хороших денег.
Если бы этот подход действительно так хорошо работал, кто‑нибудь бы уже написал весь необходимый тулинг и сэкономил бы своей компании миллионы.
Нет, хороший тулинг требует усилий на его разработку и других трудновыполнимых условий. Поэтому обходятся вечными "временными решениями" в стиле тяп-ляп. Поскольку разрабатывать хранилище данных с методологией 6NF непосредственно на SQL чрезвычайно трудозатратно и чревато ошибками, то берут экселевские таблички с метаданными и обрабатывают их на Python. Тоже трудозатратно, но не так ужасно, как на SQL. Системные аналитики, которые готовят таблички с метаданными, Python'ом практически не владеют, но хорошо владеют SQL. Поэтому нужны еще и разработчики на Python. И всё равно технология 6NF+Excel+Python+SQL слишком сложна для большинства компаний. DSL решил бы эту проблему - он похож на SQL, и удобен для системных аналитиков.
Ну или разбогател бы, продавая коробочный продукт.
На таких вещах как компилятор, разбогатеть невозможно. Спиратят, скопируют.
Ситуация, что среди всех разработчиков мира просто никто не догадался, но вот вы открыли миру глаза, и сейчас народ побежит бесплатно реализовывать вашу задумку, представляется маловероятной.
Действительно, никто пока не догадался сделать DSL для 6NF. Есть красивая и удобная (хотя местами странная и переусложненная) ERD для 6NF под названием Anchor Modeler, которая выдает непонятный программный код огромного объема на SQL Server (энтузиасты сделали плагины и для других СУБД). Но именно DSL для 6NF нет в природе. Вы, наверное, не догадываетесь, сколько есть прекрасного оупенсорсного софта. Яркий пример - PostgreSQL.
Скорее всего, это узкоспециализированная задача, нужная малому кругу лиц.
В России 6NF (под брендом Anchor Modeling) используют Авито, Яндекс Такси и ВТБ. Это не значит, что другим компаниям это не нужно. Но применение 6NF без DSL сложно, мало какая компания может себе это позволить, и поэтому нет хайпа. А раз нет хайпа, то мало кто вообще знает про 6NF и тем более понимает ее.
Отсутствие активности вокруг вашей статьи косвенно подтверждает эту версию.
Вовсе нет. Просто чем сложнее и дальше от быта тема, тем меньше активности на Хабре. Миллион статей про Arduino и нелепые требования к резюме, и полторы статьи про хранилища данных.
Вы просто пишете несколько библиотечных функций
Попробуйте сделать MVP. Может быть, его разовьют. Python выглядит подходящим для такой роли и имеет весьма изощренные способы работы со строками.
DSL для битемпоральной шестой нормальной формы с UUIDv7