Он пиздит

Причем реализация там тормозная, (по локальному процу) все копируется по 100 раз

Быстро у меня бывает по-разному, суть в том, например последнее с чем работал - сервер логов для онлайн гэмблинг конторы. Там по 100 миллионов записей в день было новых. Ну и поиск по ним. Суть в том, что скорость работы такой системы будет зависеть от структуры базы, индексов, правильных партишенов, а не от DBI или DBIC

Никто с этим не спорил)

не "почему", а "когда".

Программисты нужны знающие тему или отдельный DBA кто будет тыкать их в херовые запросы

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

И опять-таки... Разберем вариант FCGI + Apache. Если я правильно помню всю эту петрушку вы получаете данные для запроса по сокету, потом раскладываете их на ENV и дальше на основе их уже сами роутите запрос, рендерите HTML и т.д. и все это руками, так?

DBIC никак не ускоряет работу с дб. часто, как раз, совсем наоборот. он даёт дополнительный слой абстракции, который не всегда так уж легко преодолеть, особенно, когда пляшешь от известного тебе скл.

да, всё так

М - модель. которую может делать как дбик, так и много кто ещё

Если использовать dbic лишь как заменитель запросов, тогда можно совместно с ручными запросами через dbi использовать.
Если он используется полноценно как модель данных, то можно прострелить себе ногу тогда таким совместным пользованием. В нем есть поддержка литеральных частей запроса чтоб оставаться в рамках модели

фреймворк — это просто библиотека "с принципами". когда делаешь свой сайт, то так или иначе делаешь свою библиотеку, которая занимается разной рутиной

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

Берем условный Каталист. У него есть FCGI бек. Он сам разберет то что пришло, отроутит куда надо запрос, предоставит шаблонизатор (который проверит и не даст ошибиться в многих местах), сам пошлет данные обратно. То есть Каталист это такой клей, который за вас сделал рутинную работу. Далее, для упрощения всей архитектуры, бы выкидываем Апатч, в nginx'е настраиваем прокси пасс и сзади ставит каталист (Каталист уже будет не в режиме FCGI, а напрямую читать данные), мы только что убрали одну прослойку за ненадобностью.

Берем условный Mojo (Каталист так не умеет), запросы в базу данных долгие, поэтому в Mojo их можно сделать асинхронными и, пока один запрос отрабатывает в базе этот-же процесс рендерит ответ от предыдущего запроса. Утилизация ресурсов выше. Так-же Mojo умеет в Веб сокеты и долгоживущие коннекты (В FCGI вы этого не сделаете, насколько я помню). Тут и Long Pooling и прочие AJAX технологии. При этом тот-же Mojo довольно быстрый (У него где-то 20-25К RPS на пустом контроллере, точные цифры не скажу, но порядок такой).

Фактически Каталист и прочее - это дальнейшее развитие идеи FCGI, который может больше, лучше и т.д. За это его и берут.

они хотят одновременно моджо и дбик???

смотря каких запросов

Я не о конкретной ситуации, а вообще, хотят фреймворк+DBIC. Если говорю, что не использую DBIC - сразу как на отсталого смотрят:)

> Берем условный Mojo (Каталист так не умеет), запросы в базу данных долгие, поэтому в Mojo их можно сделать асинхронными

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

а ты скажи, что пользовался, но сам схемы не составлял. это про 90% пользователей дбик верно :)

->as_query -> Mojo::Pg -> Не помню что, но вроде можно заставить DBIC прочесть результаты сказав что они того типа.