Ээээ... команда по критерию "самая дешевая" или "племянник"?

Это, как обычно, хуже, чем отсутствие связывания

Это зависит, но в целом, так:
/* Check the extensions in decreasing order of preference. Encoding the release event above assumes that 1006 comes first. */
if (term->xterm_extended_mouse) {
 len = sprintf(abuf, "\033[<%d;%d;%d%c", encstate, c, r, a == MA_RELEASE ? 'm' : 'M');
} else if (term->urxvt_extended_mouse) {
 len = sprintf(abuf, "\033[%d;%d;%dM", encstate + 32, c, r);
} else if (c <= 223 && r <= 223) {
 len = sprintf(abuf, "\033[M%c%c%c", encstate + 32, c + 32, r + 32);
}

Что-то сразу не понял. Если у вас БД - практически KVS, зачем вам SQL использовать в качестве KVS? Это примерно как perl использовать в качестве шелла. Или свинью стричь - визгу много, а толку мало

Ну если подумать, то так как деньги, то транзакционность и все остальное надо, а как KVS Пг не уступает MySQL'ю и с ним нету проблем как с MySQL'е или монгой.

kvs ом редис можно

или мемкешь

Мы не доверяем NoSQL решением, так как по факту у них очень мало плюсов по сравнению с большими минусами.

Да, я не припомню транзакционных KVS и чтоб совсем NoSQL. А рожать самодельный транзакционный движок поверх kvs - это не совсем то, чем я бы хотел заниматься.
Но тогда не очень понятны страдания по недостаткам SQL

А это вообще феерия. мемкеш не сохраняет данные на диске.

А где я страдал по недостаткам SQL?.. Нет, есть недостатки DBIx::Class... Это да.

Так-же есть маленькая проблема в том что DBD::Pg немного тормознутый и если у меня словари в XS, то и из хагрузку желательно делать в XS не пользуясь DBI. Но это спешиал кейсы все.

"Пихать логику в бд - к невероятным проблемам в дальнейшим, когда проект "выстрелит"." - это к обсуждению создания view. Вас там все-таки двое или вы реально не помните, что писали?

А вы про это... Там вы разделяйте SQL и хранимки.

Хранимки - это логика в БД. Вьюхи из вашего контекста - это сущность DBIx::Class (Ну вы очень любите прыгать на разные слои абстракций, использующих схожие термины не предупреждая), как я понял из контекста

А разговор в том контексте, как я помню, - был про хранимки

хранимки — такое дело. в том же можо их очень рекомендуют, чтобы можно было легко делать асинхронный код: много операций за рах на стороне бд и только одно асинхронное ожидание в приложении

это помимо того, что сложные обработки данных лучше делать не пересылая их на клиента

но портирование становится ахренеть каким весельем. проходил портируя пл/скл на т/скл

1. Перечитал. Про хранимки там не было ни слова. У вас где-то память очень сбоит.
2. Не знаю, как в вашей реальности, а в моей DBIx::Class::ResultSource::View - это обертка над SQL view, дополнительного оверхеда не несет, дополнительной логики не имеет, кроме пометки "виртуальный набор данных" и проверки в deploy handler'е, что все таблицы, на которых основано view, развернулись. Если в DBIx::Class есть какие-то другие view, покажите, что ли
3. Если из моего контекста исходило, что это "сущность DBIx::Class", то при чем тут унесение логики в БД?
4. Триггеры, например, в той же БД позволяют сразу получить обработку стоимости звонка при записи звонка в базу - вне зависимости от того, это у меня радиус залил, или при отказе радиуса логи АТС через парсер прошли, или иными какими способами эти данные взялись в базе. А вообще "логика в БД" - это примерно все, кроме индексов. Даже уникальный индекс - это уже логика в БД...