Состояние экосистемы Common Lisp на 2015 год

Я так понимаю, что den73 хочет просто сказать, что, дескать, «есть такие-то переменные с такими-то значениями, пожалуйста, используй их по всей функции».

Он предлагает впихивать неявный let внутрь, то есть

{
  let x = 1;
  body1 ...
  let y = 2;
  body2 ...
}

->

{
  (let ([x 1])
    body1 ...
    (let ([y 2])
      body2 ...))
}

если вместо этих всяких cl-perec гораздо более естественным и красивым решением было бы создание СУБД на Lisp и для Lisp, типа AllegroCache?

Потому что таких СУБД нет.

Это просто дополнительный мартышкин труд и зарабатывание геморроя при обеспечении синхронизации описания модели на Lisp и физическим представлением.

Модель на лиспе все равно будет нужна, иначе как ты будешь работать с данными? Вопрос исключительно в том, можешь ли ты упростить потом работу с БД или нет на основе информации из этой модели.

так делать нельзя

А как же в Scheme

(begin
  (define x 1)
  body1 ...
  (define y 2)
  body2 ...)

и никаких противоречий

«Выбрать из БД все описания файлов, если эти файлы существуют на текущей машине». ORM в этом случае проверку на размер завернёт в SQL, а проверку на существование файла применит к получаемым данным.

Такие системы нельзя воспринимать сколь-нибудь серьёзно. Это отличный пример уродливой и ненадёжной архитектуры, потому что в БД могут быть описания несуществующих файлов, а-ля «висячие указатели». Ты намеренно предлагаешь похерить целостность данных, на что, лично я, пойтить не могу. И никогда не соглашусь :-)

Пример из жизни: выбрать остатки по номенклатуре в определённой группе.

Да пожалуйста. У меня будет 2 таблицы: grp (группа) и item (элемент номенклатуры), связанные отношением «один-ко-многим», определённые как

create table grp (id serial not null, nm text, parent integer,
  foreign key(parent) references grp(id));

create table item (id serial not null, nm text, grp integer)
  foreign key (grp) references grp (id);

И для получения поля SELECT из базы делать?

И для получения данных выполню SELECT: with recursive g as (select * from grp where id = %ИДЕНТИФИКАТОР-ГРУППЫ% union all select grp.* from grp join g on (grp.parent = g.id)) select * from g;

Всё :-)

И для получения данных выполню SELECT:

with recursive g as (select * from grp where id = %ИДЕНТИФИКАТОР-ГРУППЫ% union all select grp.* from grp join g on (grp.parent = g.id)) select * from g;

Всё :-)

Ну, то есть, как ты уже понял, полный запрос будет таким:

with recursive g as
(select * from grp where id = %ИДЕНТИФИКАТОР-ГРУППЫ%
 union all
 select grp.* from grp join g on (grp.parent = g.id))
select item.* from g join item on (g.id = grp);

:-)

Потому что таких СУБД нет.

Ах да, Postgres был изначально на Lisp, потом всё переписали на C, попутно попробовав C++, но, поплевавшись, сделали всё на C :-)

Модель на лиспе все равно будет нужна, иначе как ты будешь работать с данными?

Через хорошо спроектированный DSL, называемый SQL :-)

Вопрос исключительно в том, можешь ли ты упростить потом работу с БД или нет на основе информации из этой модели.

Нет, любая попытка сделать абстракцию над SQL обычно заканчивает абасракцией :-)

Тут define не вводит новую область видимости. Оно, условно говоря, добавляет идентификатор в текущую. В результате симметричность сохраняется. Если же вводить область вниз, как предлагает дэн, - получаем непредсказуемый сайд-эффект во время экспанда.

Ты намеренно предлагаешь похерить целостность данных

В предполагаемом тобой определении «целостности» бд с целостными данными не существует вообще.

Ах да, Postgres был изначально на Lisp, потом всё переписали на C, попутно попробовав C++, но, поплевавшись, сделали всё на C :-)

Как это отменяет сказанное мной?

Через хорошо спроектированный DSL, называемый SQL :-)

Я спрашиваю, как ты будешь работать с данными, полученными в результате SQL-запроса? Их же надо разобрать, обработать и как-то применить - например, вывести пользователю в определенном виде: отчетик там нахуярить, табличку, treeview какой-нибудь. Или тебе ничего не нужно кроме как неформатированной портянкой выблевать их на stdout? Ну тады тебе вообще кроме SQL ничего не надо. Разве что набор скриптиков на баше, которые будут запросами в бд хуячить.

Через хорошо спроектированный DSL, называемый SQL :-)

алсо, называть вот этот кусок нечитабельного и неподдерживаемого дерьма:

with recursive g as
(select * from grp where id = %ИДЕНТИФИКАТОР-ГРУППЫ%
 union all
 select grp.* from grp join g on (grp.parent = g.id))
select item.* from g join item on (g.id = grp);

примером «хорошо спроектированным DSL» может только в конец упоротый.

В предполагаемом тобой определении «целостности» бд с целостными данными не существует вообще.

В моём определении БД содержат данные, которые могут быть получены с помощью SQL, а не метаданные файлов на клиенте :-) Бугага :-)

Как это отменяет сказанное мной?

Это дополняет, просто подчёркивая провал использования Lisp для написания СУБД :-)

Я спрашиваю, как ты будешь работать с данными, полученными в результате SQL-запроса?

Я SQL-запросы выполняю в контекстах, где заведомо известно какие данные лежат в каком столбце. Задача выбора данных по имени столбца смущать не должна даже пионэров моделей данных типа ООП адептов :-)

примером «хорошо спроектированным DSL» может только в конец упоротый.

Ты из какой бурсы вылупился, аналитик ты наш? :-) Этот SQL-запрос - элементарщина, не понимать который может только недоучка :-)

Этот SQL-запрос - элементарщина

Вот только на каждый (in-group ...) приходится писать 4 строки левой пурги. А если таких условий на три колонки (номенклатура в группе ..., контрегнт в группе ..., продавец в группе ...)?

К слову, в ORM я могу и указать, что «в группе» можно проверять не на клиенте, а на сервере. И тогда не меняя код запроса (останется in-group) получу скорость ручного запроса PostgreSQL.

Вот только на каждый (in-group ...) приходится писать 4 строки левой пурги. А если таких условий на три колонки (номенклатура в группе ..., контрегнт в группе ..., продавец в группе ...)?

В этом случае создаётся вид, объединяющий номенклатуру, контрагента, продавца, и запрос в 4 строки выполняется уже применительно к этому виду. :-) Элементарщина. :-) А можно и 3 (или одну, но тогда лучше сначала вид) функции, вроде такой:

create or replace function items_in_group(in_grp integer)
  returns setof item
  language sql as
$$
with recursive g as (
  select * from grp where id = in_grp
  union all
  select grp.* from grp join g on (grp.parent = g.id))
select item.* from g join item on (g.id = grp);
$$;

select * from items_in_group(3) where %что душе угодно%

К слову, в ORM я могу и указать, что «в группе» можно проверять не на клиенте, а на сервере. И тогда не меняя код запроса (останется in-group) получу скорость ручного запроса PostgreSQL.

Ну ORM - это просто ещё один уровень косвенности, поэтому такие плюшки имеют место быть. Но за этот уровень косвенности нужно платить последствиями возможных багов в этом ORM и дополнительным головняком на сопровождение усложнённого ORM кода. :-)

Причем тут элементарщина или нет? Речь о том, что это классический пример говно-кода.

В моём определении БД содержат данные, которые могут быть получены с помощью SQL, а не метаданные файлов на клиенте :-) Бугага :-)

В твоем определении бд содержит актуальные и корректные данные. Что, конечно, в реальности практически всегда не так. Иди прочитай определение целостности и не неси ересь.

Я SQL-запросы выполняю в контекстах, где заведомо известно какие данные лежат в каком столбце.

Ну так работать-то с ними как? Ты так и не ответил. Вот у тебя есть выхлоп скл-запроса - какая-то коллелкция сформированных бд строк. Что ты дальше с ней будешь делать?

Это дополняет, просто подчёркивая провал использования Lisp для написания СУБД :-)

То есть писать СУБД на лиспе - плохо и использовать лисп для работы с СУБД - тоже плохо, тогда наверное вообще стоит выкинть лисп и писат ьвсе на сишке? На ней же хорошо? Вон, постгрес написали.

В этом случае создаётся вид, объединяющий номенклатуру, контрагента, продавца, и запрос в 4 строки выполняется уже применительно к этому виду. :-) Элементарщина. :-) А можно и 3 (или одну, но тогда лучше сначала вид) функции, вроде такой:

Прекрасно. Теперь назови хоть одну причину, по которой надо плодить невменяемые неподдерживаемые портянки на SQL, если можно то же самое няшно и лаконично выразить в рамках ОРМа при прочих равных?

ORM - это просто ещё один уровень косвенности, поэтому такие плюшки имеют место быть

Да!

Но за этот уровень косвенности нужно платить последствиями возможных багов в этом ORM и дополнительным головняком на сопровождение усложнённого ORM кода

То же относится и к SQL. В базах данных тоже бывают баги и SQL как правило сложнее, чем код на лиспе.

В базах данных тоже бывают баги

Угу, и от добавления багов ORM к багам SQL ситуация заметно улучшится, конечно.

На самом-то деле, SQL является одной из вершин достижений IT-индустрии, сочетая наибольше количество продвинутых концепций. Эти концепции не просто «есть», они ещё и скоординированы между собой. SQL превосходит и лисп в том числе. Перечисляю (надеюсь, не забыл ничего)

• REPL
• макросы (через eval)
• ООП с наследованием (через view)
• декларативное программирование
• автоматическое управление памятью
• автоматизация написания быстрых алгоритмов доступа к данным
• image-based development в стиле Smalltalk, но можно сделать и в виде SLIME
• обработка ошибок: вычисления с обратимыми побочными эффектами (хаскель курит в сторонке)
• многопоточность

Проблема лишь в том, что SQL слегка застрял в своём развитии. Но не настолько, чтобы вымереть: он применяется начиная от инфраструктуры ОС и заканчивая интернет-магазинами (на клиенте и на сервере).

Поэтому, абстракции поверх SQL - это тупость, неосиляторство, забивание гвоздей микроскопом или карго-культ - выбери нужное для себя и подчеркни.

так делать нельзя, потому что может быть: (defmacro yoba () `(let x 1))

Ты просто тупой баран. У меня уже сотни (или тысячи функций) где так сделано без всяких проблем. Например, вот здесь

Твой ответ, да и вообще вся дискуссия здсь - демонстрация неадекватности, тупости или зомбированности лисперов.

Они могут годами надевать трусы через голову и не видеть, что это неудобно и неправильно.

Потому-то лисп и потерял свой трон.

автоматическое управление памятью

Такое «автоматическое» управление памяти если в любом языке, вообще-то. Даже в сишке.

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

Поэтому, абстракции поверх SQL - это тупость, неосиляторство, забивание гвоздей микроскопом или карго-культ - выбери нужное для себя и подчеркни.

Нет, это просто экономия времени.

Ты просто тупой баран. У меня уже сотни (или тысячи функций) где так сделано без всяких проблем.

Ну просто ты туповат, что поделать.

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

Они могут годами надевать трусы через голову и не видеть, что это неудобно и неправильно.

Так ты в зеркало то посмотри. Тебе объясняют, что предложенное тобой решение - говно. Объясняют с фактами, против которых не попрешь. И даже объясняют, как надо правильно. Но ты уперся рогом и повторяешь «а я в домике» раз за разом, вместо того, чтобы мозг включить.

Только в репозитории, который я указал, надо искать слово perga, а не proga. После годичной эксплуатации proga я понял некоторые ошибки дизайна, но патчить production код было страшно и некогда, поэтому пришлось выпустить вторую версию под новым именем. Теперь та программа умерла и можно будет свести версии в одну.

Тебе объясняют, что предложенное тобой решение - говно.

Напрасно ты думаешь, что ваши объяснения я собираюсь читать :)

Тогда продолжай одевать штаны через голову, чо.

После годичной эксплуатации proga я

А вот здесь мы и видим причину, по которой лисп потерял свой трон. Для типичного лиспера других программистов не существует, он пишет костыли для себя и никого больше.

Поэтому, абстракции поверх SQL - это тупость, неосиляторство, забивание гвоздей микроскопом

Да? Вот типовая задача (многократно решённая через «абстракции поверх SQL»). Есть таблица бухгалтерских проводок. Колонки

- дебет счёт
- дебет аналитика1
- дебет аналитика2
- дебет аналитика3
- кредит счёт
- кредит аналитика1
- кредит аналитика2
- кредит аналитика3
- сумма

типы значений «аналитика» зависят от значения «счёт». Например, если счёт = «10.1», тогда аналитика1 FOREIGN REFERENCE goods.id, аналитика2 FOREIGN REFERENCE warehouse.id, аналитика3 IS NULL.

Нужны запросы вида «выбрать проводки, где аналитика1 ссылается на nomenclatura и равна 3, а аналитика3 ссылается на строку какой-то таблицы и в той строке date > '20150101'»

Как будешь делать на чистом SQL без «абстракции поверх»?

Причем тут элементарщина или нет? Речь о том, что это классический пример говно-кода.

А кто ты есть такой, чтобы определять «говнокод»? Кому какое дело до твоей аналитики? Единственно, что можно брать в расчёт, это факты. А факты говорят о том, что полным говном являются ORM и Lisp, от которого отвернулись уже почти что все :-)

Ну так работать-то с ними как? Ты так и не ответил. Вот у тебя есть выхлоп скл-запроса - какая-то коллелкция сформированных бд строк. Что ты дальше с ней будешь делать?

Это зависит от контекста. Где-то полученные из строки результата запроса данные я вставлю в специальное место в шаблоне (без затрат на конверсию из char* в «родной» тип данных языка или класс, определённый программистом), а где-то конвертну (что очень редко) данные в «родной» тип для расчётов. Последний случай очень редок из-за того, что все необходимые расчёты почти всегда можно сделать на стороне СУБД с помощью SQL, PL/SQL, или C в конце концов. Модели на Lisp - это красиво, но геморрно. Надо бы СУБД на Lisp написать, тогда будет кошерно. Но тот же автор weblocks, (он же автор cl-cont) который знаменитый лиспер, почему-то для своего нового стартапа RethinkDB выбрал C++, а не Lisp :-) Улавливаешь, ты? :-) А вот AllegroCache, например, судя по концепции, очень хорошая штука. Гораздо более оправданная и заслуживающая уважение, чем эти ваши говнястые ORM все вместе взятые :-)

Как будешь делать на чистом SQL без «абстракции поверх»?

Три варианта: юнионом по числу разных возможностей. Selectable хранимыми процедурами. Генерацией sql кода.

Прекрасно. Теперь назови хоть одну причину, по которой надо плодить невменяемые неподдерживаемые портянки на SQL, если можно то же самое няшно и лаконично выразить в рамках ОРМа при прочих равных?

Называю :-) Кому нужны все эти твои задротные ORM, которые на фоне стандартного SQL выглядят бледно-серым дерьмецом? По-мимо того, что SQL - это стандарт, он же отличный DSL, который используется как язык для работы с данными в любой современной СУБД промышленного уровня. Так что «невменяемыми» и «неподдерживаемыми» портянками являются куски кода для удовлетворения мало кому известных ORM, нежели чем стандартный SQL :-)

То же относится и к SQL. В базах данных тоже бывают баги и SQL как правило сложнее, чем код на лиспе.

Баги бывают везде. Только вот над парсером и оптимизатором запросов в том же Postgres уже многие годы работает огромная команда, которая плотно общается между собой что в списке рассылки, что на всевозможных конференциях. Команда, которая хорошо мотивированна финансово. А вот над ORM, тем более, написанном на Lisp, работает 1-2.5 энтузиаста. Мой опыт использования различных ORM (не на Lisp), показывает, что сия «няшность» лишь выкручивает руки всеми возможными способами, ведёт к усложнению и бесконечной охотой за багами. Это уже настолько достало, что вместо багрепорта автору очередного гомна хочется писать послания с отсылкой :-)

типы значений «аналитика» зависят от значения «счёт». Например, если счёт = «10.1», тогда аналитика1 FOREIGN REFERENCE goods.id, аналитика2 FOREIGN REFERENCE warehouse.id, аналитика3 IS NULL.

Элементарный триггер целостности (CONSTRAINT TRIGGER).

Нужны запросы вида «выбрать проводки, где аналитика1 ссылается на nomenclatura и равна 3, а аналитика3 ссылается на строку какой-то таблицы и в той строке date > '20150101'»
Как будешь делать на чистом SQL без «абстракции поверх»?

Таблица бухгалтерских проводок будет дополнена столбцами «куда ссылается аналитика1», «куда ссылается аналитика3» и вышеупомянутый триггер будет обеспечивать целостность данных в этих столбцах. Ни у дальше SQL-запросы становятся тривиальными :-)

В твоем определении бд содержит актуальные и корректные данные. Что, конечно, в реальности практически всегда не так. Иди прочитай определение целостности и не неси ересь.

Ересь несёшь здесь ты. :-) Моя БД будет содержать данные и метаданные, которые будут согласованы.

Це́лостность ба́зы да́нных (database integrity) — соответствие имеющейся в базе данных информации её внутренней логике, структуре и всем явно заданным правилам. Каждое правило, налагающее некоторое ограничение на возможное состояние базы данных, называется ограничением целостности (integrity constraint). Примеры правил: вес детали должен быть положительным; количество знаков в телефонном номере не должно превышать 25; возраст родителей не может быть меньше возраста их биологического ребёнка и т. д.

Так что тасуйся вальсом, мальчик :-)

неподдерживаемые портянки на SQL

Ну бугагище же. Эти «неподдерживаемые портянки» я просто отдаю DBA на оптимизацию, а потом дергаю откуда угодно - хоть из баша, хоть из хацкеля. А ты каждый раз заново натягиваешь пиджак на осьминога и надеешься, что орм авось как-то оптимизирует. А потом у таких «жаба тормозит».

дальше SQL-запросы становятся тривиальными

Пусть для аналитики3 колонки detail3_id INT, detail3_table VARCHAR

В SQL уже можно сделать SELECT * FROM data JOIN `detail3_table` d3 ON detail3_id = d3.id WHERE d3.date > '20150101' ?

Или как тебе поможет указание имени таблицы? На стороне клиента я просто фильтрую record.detail3.date > '20150101', а в SQL что можно сделать?

юнионом по числу разных возможностей

В смысле, вместо одной таблицы будет N^3, где N — число типов для аналитики?

Selectable хранимыми процедурами

Это понятно. Вопрос, как в них данные вытаскивать. Глобальных переменных в SQL нет, между вызовами закэшировать негде. То есть getdate(account, detail3) будет делать SELECT из БД на каждый вызов.

Генерацией sql кода.

То есть тот же ORM. Только, возможно, на стороне сервера.

Или как тебе поможет указание имени таблицы? На стороне клиента я просто фильтрую record.detail3.date > '20150101', а в SQL что можно сделать?

Начнём с того, что приведённый тобой реальный пример - является примером того, как не надо проектировать БД. :-) Почему? Очевидно потому, что сущности «аналитикаN» являются подклассами сущности «аналитика». Проектировщик этой БД счёл нужным разнести сущности «аналитика» по разным таблицам. Этот способ реализации наследования является самым сложным. В Postgres реализована довольно ограниченная поддержка наследования, которая для таких вот случаев подходит не самым лучшим способом. Обычно такие сущности сливают в одну таблицу, в которой определяют поле типа. Т.е. проще всего сделать одну таблицу «аналитика» с полем типа «тип», целостность которой будет обеспечивать тривиальный триггер. Далее, можно без генерации SQL осуществлять сколь угодно сложные выборки. А вот наследование Postgres можно в этом случае использовать для т.н. «партиционирования», т.е. когда эта единая таблица станет реально большой, дробить её на куски по, например, диапазону дат или идентификаторов. :-) Другой способ реализации наследования (который пытался использовать проектировщик указанной таблицы) заключается в физическом разделении классов сущностей по таблицам. Только в этом случае всё равно все сущности из физически разных таблиц должны иметь один и тот же ключ (т.е. уникальный идентификатор среди разных таблиц). Обеспечить это проще всего последовательностями (sequence). Но всё равно придётся потом создавать вид, объединяющий сущности из разных таблиц. В таблице «проводка» в обоих решениях должно быть только одно поле «аналитика» для каждого из счетов. А то что сейчас там по 3 поля - это очень корявое решение (если я правильно уловил задачу). :-)

А кто ты есть такой, чтобы определять «говнокод»?

А при чем тут я? Мы имеем факт - никто не пишет в БД бизнес-логику кроме парочки упоротых маргиналов вроде тебя.

Последний случай очень редок из-за того, что все необходимые расчёты почти всегда можно сделать на стороне СУБД с помощью SQL

Ты уже сделал все расчеты и получил выхлоп из СУБД, еще раз. У тебя коллекция строк, что дальше с ней делать?

Где-то полученные из строки результата запроса данные я вставлю в специальное место в шаблоне

А если прилетевший из БД формат данных изменится, то будешь потом искать все сотни мест, где у тебя «специально место в шаблоне» и переписывать эти «шаблоны» да еще и без гарантии, что ты где-то что-то забыл? Отличное, надежное решение!

Ересь несёшь здесь ты. :-) Моя БД будет содержать данные и метаданные, которые будут согласованы.

Но они не будут согласованы, потому что это невозможно в реальном мире.

соответствие имеющейся в базе данных информации её внутренней логике,

Правильно. То, что в БД не указано в качестве ограничений (например, согласование данных и метаданных которые рассогласованы по определению и не могут храниться в целостностной БД) - и не относится к целостности БД.

А ты каждый раз заново натягиваешь пиджак на осьминога и надеешься, что орм авось как-то оптимизирует.

А зачем ОРМу что-то оптимизировать, лол? Оптимизацией занимается БД.

Эти «неподдерживаемые портянки» я просто отдаю DBA на оптимизацию

А, так поскольку портянки неподдерживаемые, то их никто и не поддерживает. Отличное решение проблемы, чо. А если надо внести в систему исправления - то каждый раз переписывать с нуля. Очень удобно.

А при чем тут я? Мы имеем факт - никто не пишет в БД бизнес-логику кроме парочки упоротых маргиналов вроде тебя.

«Бизнес-логику» или «шоу-бизнес»? :-) Я просто пользуюсь возможностями серверного программирования, предоставляемые СУБД. Я могу обеспечивать целостность данных триггерам. С т.з. любителей паттернов, мои БД можно рассматривать как настоящую модель в контексте MVC. Модель может генерировать сигналы с помощью NOTIFY. У меня в руках вся мощь SQL и все возможности СУБД :-) И зачем мне смотреть на маргиналов, вроде тебя, пользующимися однобокими и вечно недоделанными ORM? :-)

Ты уже сделал все расчеты и получил выхлоп из СУБД, еще раз. У тебя коллекция строк, что дальше с ней делать?

Вопрос риторический. Что душе угодно, то и делай :-)

А если прилетевший из БД формат данных изменится, то будешь потом искать все сотни мест, где у тебя «специально место в шаблоне» и переписывать эти «шаблоны» да еще и без гарантии, что ты где-то что-то забыл? Отличное, надежное решение!

А если прилетевший из космоса астероид угодит прямо в центр обработки данных, где расположен сервер СУБД? :-) На самом же деле, шаблоны для вывода того же HTML никак не зависят от формата строк, «прилетающих» из СУБД. ОниЖеШаблоны :-) Поэтому лучше подумать об астероиде :-)

Но они не будут согласованы, потому что это невозможно в реальном мире.

Т.е. когда фотоаппарат записывает в только что сделанный снимок данные EXIF, он делает невозможное? Или же и фотоаппарат записывает несогласованные метаданные в фотографии? :-)

Правильно. То, что в БД не указано в качестве ограничений (например, согласование данных и метаданных которые рассогласованы по определению и не могут храниться в целостностной БД) - и не относится к целостности БД.

Закусывать надо :-)

Я могу обеспечивать целостность данных триггерам.

Так с обеспечением целостности никаких проблем нет, для того реляционные СУБД и нужны. Чем больше инвариантов выразили ограничениями - тем лучше, конечно же. Проблемы начинаются, когда на БД переносится сложная логика выборки и обработки данных, потому что SQL - очень плох именно как _ЯП_. Какие-либо средства контроля за сложностью в этом языке отсутствуют как таковые. SQL можно сравнить с ассемблером - вроде как у тебя в руках «вся мосчь», но на практике на ассемблере практически никогда уже не пишут (за исключением редких ассемблерных вставок = простенькие SQL-запросы на пару строк), а пишут на ЯВУ.

А если прилетевший из космоса астероид угодит прямо в центр обработки данных, где расположен сервер СУБД? :-)

Но астероиды прилетают редко, а «шаблоны» тебе надо переписывать чуть не каждый день.

На самом же деле, шаблоны для вывода того же HTML никак не зависят от формата строк, «прилетающих» из СУБД.

Ага, они берут информацию о структуре БД прямиком из libastral.

Ты упорно не понимаешь того факта, что у тебя два варианта - либо выразить модель БД в одном месте (шаблонами, классами, еще чем-либо, не важно совершенно) и тогда нет смысла не использовать ОРМ, либо при каждом изменении БД потом пердолить весь код, исправляя вызовы по отдельности.