Толочь воду в ступе
Пост навеян свежим ПФП. Статья про circumflex, вот этим вот:
// Выбрать все города Швейцарии, вернуть Seq[City]:
SELECT (ci.*) FROM (ci JOIN co) WHERE (co.code LIKE ”ch”)
ORDER_BY (ci.name ASC) listСтоило ли огород городить, если на выходе всё равно получается нечто, что ( Read more... )
// Выбрать все города Швейцарии, вернуть Seq[City]:
SELECT (ci.*) FROM (ci JOIN co) WHERE (co.code LIKE ”ch”)
ORDER_BY (ci.name ASC) listСтоило ли огород городить, если на выходе всё равно получается нечто, что ( Read more... )
Если же их вдруг надо как-то обсчитывать, то проще и быстрее это в самой базе и сделать, а не таскать записи по памяти или того хуже, сети.
Типичное использование --- получить из базы рекордсет, преобразовать к списку типизированных сущностей, засунуть в шаблонизатор и отдать строку на веб. И обратно --- получить набор строк с веба, засунуть в типизированные сущности и засунуть в базу, которая сама по себе типизируется.
Если срезать немного углов, то можно получить из базы прямо сразу XML и отдать его на веб:
select xmlelement(name person, xmlattributes(p.age as a age, p.salary as salary)) from person p where ...
Запросы такие генерятся в рантайме из метаинформации, которая засасывается из базы. Прочие части CRUD тоже генерируются, соответственно консистентность базы запросам достигается сама собой.
Ошибки в рантайме возможны, да --- но их все равно нужно проверять, если мы работаем с базой --- ведь кто-то мог и саму базу удалить.
Если вдруг ВНЕЗАПНО понадобится отобразить эти записи на объекты языка, всегда можно сделать, например,
instance Read Something
Все равно же нам обычно нужен в контексте какого-то бизнес-метода не весь объект целиком, а какой-то его разрез, о котором этот метод знает.
Я это все к чему? Я в хаскелле забил эту ботву типизировать, потому что непонятно, зачем оно нужно. Если же вдруг понадобится, но явно не всю базу, а отдельные разрезы отдельных таблиц в каких-то отдельных случаях.
Reply
> Запросы такие генерятся в рантайме из метаинформации, которая засасывается из базы. Прочие части CRUD тоже генерируются, соответственно консистентность базы запросам достигается сама собой.
Вот! :) Это ровно то, что я и предлагаю :)
Только у меня вся генерация происходит на компиляции проекта, а такой "метаинформацией" служит DSL.
PS: Десятое правило Гринспена: "Любая достаточно сложная программа на C или Фортране содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp"
Reply
Только у меня вся генерация происходит на компиляции проекта, а такой "метаинформацией" служит DSL.
Да зачем он, если метаинформация сама по себе в БД уже есть?
PS: Десятое правило Гринспена: "Любая достаточно сложная программа на C или Фортране содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp"
Ничего похожего на лисп тут нету, да и метапрограммирование как-то тоже не пригодилось
Reply
Ну это смотря что первично: схема бд или типы языка. В принципе, ничто не мешает и по описанию таблицы объекты генерить.
> Ничего похожего на лисп тут нету, да и метапрограммирование как-то тоже не пригодилось
Потому что весь процесс происходит в рантайме. А метапрограммирование пригодилось бы для генерации "instance Read Something" по метаданным из базы, которые иначе при неконсистентности скомпилируются нормально, но дадут ошибку на рантайме.
Reply
У меня нет шаблонизатора, а есть структура проектов с файлами, которые надо уметь редактировать и всё такое.
Плюс дополнительные объекты - системы сборки, привязанные к сообщениям об ошибках и архитектурам процессоров.
И тп, и тд.
Это CAD, не опердень.
Поэтому у меня так, а не иначе. ;)
Reply
Reply
Мне язык запросов в виде LINQ выражений нравится ранними проверками, плюс не надо учить ещё один ЯП.
Reply
Leave a comment