Текстовый юникс-вей vs запросы к БД.

Когда vitus_wagner в очередной раз толкает у себя в ЖЖ глобальные идеи на тему "как нам обустроить IT" там всегда всплывает ключевым аспектом unix-way в его аспекте "используем множество мелких программ, увязывая их через текстовый ввод-вывод".

Я же постоянно там на это отвечаю, что счетаю нужным увязывание сделать строго типизированным, чтобы быть уверенным, что это дело не поломается, когда в какой-нибудь мелкой утилите поменяют формат ввода или вывода.
И там же у vitus_wagner как-то было обсуждение, как этот подход скрестить с GUI-программами, потому что у них другая модель, не текстовый ввод-вывод, а ожидание событий от пользователя.

Вот сейчас сижу смотрю на свою почту в Mozilla Thunderbird и понимаю, что мне не хватает там возможности сделать запрос типа "все непрочитанные письма из всех ящиков с сортировкой по дате и отметками к какому из проектов оно относится".

Т.е. если по хорошему, то в любой гуманной проге работающей со большими объемами структурированных данных, подобно реляционной(не обязательно, главное наличие схемы/типов/структуры) БД, должна быть вкручена некая консоль с REPL, где можно было бы на ходу пилить запросы, сохранять их для будущего использования, итд.

Я в самодельном фреймворке, на котором основано несколько штук наших оперденей, сделал похожую вещь - она уже 5 лет используется на полную катушку, вплоть до того, что можно разрабатывать новый функционал вообще не открывая средства разработки - прямо в рабочей проге. (про одну из возможностей Firebird на которой это построено, будет отдельный пост).

Сейчас в бзодотнетовском варианте хотелось бы сделать то же самое, только еще более навороченное, с запоминанием промежуточных результатов, итд (похоже на натуральный REPL, типа GHCi или F# консоли), но это надо мозг расшевеливать будет сильно.


Т.е. основная идея: текстовый unix-way это конечно очень хорошо, но хочется статической типизации.

Автоматический вывод типов запросов и bind-параметров в СУБД

Я знаю, что меня читают люди, использующие всякие разнообразные СУБД.
В связи с этим у меня есть такой хитрый вопрос, связанный с использованием bind-параметров в запросах: насколько распространена среди разных серверов (а так же клиентских либ и компонентов доступа) такая фича, что при парсинге запроса он возвращает список параметров и их типы?

Дело в том, что более-менее напрямую я использую только Firebird и он после prepare возвращает информацию о используемых параметрах и их типах (когда-то в версии 1.5.х, что ли, его плющило на тему вывода типов, но давно было, вроде исправили и вообще я уже забыл что там было).

Т.е. если мы представим селект как функцию вроде select :: p0 -> p1 -> p2 -> ... -> [(f0,f1,...)] то Firebird выводит тип этой функции из текста запроса и информации о таблицах. Это невероятно удобно, т.к. позволяет использовать SQL запрос+пару таблиц с дополнительными метаданными в качестве DSL для описания достаточно большого класса отчетов, покрывающего 90% всех потребностей в опердени. Т.е я из списка параметров и таблицы типа (параметр, юзеровское имя, справочник, формат) генерю UI для ввода этих самых параметров, а из типа результата запроса дельфи автоматом заполняет всю метаинформацию для DBGrid.

Из других СУБД я использую MSSQL и Sqlite, но через ADO.NET, в котором параметры, судя по всему, принципиально не заполняются автоматически и их нужно вносить в DbCommand или SqlCommand вручную. Т.е. я не знаю, умеет ли сервер это делать вообще. Это выбешивает просто невероятно, т.к. работы становится в несколько раз больше. Я уже подумываю написать собственный парсер запросов или вообще DSL с выводом типов и генерацией SQL запросов для описания запросов/датасетов, чтобы не заниматься этой многословной хренью.

PostgreSQL заполняет bind-параметры после prepare, но непонятно кто это делает - сервер, клиентская либа или компоненты доступа. И на сервер он гонит запросы плейн-текстом, т.е. запросто может оказаться что подстановка вообще делается клиентской либой в лоб, без всякого вывода типов.

А как вообще принято эти параметры заполнять и кто это делает - сервер, клиентская либа, компоненты доступа или вообще вручную по жизни?

Допился

Сижу читаю книжку по F# и параллельно слушаю "139. PAGANINI - CAPRICE # 11 IN C (ANDANTE - PRESTO)". Ловлю себя на мысли о том, что структура музыки у меня как-то ассоциируется со структурой сложной программы в функциональном стиле, и теперь пытаюсь придумать этому рациональное объяснение. Что-нибудь вроде того, что музыка, как я когда-то читал, имеет фрактальную структуру, причем чем более ближе к классической, тем более сложная эта структура, а программы, если по хорошему, должны описывать сами себя и вообще быть написаны сами на себе, чтобы каждая новая фича упрощала реализацию последующих и была доступна не только пользователям, но и программистам.

Производственное

Опердень powered by lambda-calculus!

Дивный новый мир.

У меня в мозиле после обновления сломался плагин ImgLikeOpera, которым я прятал картинки и показывал только по мере надобности.
Веб заиграл новыми красками, оказывается на сайтах дофига картинок, в жж множество ссылок сопровождается пиктограммами, а самое смешное, что при добавление RSS фидов из мозилы в гугл-ридер все таки работает - там нужно было нажать на ссылки вверху, которые с выключенными картинками не видны вообще:)