Максим НMasterZivМаксим Н,

А есть ли прецеденты объединить эти подходы?
т.е. берем крутой ORM, там классы предметной области, методы доступа (типа findByUserWhoSmoke и т.д.), но этот ORM не сам генерирует запросы и не лезет к напрямую к таблицам (и тем более не создает их как это бывает :)), а гибко настраивается, так сказать "насаживается" на готовое, продуманное приложение БД, где реализована бизнес логика (или ее часть), готовы процедуры доступа и изменения записей в таблицах, хранятся sql-запросы для методов доступа и т.д.

Конечно, любое нормальное ORM приложение и должно быть так написано.
И я уверен, что любое приложение с ORM, если оно выполнено не так, к такому рано или поздно придет, если не умрет раннее.

К чему тогда все эти ORM-войны, это то же самое что выбирать между вилкой и ложкой?

очень классная аналогия. Суп удобнее есть ложкой, спагетти -- вилкой.
Так и в IT нужно.

Пилот ПирксMasterZivпропущено...

Кстати слайд 21 в презентации пилота пиркса — яркое тому доказательство.
но-но! я не тот козёл, который только ООП знает, я то, который почти OCP получил, но забил :)

Я ж не знаю, кто этот твой код писал. Может и не ты.
Но такого кода в принципе в приложении не должно быть.
Слайд 20, я там не так указал, извиняюсь.

Пилот Пиркс,

А что такое "1 тред для базы данных" ?
Это как ? Один коннект к БД и все запросы через него ?

Пилот ПирксMasterZivПилот Пиркс,

А что такое "1 тред для базы данных" ?
Это как ? Один коннект к БД и все запросы через него ?
Да, чтобы не париться с конкурентным доступом и не огребать связанных с этим багов, contention-ов на индексах и т.п. У нас много маленьких баз и 1 connection к каждой. На одном сервере 30-40 маленьких баз (схем, в терминах Оракла), соответственно столько же тредов worker-ов, которые работают с базой. Более того, у нас весь игровой сервер примерно так и написан. Множество сервисов, и каждый в 1 тред. Очень удобно.

Странное решение, тем более, что у вас PostgreSQL.