Так в чем проблема? Выкини лишние запросы и не парься. Непонятно чем тебе поможет замена орм.

...на проект с 1к таблиц.

Ну, используя hibernate, прекрасно работается с таким проектом.

У меня 200 таблиц и что-то я не вижу, в каком месте может прекрасно с ним работаться. Про проблемы написал вот тут Замена orm (комментарий)

Про проблемы написал вот тут

Нарисуй жизнеспособный домен, и переходи на него постепенно.

Выкини лишние запросы и не парься.

Прикольно. Ну ок. Тормозит расчёт, скажу, что считать ничего не надо.

Непонятно чем тебе поможет замена орм.

Дело в том, что он не нужен. Смотри, тормозят вычисления по одному. Я вычисляю всё кучей заранее в хитрых запросах, потом считаю. В итоге у меня будет срач из кучи hql портянок. Зачем мне в таком случае orm? Зачем мне объекты? Всё постоянно меняется и мне придётся их менять и трахаться со всеми зависимостями. Зачем мне вообще монолит на яве? В чём профит? Не проще ли мне тогда сделать запрос->json->микросервис и гетеросексуальную pipeline архитектуру вместо пердолинга с потоками?

таки 1с торт? удобный орм в наличии?

Зачем ? Просто аыносишь часть логтки для показа в nosql например

Только если в перспективе в какое-нибудь оперативное хранилище. Сейчас мне надо просто набрать данные, посчитать, вернуть. И так, чтобы всё это не превратилось в кучу дерьма из sql портянок.

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

грамотно спроектированный набор view + materialized view

таки 1с торт?

Смотря в какой части. Нормального ООП (наследования от произвольного класса) нет. Многопоточность слегка извращённая. У серверных процессов нет состояния (разве что в БД его пихать).

Макросов нет, ссылок на функцию нет (точнее есть, но опять же в крайне извращённом виде).

Зато практически идеальный орм (в местном SQL поле БД может иметь любой объектный тип или их объединение, отладчик умеет показывать временные таблицы), конструктор запросов, пользовательские отчёты (пользователь может строить произвольные условия и группировки). И практически идеальный клиент-сервер, в котором вызов серверной синтаксически не отличается от вызова обычной функции, а состояние формы вообще автоматически синхронизируется без вмешательства программиста. Ну и возможность писать всю программу на русском языке тоже удобна (не приходится придумывать правильный контекстный перевод для всех переменных).

удобный орм в наличии?

Да. Лучше я не видел. Единственный его недостаток: структура самой БД не управляется, а генерируется автоматически. То есть в 1С у тебя Номенклатура, Контрагент и прочее, а в СУБД: _Document315._Fld5739. И индексы он сам за тебя создаёт. Иногда неоптимально. Впрочем, никто не мешает после применения изменений конфигурации индексы пересоздать самом через консоль SQL напрямую.

сколько платят? )

Смотри, тормозят вычисления по одному. Я вычисляю всё кучей заранее в хитрых запросах, потом считаю.

Нираспарсил. так ты в запросах вычисляешь или потом или и так и так?

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

В Hibernate нельзя граф объектов разом подтянуть?

Можно, но зачем?

Чтобы на каждую отдельную сущность запрос не делать?

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

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

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

опять надо какой-то запрос городить?

А ты как хотел? Но в таком случае, в чём проблема сделать этот «запрос» к сущностям в памяти через что-то типа пары .flatMap и .count? Да даже если и явным циклом, в чём проблема? Ну некрасиво да, но работает же.

Ну или меняй джаву на дотнет с его LINQ, будут у тебя одинаковые портянки и для запроса в базу данных, и для запроса «в память», если так хочешь механизм, позволяющий строить универсальные запросы по кусочкам.

Так что написал бы, а потом созрев на выкидывание ОРМ, взял уже готовые

Да не вопрос. Вот уже дописываю кусок. Только что-то мне не нравится результат и что-то не доброе на горизонте маячит.

Да даже если и явным циклом, в чём проблема? Ну некрасиво да, но работает же.

Не, не работает. Тормозит всё.

Ну или меняй джаву на дотнет

Шило на мыло и дело не в яве. Считать будет сносно хоть на js. Главное - это упорядочить портянки, чтобы они не воняли и можно было с ними что-то делать без боли. Вот я и ищу такой инструмент, чтобы там пляска вся шла от запроса. То есть: имеем запрос, как объект с кучей параметров, имеем какие-то методы, чтобы на него влиять, имеем какие-то методы, чтобы их друг с другом дружить. Короче я сам наверное быстрее напишу что мне надо, чем что-то найду для этого.

Да даже если и явным циклом, в чём проблема? Ну некрасиво да, но работает же.[/quote

Не, не работает. Тормозит всё.

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

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

LINQ к IQueryable. В джаве такого точно нет.

На этом этапе, возможно, придётся делать хранимую портянку

Портянки сваляются и будут вонять.

LINQ к IQueryable. В джаве такого точно нет.

Ну, это печально, так бы потыкал может быть.

сколько платят? )

У меня же в профиле сайт, там все расценки. Если же вопрос про зарплату/оклад, то от региона очень сильно зависит.

Портянки сваляются и будут вонять.

Аккуратно храни их в системе контроля версий и обновляй только миграциями и всё будет хорошо.

Аккуратно храни их в системе контроля версий и обновляй только миграциями и всё будет хорошо.

Я их не могу хранить. Постоянно будут ходить все и спрашивать что-то там проверить/поправить. Это обычное дело тут.

Так и вноси поправки миграциями. Сделай себе тестовую реплику БД, проверяй на ней. Правки записывай в гит и применяй на продакшен.

Да дело не в том, чтобы потестить, а в том сколько гловняка потом разбираться в этих портянках, которые я писал пол года назад.

гловняка потом разбираться в этих портянках, которые я писал пол года назад.

Тут кроме аккуратного комментирования каждого значимого блока портянки и разеделения на под-портянки не поможет ничего. С LINQ тоже будут нечитаемые портянки, но не SQL, а дерева LINQ (часть можно вынести в функции, но всё же). С императивным кодом будут нечитаемые циклы, которые так же надо разбивать на подпрограммы тем или иным образом.

Тут кроме аккуратного комментирования каждого значимого блока портянки и разеделения на под-портянки не поможет ничего

Это тоже не поможет, если косяк в середине зависимого блока и тебе как-то надо его отладить, а там зависимости из подзапросов. Если было бы что-то такое, что это разруливает.

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

Нет, не полезно, неудобно и неэффективно. К MVC это не имеет никакого отношения и обычной практикой это было лет 20 назад.

Шаришь, анонимус! Реально шаришь =)

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

Но тут тебе ЛОР не помощник, тебе надо сидеть и ботать, если это целесообразно, конечно.

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

Бред. Какое это имеет отношение к сложности схемы или к объёму? Концепция ORM ортогональна к этим понятиям.

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

Какие именно инструменты ты имеешь в виду? Эти инструменты потеряли актуальность лет 10 назад. Сейчас база - это просто база, логику никто в здравом уме пихать в базу не будет, даже триггеры - это антипаттерн.

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

Ахахахаха. Моим коллегам это расскажи. У них пол логики в тригерах и пакетах, потому что быстро и ничего лучше не придумали. И вот тот мужик год назад сгорел от pl/sql и написал расчёт на яве. А потом он ушел и оставил всё это мне.

Это называется у меня мускуль вместо базы данных.

odin-ass с конфигурацией которая заточена на это.

Возьмите Java EE последнюю версию и нормальную IDE с интеграцией управления javaee-сервера. Тогда разработка ORM на Java (JPA) перестанет быть мучением. То, что вы до этого разрабатывали (spring, hibernate), давно не соответствует промышленному уровню и качеству предоставления услуг. Это - поделки пятилетней давности, над которыми обустраивают костыли из палок и соплей (spring-boot, idea) с громким хайпом.

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

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

Это ты к чему?

Не, это повторение ошибки прошлого разработчика.

не автоматиируется, и никогда не будет, ручками в 1С или таблицы екселя, которые править когда надо

ес че таблицки ексели и 1С можно к любой базе поднлючать

К тому

что ты быдло! В мельбурне с кенгурями в ж@пу долбисси?

Какая тебе разница? Тамбовский волк тебе дружище. Я еще раз спрашиваю: у кого это, «у вас»? Мне ужасно интересно знать к кому ты меня причисляешь на основании «диагноза по фотографии». Перечисли мне какие правила куда я спроецировал. Я всего лишь сказал, что на баше можно и нужно писать, ибо баш есть практически везде. А если его нет, то скорее всего, это - следствие какого-то недоразумения, которое несложно устранить, если админ не выжил из ума. Давай ты мне не будешь говорить куда мне с каким уставом ходить, да? Без сопливых скользко. А проекты в человеко-годы, которые должны стоить пару недель, выстраданы невменяемостью непроходимых кретинов, которые подменяют реальную работу, направленную на решение поставленных задач, рассуждениями о предметах, которые никак к поставленной задаче не относятся.

А, ты опять выходишь на связь. Чего это тебе так припекло, ты питон не любишь что ли?

Я еще раз спрашиваю: у кого это, «у вас»?

Ты про что? Я понял что тебе что-то доставляет адский дискомфорт в жопе, но никак не возьму в толк что именно. Чел, тебе надо срочно завязывать с бухлом.

Mybatis еще не советовали ?

Mybatis - наверное самая толковая надстройка над JDBC что я видел. По сути просто хороший движок шаблонов и удобная обертка генерирующая объекты для каждой строки из ResultSet.

есть шаблоны для повтороного использования кусков sql и т.д.

Да надо поковырять. Там есть объявление запросов не в xml или работа какая-то с ними из java кода?

Короче, ситуация следующая. Один процесс делался 5 часов. Там был запрос в цикле, который брал запись с максимальным id за определённый период по вн.ключу. Вытащил я его из цикла, переделал запрос на группировку по этому ключу, засунул его в hashmap самым прямым и пошлым образом через nativeQuery, дёргаю данные из этого hashmap вместо дрочки hibernate'а. И о, чудо, считаться стало 8 минут. Это вин, я считаю (нет, это не вин. Ну и говнище мне оставили).

... засунул его в hashmap самым прямым и пошлым образом через nativeQuery, дёргаю данные из этого hashmap вместо дрочки hibernate'а. И о, чудо, с ...

Ну, т.е. пригодился-таки SQL, cформированный «ручками»? )))
А бывает еще, что даже в собственной SQL-ке могут просто не те индексы цепляться при выполнении запроса и из-за этого скорость выполнения может падать на порядок - тут имеет смысл анализировать план выполнения SQL-запроса.

Ну и говнище мне оставили ...

Скорее всего, твой предшественник вообще не заморачивался над тем, как извлекаются данные из оракловой базы - он просто по ORM-ной наивности считал, что данные сразу мгновенно в оперативной памяти оказываются )