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

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

что я буду делать потом с этими hql портянками

Тоже самое что и с тем же количеством sql портянок.

Кто обсчетами пользоваться будет? Если какая-нибудь бухгалтерия, то впилите им OLAP-куб, через OLE к экселю прикрутите и пусть считают что их душе угодно.

схема подразумевает кучи переборов

Я ж говорю, хреновая схема. Расскажи поподробней: что за переборы и зачем. С ОРМом ли, или без него, реляционная парадигма для того и сделана чтобы вместо переборов указывать что ты хочешь получить.

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

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

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

Почему он должен потащить за все время? Ограничивай запрос.

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

Нет, не будет. Почему что-то должно отваливаться?

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

Кто, простите, на ком стоял?

не портал с великой нагрузкой

Что-то тебя не поймешь, то у тебя все медленно, то у тебя не портал с великой нагрузкой.

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

Наличие или отсутствие ОРМ не влияет на то, как ты проектируешь схему. Обратное, кстати, неверно: то как у тебя спроектирована схема может влиять на выбор инструментов, в том числе ОРМ. Если, например, все конкретно денормализовано, то ОРМ скорее прибавит боли, чем улучшит ситуацию.

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

Гонять ORM поверх Oracle - это полный абсурд :)

Это еще с какой стати? При чем тут Оракл или не Оракл? Типа, на Оракле абсурд, на Постгресе норм, а на Мускуле - опять абсурд, так?

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

За пихание бизнес-логики в хранимый код надо отрывать руки на месте. Это тут же убивает насмерть все процессы разработки.

Гонять ORM поверх Oracle - это полный абсурд :)

Это еще с какой стати? При чем тут Оракл или не Оракл?

Ну можно обобщить ) Гонять ORM на любой реляционной СУБД-шке при достаточном большом объеме данных и/или достаточно сложной схеме хранения данных - это абсурд.
Просто Oracle достаточно неплохо заботится о прикладных разрабочиках предоставляя им необходимые инструменты разработки. Причем, занимается он этим очень давно, чего не скажешь о других.

Ты бы нашел сначала чего у тебя там тормозит. А то поди делаешь 100500 запросов вместо одного и слипы натолканы.

За пихание бизнес-логики в хранимый код надо отрывать руки на месте. Это тут же убивает насмерть все процессы разработки.

У вас очень странные представления о процессе разработки СУБД-шных приложений. Вас же не удивляют всякие MVC-модели разработки? Ну просто иногда весьма полезно, удобно и эффективно вынести то, что называется «моделью», в хранимые процедуры. Это, обычная практика.

Гонять ORM на любой реляционной СУБД-шке при достаточном большом объеме данных и/или достаточно сложной схеме хранения данных - это абсурд.

В чем абсурд? Поднятые данные для обработки в коде в любом случае будут храниться в памяти в том или ином виде, и абсолютно параллельно будет это массив у тебя, мапа, или объект или еще что. Только в случае ORM, объект у тебя будет везде один (если это ни какой-то отчет, где можно и колонками обойтись). А не на запись у нас одна структура, чтение другая, на интеграцию отдать мы вообще третью формируем, еще и с ручным заполнением этого добра, что в итоге тот же самый ORM только недоORM. При схеме хранения, оторваной от жизни, конечно да не варик иначе.

За пихание бизнес-логики в хранимый код надо отрывать руки на месте. Это тут же убивает насмерть все процессы разработки.

...но слишком велик соблазн...

... а вообще гениальная идея с точки зрения маркетинга и конкуренции- приварить BL к БД ;) ...

В чем абсурд? Поднятые данные для обработки в коде в любом случае будут храниться в памяти в том или ином виде ...

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

Эти данные еще надо быстро поднять :) - собственно, с этим и возникли проблемы у ТС-а.

Данные поднимаются из СУБД везде sql-запросами, чем hibernate и занимается, а у ТСа там какой-то говнокод похоже.

в идеале:

REST-сервер как модель + генераторы, компиляторы из декларативных наборов прикладных описаний на входе

используй nosql

Данные поднимаются из СУБД везде sql-запросами, чем hibernate и занимается, а у ТСа там какой-то говнокод похоже

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

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

SQL-запросы бывают весьма разные )

Никто не мешает разные запросы выполнять и в hibernate.

Любая ORM поверх реляционной модели хранения данных - это изначально и есть тот самый средненький «говнокод»,..

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

Плюсую jdbcTemplate. Spring у тебя все равно уже есть, а на нем писать удобней, чем на чистом SQL поверх JDBC.

пованивает тут скорей от проектирования хранения данных чисто ради «реляционной модели хранения данных», наплевав как с этим потом работать

похоже, кто-то перенедоучился

Объектно-ориентированные БД, конечно! Особенно когда они непосредственно интегрированы в а) объектную модель б) общую персистентность.

Пример: GemStone/S

https://gemtalksystems.com/products/gs64/

похоже, кто-то перенедоучился

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

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

Здесь же речь идет о бухгалтерских расчетах. Так что, выбор реляционной СУБД - абсолютно по делу.

Так что, выбор реляционной СУБД - абсолютно по делу.

Речь про способ уложить данные в реляционной СУБД, их нормально и под orm можно уложить. Реляционная СУБД это только инструмент.

Речь про способ уложить данные в реляционной СУБД, их нормально и под orm можно уложить. Реляционная СУБД это только инструмент.

Можно вполне нормально уложить данные - с реляционной точки зрения, - но потом очень хреново и медленно работать с ними. Типа, там где вы «ручками» можете выгрести всё одним SQL-запросом с несколькими JOIN-ами да еще и сразу обсчитать данные, ORM-ка может использовать какой-нибудь тупой алгоритм, включающий в себя просто циклическое выполнение серии отдельных SQL-запросов. Вы же под капот ORM не заглядываете - просто тупо пользуетесь тем кодом, который когда-то насочинял какой-то конкретный разработчик ORM.

PL/SQL лесом, он точно хуже джавы. Раздели логику на вытаскивание нужных данных из базы и обсчёт. Обсчет не должен никак зависеть от базы. Обсчет обложи миллионом юнит-тестов. Внутри может быть сколько угодно костылей, юнит-тесты тут самое важное, костыли можно потихоньку убрать. SQL или ORM для вытаскивания данных - не слишком важно, я бы посоветовал начать с SQL.

Типа, там где вы «ручками» можете выгрести всё одним SQL-запросом с несколькими JOIN-ами да еще и сразу обсчитать данные, ORM-ка может использовать какой-нибудь тупой алгоритм, включающий в себя просто циклическое выполнение серии отдельных SQL-запросов.

Используя реляционную СУБД ей надо уметь пользоваться, и соответственно нужно иметь представление, какие sql-запросы формирует orm.

Итак имеется полурабочая считалка на яве (spring, hibernate) - тормозная и глючная. Встаёт вопрос, куда двигаться дальше?

1) Профилирование, отладка, вот это всё.

...

N) Пересмотр схемы данных -> выбор подходящей БД -> тестирование/профилирование -> миграция.

Тормозит всё, как обычно, на 100500 запросах в циклах, а даже минимальный запрос к бд - это 4 мс.

Хранимку не пробовали написать? У вас большая часть из этих 4 мс это сетевое взаимодействие + парсинг + транзакционные обертки.

Можно и 100к строк вставлять минутами, а можно одним запросом за секунду.

Если текущая структура БД не подходит для выборок, то в Oracle есть виьюхи и материализованные вьюхи. Которые ты можешь сформировать заранее для таких запросов (чем отличаются кури в доках).

P.S. Ну или денормализуй нафиг и уложи тупо в монгу или другую документно-ориентированную БД по вкусу и требованиям к надежности и скорости (их сейчас много).

Используя реляционную СУБД ей надо уметь пользоваться, и соответственно нужно иметь представление, какие sql-запросы формирует orm.

Вы включили в одну фразу два совершенно противоречивых утверждения. Абсолютно согласен по поводу «Используя реляционную СУБД ей надо уметь пользоваться». А вот по поводу «иметь представление, какие sql-запросы формирует orm» могу сказать, что многие пользователи ORM вообще SQL не знают. И приучает их к этому именно ORM-парадигма, суть которой в том, что, типа, знать SQL - это не обязательно, это прошлый век и лишняя суета. Собственно, вот так и возникает тот «программный» код, потребители которого открывают потом темы типа текущей.

Даже если вы вдруг загляните в исходники ORM, и увидите, что там за алгоритмические «чудеса» присутствуют, возможности что-то исправить (не выкидывая ORM) может не быть.

Если делать это чисто через sql тут вообще 3 запроса получаются вместе с подсчетом. Так откуда у тебя 100500 запросов вылазит?

3 запроса только по этой микрозадаче.

PL/SQL Packages

Не особо помогают.

Тоже самое что и с тем же количеством sql портянок.

Вот и нахрена он тогда нужен?

При большом количестве сущностей (таблиц) hibernate позволяет все это нормально поддерживать.

Я вижу, что он только позволяет не париться с простыми выборками и join'ами. Как в этих их примерах типа бложика или магазина. Да, там всё красиво.

У нас есть кубы, тут надо посчитать квартплату. Найти сколько человек вылил/сжег по какой цене, какие там льготы. Потом посчитать сальдо, долги и пр.бух.данные. Как я её тебе всё это запихаю в olap?

Ты бы нашел сначала чего у тебя там тормозит. А то поди делаешь 100500 запросов вместо одного и слипы натолканы.

Так нашел. Ты даже угадал что.

Хранимку не пробовали написать?

Не хранимку, а переписать на хранимки. С этого всё и начиналось, но разработчик сгорел и написал на orm. Теперь сгорел я, но я не хочу переписывать на хранимки. Прошлый разработчик сгорел с хранимок не просто так.

Ну я так и хочу сделать. Вопрос как именно, чтобы потом все это не превратилось в тыкву.

Переписать всю базу, которой уже лет 5 на nosql. Хороший совет. Будешь работать с чем нибудь крупнее гостевухи расскажешь.

Я ж говорю, хреновая схема. Расскажи поподробней: что за переборы и зачем.

Нужно сделать автоначисление, например. То есть тем, кто долго не платит и у кого включена эта фича расчитать по среднему потреблению или по нормативу. Перебираются все счётчики дома по услугам гвс, хвс, эл.энергия, отопление. С этим проблем нет, даже если по одному запросу их выдёргивать, то всё будет нормально. Проблемы начинаются на этапе, когда для каждого счётчика надо вытаскивать норматив по услуге, в рамках которого вытаскивать тариф, его параметры, число проживающих в квартире и еще что-то. Тут начинается жопа. Она конечно, кэшируется, но это помогает слабо, т.к. одни и те же данные дёргаются не так часто.

А за каким хреном тебе тогда вообще база?

За тем, что я не один её использую. Кому-то она еще нужна.

Почему он должен потащить за все время? Ограничивай запрос.

И получится ехал дао через дао и та же самая жопа, что и на хранимках. Я и без hibernate могу надёргать данных с базы и их обсчитать. Вопрос как это сделать как, чтобы не превратить всё в помойку.

Нет, не будет. Почему что-то должно отваливаться?

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

Что-то тебя не поймешь, то у тебя все медленно, то у тебя не портал с великой нагрузкой.

Запросов от юзеров мало, но считать надо, условно, много.

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

На 1С вся эта фигня всегда вытаскивается через LEFT JOIN. За попытку сделать запросом в цикле бьют канделябрами. Если не хочется вытаскивать ненужные данные, то разделяешь лицевые счета по методу расчёта, а потом UNION ALL на результат. Впрочем, методов расчёта там всего 3 (по счётчику, по среднему, по нормативу), можно и отдельными запросами.

P.S. В 1С как раз золотая середина. Язык запросов — чистый SQL (с сахаром вместо явных LEFT JOIN писать типа ЛицевойСчет.Счетчик.Тариф), а результат запроса возвращается в виде объектов ООП.

На 1С

Но 1с не нужен, вот в чем дело.

Впрочем, методов расчёта там всего 3

Мало. Их намного больше, чем 3. А в перспективе еще что-нибудь новенькое подкинут. Недавно, вот, сделали подогрев. Расчёт как по счётчику гвс, вода по цене хвс + гкал на подогрев кубометра по установленному нормативу в зависимости от того изолирован ли стояк, наличия полотенцесущителя, по/свыше норматива по вылитой воде + отдельный тариф для квартиры без проживающих. И конца этому не видно.

QL

Но 1с не нужен, вот в чем дело.

Я имел в виду, что методики можно и позаимствовать бы.

Мало. Их намного больше, чем 3. А в перспективе еще что-нибудь новенькое подкинут.

Я имел в виду, что 3 на каждый отдельный расчёт.

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

В услуге ссылаешь на счётчик ГВС, а тариф вычисляешь единожды и пишешь в БД. То есть у тебя услуга должна быть: ссылка на счётчик, тариф до норматива, тариф после норматива, норматив, нормативный тариф без показаний. При вычислении возвращаешь из БД для каждой комбинации лс + услуга: последнее показание, предпоследнее показание (можно как в 1С в таблице показаний в каждую строку пихать последнее + предпоследнее, последняя строка через SQL тривиально вытаскивается), ссылку на услугу (JOIN все поля таблицы). Там, где расчёт по среднему, делаешь второй запрос, вытаскивая данные для среднего с фильтром по списку услуг (фактические начисления по услуге).

Всё. При расчёте у тебя всего два запроса на чтение и один на запись.

blaze persistence еще есть. оно поверх jpa, так что, какая там бд - не важно.

но тут верно подсказали - всю логику в сервисы, орм тут не особо виновата.

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

Поддерживаю этого оратора, дело говорит.

Попробуй лёгкие ORM, например QueryDSL for SQL. И с хибера (если у тебя он) удобно перейти: сначала юзаешь QueryDSL for HQL/JPQL в качестве статически типизированного языка запросов, привыкаешь так сказать, потом эти же запросы переносишь на SQL-двигло.

При схеме хранения, оторваной от жизни, конечно да не варик иначе

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

...возможности что-то исправить (не выкидывая ORM) может не быть.

Не знаю, что за говно-orm вы встречали, тот же hibernate умеет выполнять чистый sql-запрос. Или вы просто порете чушь и не имели никогда дел ни с orm, ни с реальной разработкой, ни с разработчиками, которые якобы считают, что используя реляционные субд sql не нужно знать.

Ну и зачем тогда orm, если делать на нём чистые sql запросы? Лишняя сущность же.

У нас нет сдачи проекта. У нас проект длинною в жизнь. Что-то допилить надо постоянно, а меняющиеся требования - это основное требование для проекта.

Вот и нахрена он тогда нужен?

Для написания кода на Java.

Как в этих их примерах типа бложика или магазина.

Ну, я бы посмотрел на проектики с >1000 таблиц, с постоянно изменяющимися требованиями, как там все красиво делается на чистом sql, а запись, чтение написано с разными структурами данных с их ручным заполнением.

Ну, я бы посмотрел на проектики с >1000 таблиц, с постоянно изменяющимися требованиями, как там все красиво делается на чистом sql, а запись, чтение написано с разными структурами данных с их ручным заполнением.

Я бы тоже не хотел на это смотреть. И вообще на проект с 1к таблиц, не важно на чём он сделан. Даже палкой тыкать бы не стал.