Замена orm

Для начала отдели бизнесслогику от инфраструктуры. Выдели контексты и объекты в них. Выдели shared сущности. Профит. Это я так намекнул на то что бы ты следовал DDD, а не говнокодил обсчет квартплаты в sql каше которую даже ты потом не сможешь поддерживать.

ну или возьми спец конфигурацию 1Ски, полюбому такая есть.

Это я так намекнул на то что бы ты следовал DDD, а не говнокодил обсчет квартплаты в sql каше которую даже ты потом не сможешь поддерживать.

Ок. Спроектируем, как потом это всё реализовывать встал вопрос. Про sql кашу вопросов нет, но тут ситуация двух стульев.

ну или возьми спец конфигурацию 1Ски

Неее, это долго, муторно и еще год дебажить. Никто на такое не пойдёт и не факт, что это всё будет работать лучше и поддерживать это проще.

Ок. Спроектируем, как потом это всё реализовывать встал вопрос. Про sql кашу вопросов нет, но тут ситуация двух стульев.

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

Ты думаешь что ORM будет тормозить, но это лишь теория не подтвержденная профайлингом.

Это практика, подтвержденная профайлингом. Тормозит всё, как обычно, на 100500 запросах в циклах, а даже минимальный запрос к бд - это 4 мс. Даже в случае кеша 20 вложенных вызовов - тоже не очень весело. Надо посчитать 10 услуг на 30 дней на 60 лицевых, 100 раз дёрнул кеш и дом считается 2 минуты без бд, что уже очень много. А если имеет место подёргивание бд, то в 3 раза дольше. Итого использование orm - это критично по производительности. Еще при попытках оптимизации оно имеет свойство внезапно отваливаться в других неожиданных местах и это сводит все её преимущества на нет. Нужно что-то среднее - и не совсем sql портянки и не orm шалаш с кешами.

На PL/SQL не надо. Анализируй архитектуру софтины, отделяй зерна от плевел. Наиболее эффективная оптимизация - это оптимизация логики. Гибернейт тут ни при чем, если у тебя тормозит ORM, значит у тебя кривая схема и кривая логика.

Гибернейт тут ни при чем, если у тебя тормозит ORM, значит у тебя кривая схема и кривая логика.

У меня схема подразумевает кучи переборов. Если переделывать эту схему, проще выкинуть orm, сразу набрать из базы всё, что мне надо, посчитать и залить результат. Нужны, например, показания за 6 месяцев, зачем мне нужен orm, который потащит их за всё время, я не хочу трахаться с ним, когда он будет отваливаться в разных местах после оптимизаций и т.д. Охота что-то, что просто оптимизирует вид sql портянок, добавит плюшки для их дебага и вернёт какой-нибудь датасет, я по нему посчитаю и отдам результат. А всё эти мапинги, объекты, кэши, честно говоря, нахер не нужны. У меня тут не портал с великой нагрузкой, чтобы от этого был хоть какой-то толк.

jooq

Oracle. Не пойдёт, но близко. Есть что-нибудь, где пляшут от самого запроса и структуры бд, а не от возвращаемого набора полей? То есть, чтобы я join'ил объект к объекту, а не таблицы между собой.

https://apex.oracle.com/en/

Извините, вы там на Pentium2 чтоли считаете? Или головой ударились? 2 минуты у них дом считается...

Либо база спроектирована лузером, либо вы что-то делаете не так. Обычно запрос в базу делают чтобы вытянуть нужную инфу (1 раз, не в цикле), никто в запросе расчет не производит. И на spring с java гнать не надо, оно работает на порядки быстрее любых рубей, питонов и иже с ними.

никто в запросе расчет не производит

ну и ССЗБ, «быстрее базы зверя нет»//

Oracle. Не пойдёт, но близко...

Гонять ORM поверх Oracle - это полный абсурд :)
Как временную меру - чтобы быстро закрыть тормоза - можно использовать SQL в некоторых критичных операциях, если ORM позволяет такое (или без неё). Но постоянно так работать, вроде как, не технологично - схему базы данных и запросы нужно контролировать либо «ручками» (как положено) либо посредством всяких костылей, типа ORM, изначально не предназначенных для эффективной работы с данными. Мешать всё в кучу - это не хорошо...

умножить, разделить это да, проще в запросе, но городить там целую логику это и есть ССЗБ

Так поставьте обсчет не на утюг, а на компьютер. У меня на запись сотней тысяч записей с кучей констрейнтов умещается в 5 минут на обычном пк. А у вас выборка тормозит 2 минуты.

Хотя

Тормозит всё, как обычно, на 100500 запросах в циклах

Думаю проблема у вас в архитектуре. Не должно быть запросов в цикле в таких объемах. Давайте конкретику что и как считаете.

Обычно запрос в базу делают чтобы вытянуть нужную инфу

Да я-то не против.

Либо база спроектирована лузером

Даже если это так с этим ничего уже не сделаешь. Хотя база относительно нормальная, многого от неё не надо.

И на spring с java гнать не надо

Дело не в том, что оно само по себе работает тормозно. Да, считает шустро до тех пор, пока не упрётся в отсутствие каких-то данных. Да, считалка написана через жопу и всё упирается в кучу запросов посреди расчётов. Давай приведу маленький пример.
Надо узнать какой-то норматив потребления по какой-то услуге. Ок, берем тариф по услуге. Тариф может вешаться на дом, на лиц.счёт или на город. Ищем его, пока не находим. Итак, дом/лиц.счёт/город имеют ссылку на тариф, у которого есть услуга в свойствах и список параметров (типа цен, нормативов потребления, периода действия и проч.). Нам надо запросить по очереди для дома, лиц.счёта и города все параметры тарифов для конкретной услуги. Но у нас нет связи дом->услуга->тариф->параметры. У нас дом->тариф->параметры и все выборки идут перебором с проверкой даты, услуги для каждой записи и еще чего-то в перспективе, а не автомапером с entitymanager'а или дао. Можно переделать стуктуру, да, но посыпется в другом месте где-нибудь. Можно сделать dao с hql, но нахера мне тогда всё это orm с его поддержкой, если у меня и так всё на dao.

Нет. Но поддерживать sql - боль и страдание. Поэтому ищу что-то не слишком ущербное.

Давайте конкретику что и как считаете.

Выше описал маленько, но это долго всё перечислять. Тут куча целая всего мужик пол года это писал.

... Охота что-то, что просто оптимизирует вид sql портянок, добавит плюшки для их дебага и вернёт какой-нибудь датасет, я по нему посчитаю и отдам результат.

Ну есть такие библиотечки и классы, которые рассчитаны на работу именно с SQL и обеспечивают удобства кодирования.
Типа:
https://www.yiiframework.com/doc/api/2.0/yii-db-connection
https://www.yiiframework.com/doc/api/2.0/yii-db-query
https://www.yiiframework.com/doc/api/2.0/yii-db-command

поддерживать sql - боль и страдание. Поэтому ищу что-то не слишком ущербное

В Oracle хранимые процедуры можно можно писать на языках PL/SQL и Java.

yii

java

Нужны, например, показания за 6 месяцев, зачем мне нужен orm, который потащит их за всё время

Так не просите ORM тащить показания за всё время, кто мешает фильтр по критерию даты сделать и сделать проекцию только нужных полей? Проблема у вас не в ORM, а в её неправильном использовании. Если будете переписывать на голых sql запросах, то или получите свой недоделанный ORM, или пробежите по тем же граблям, что у вас сейчас.

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

Типичная ситуация когда фронт-веб макаку посадили писать бэкэнд логику.

Ищем его, пока не находим...

Делаешь запрос на все, что надо искать перекрестно, пихаешь то где искать в Map, остальное в List. Потом проходить по листам и ищещь в мапе по ключам. Это не может тормозить, я гарантирую.

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

зачем мне нужен orm, который потащит их за всё время

Да, похоже я понял проблему. Выкинь hibernate. Заюзай jdbcTemplate. И без прямого маппинга, а с ручным заполнением полей.

yii

java

Ну так и в Java такое наверняка есть, если поискать - это я просто пример привел на тот случай, если нужен функционал именно такого типа.

Это не может тормозить, я гарантирую.

Да я понимаю. Вопрос нахрена мне тогда этот hibernate и что я буду делать потом с этими hql портянками в dao. Всё это будет выглядеть не лучше кучи дерьмища в хранимках.

Че там по индексам?

нахрена мне тогда этот hibernate

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

Ну там есть, но мне нужно что-то на уровень выше. Идеально - чтобы все эти select'ы заворачивались в какие-нибудь объекты и я, например, мог заjoin'ить 2 селекта и как-то это всё подебажить. Главная проблема в том, чтобы проект не превратился в sql/hql кашу, где я буду дни на пролёт сношаться с подзапросами подзапросов.

Да сносно в принципе. Простой @batchsize или как его там, ускорял работу в 6 раз, правда всё ронял в другом месте.

Ну, походу всё к этому и придёт. JDBC и велосипеды.

Так не просите ORM тащить показания за всё время, кто мешает фильтр по критерию даты сделать

И как это сделать? Через dao на hql? И что я получу в итоге?

Это не велосипеды, это работа такая, называется «программирование» :)

Ну так а что вам мешает сказать ОРМ как это все вытаскивать а не тупо мапится на поля как они в базе лежат? На то она ОРМ что бы делать нужную вам абстракцию над слоем хранения данных. Вообще не понимаю в чем проблема то? Вы используете ОРМ как простую АР мапилку на таблички. Изучайте иструмент.

Да. Похожу надо избавляться от комплексов:)

Ну так а что вам мешает сказать ОРМ как это все вытаскивать а не тупо мапится на поля как они в базе лежат?

Через что? Dao? А профит в чём? Аннотации? А как? Сущность-то одна, а ситуации разные.

Изучайте иструмент.

Ммм. По мануалам с примерами блогов? Расскажи, как можно решить, то, что описал тут: Замена orm (комментарий)

А Есть ли какая-нибудь «золотая середина» между sql и orm?

ну... jdbc template (native queries) и jOOQ

Ну там есть, но мне нужно что-то на уровень выше. Идеально - чтобы все эти select'ы заворачивались в какие-нибудь объекты и я, например, мог заjoin'ить 2 селекта и как-то это всё подебажить. Главная проблема в том, чтобы проект не превратился в sql/hql кашу, где я буду дни на пролёт сношаться с подзапросами подзапросов.

OOП (ORM) и реляционная модель - это совершенно перпендикулярные подходы, попытка «скрестить ежа с ужом». Если и искать что-то уровнем повыше, то точно не ORM - посмотри какие-нибудь чисто оракловые примочки.

jOOQ

OOП (ORM) и реляционная модель - это совершенно перпендикулярные подходы, попытка «скрестить ежа с ужом»

Ну почему. У нас есть класс запрос, у него есть таблицы, со связями, набор условий, набор полей / строковых/агрегативных функций, набор условий, набор полей для групировки/сортировки. Из этого запроса, можно сварить sql запрос и куда-нибудь его передать. Можно соединить два таких запроса, можно сделать объединение/пересечение и т.д. То есть это будет обёртка над sql, чтобы не писать бесконечные nvl и coalesce и case when. Как-нибудь туда передать еще данные о связях, чтобы он сам таблицы связывал по известным ключам, если не указано иное. Можно еще всяких примочек сверху наделать для дебага всего этого.

К сожалению с hibernate и Java знаком мало, воспитан на дотнете с его LINQ. Но вот небольшой поиск выводит на такую статью

Идеально - чтобы все эти select'ы заворачивались в какие-нибудь объекты и я, например, мог заjoin'ить 2 селекта и как-то это всё подебажить.

Ну почему. У нас есть класс запрос, ... То есть это будет обёртка над sql...

Ну есть же View-шки, хранимые процедуры - это как раз наиболее адекватные инструменты структурирования кода при работе с реляционными СУБД-ками. Если грамотно работать, то не будет никакой каши.

JOOQ
Result<Record> result = create.select().from(AUTHOR)
Но вот небольшой поиск выводит на такую статью

Проблема и с тем и с другим в том, что у меня не запросы вида select * from author, а многоэтажные портянки. Тут без разницы в каком они будут виде в sql или в create.select().from(TABLE) отлаживать их всё равно придётся копипастой по кускам. Если бы вот чем-нибудь можно было маленькие кусочки собирать в запросище...

Ну есть же View-шки,

Есть, но они без параметров внутри себя, например. Можно что-то упростить, но не всё. А хранимки - это каша на большом проекте. У нас есть хранимки, я их видел и меня _реально_ тошнило целую неделю.

... Можно что-то упростить, но не всё.

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

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

Если каждый индивидуальный объект данных не очень большой, но их очень много и ты из загрущишь себе локлаьно в хештаблицу, то так будет значительно быстрее. Может даже быстрее,чем если ты напишешь это в хранимой процедуре.

хранимки - это каша на большом проекте

PL/SQL Packages

Вытащи все нужные данные в память и там считай.

Наймите нормального DBA. Он расскажет вам про olap кубы и прочую ересь. Как бонус - обычно они шарят в джаве в области всяких orm и прочих граничных api в разы лучше самих джавистов.

Через что? Dao? А профит в чём? Аннотации? А как?

Я не джавист и не шарю в какой ты там орм и как это синтаксически правильно будет делать у вас. Я тебе за общие принципы расскажу.

Ммм. По мануалам с примерами блогов?

по документации инструмента

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

И в чем проблема? Ты тут же фильтруешь (в рамках запроса) их по услуге и другим параметрам и получаешь нужные тебе дтошки. Если делать это чисто через sql тут вообще 3 запроса получаются вместе с подсчетом. Так откуда у тебя 100500 запросов вылазит?