LINUX.ORG.RU

Замена orm

 , ,


0

4

Нужно считать кварплату. Куча всяких условностей и идиотский законов которые постоянно меняются. То есть задача намного сложнее, чем умножишь объём на цену. Наркомановские параметры, нормативы, полувиртуальные услуги, тарифы и сбор параметров для них с нескольких уровней, лицевых счетов и пд владельцев прилагается. Нужно всё это как-то обсчитывать, чтобы не выстрелить себе в голову из дробовика после двух месяцев поддержки и звонков из бухгалтерии.
Итак имеется полурабочая считалка на яве (spring, hibernate) - тормозная и глючная. Встаёт вопрос, куда двигаться дальше? Снабдить считалку бодрящей порцией костылей и бегать вокруг неё с подмазкой и клеем, чтобы не разваливалась? Попытаться переписать всё на pl/sql не заехать при этом в дурку после пары циклов отладок всплывающих косяков?
А Есть ли какая-нибудь «золотая середина» между sql и orm? Sql хорош и быстр, но какие-то тонкие вещи делать на нём - это боль. Тем более, если тебя постоянно просят что-то добавить и переделать. На orm легко и просто делать тонкие вещи, добавлять и переделывать логику происходящего, но скорость работы и надёжность оставляют желать лучшего.

★★★★★

Последнее исправление: crutch_master (всего исправлений: 1)

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

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

Noob_Linux ★★★★
()
Ответ на: комментарий от Noob_Linux

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

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

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

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

crutch_master ★★★★★
() автор топика
Последнее исправление: crutch_master (всего исправлений: 2)
Ответ на: комментарий от crutch_master

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

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

Noob_Linux ★★★★
()
Ответ на: комментарий от Noob_Linux

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

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

crutch_master ★★★★★
() автор топика
Последнее исправление: crutch_master (всего исправлений: 1)

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

alex_the_v ★★★
()
Ответ на: комментарий от alex_the_v

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

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

crutch_master ★★★★★
() автор топика
Ответ на: комментарий от anonymous

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

crutch_master ★★★★★
() автор топика
Последнее исправление: crutch_master (всего исправлений: 2)
Ответ на: комментарий от crutch_master

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

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

Deleted
()
Ответ на: комментарий от crutch_master

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

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

vinvlad ★★
()
Ответ на: комментарий от anonymous

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

Deleted
()
Ответ на: комментарий от crutch_master

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

Хотя

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

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

Noob_Linux ★★★★
()
Ответ на: комментарий от Deleted

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

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

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

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

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

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

crutch_master ★★★★★
() автор топика
Последнее исправление: crutch_master (всего исправлений: 2)
Ответ на: комментарий от Noob_Linux

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

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

crutch_master ★★★★★
() автор топика
Ответ на: комментарий от crutch_master

... Охота что-то, что просто оптимизирует вид 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

vinvlad ★★
()
Ответ на: комментарий от crutch_master

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

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

anonymous
()
Ответ на: комментарий от crutch_master

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

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

anonymous
()
Ответ на: комментарий от crutch_master

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

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

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

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

Deleted
()
Ответ на: комментарий от anonymous

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

crutch_master ★★★★★
() автор топика
Ответ на: комментарий от crutch_master

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

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

Deleted
()
Ответ на: комментарий от crutch_master

yii

java

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

vinvlad ★★
()
Ответ на: комментарий от Deleted

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

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

crutch_master ★★★★★
() автор топика
Ответ на: комментарий от crutch_master

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

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

Deleted
()
Ответ на: комментарий от vinvlad

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

crutch_master ★★★★★
() автор топика
Ответ на: комментарий от ritsufag

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

crutch_master ★★★★★
() автор топика
Ответ на: комментарий от anonymous

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

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

crutch_master ★★★★★
() автор топика
Ответ на: комментарий от crutch_master

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

Noob_Linux ★★★★
()
Ответ на: комментарий от Deleted

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

crutch_master ★★★★★
() автор топика
Ответ на: комментарий от Noob_Linux

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

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

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

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

crutch_master ★★★★★
() автор топика

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

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

bvn13 ★★★★★
()
Ответ на: комментарий от crutch_master

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

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

vinvlad ★★
()
Ответ на: комментарий от vinvlad

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

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

crutch_master ★★★★★
() автор топика
Ответ на: комментарий от crutch_master

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

anonymous
()
Ответ на: комментарий от crutch_master

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

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

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

vinvlad ★★
()
Ответ на: комментарий от bvn13

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

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

crutch_master ★★★★★
() автор топика
Ответ на: комментарий от vinvlad

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

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

crutch_master ★★★★★
() автор топика
Ответ на: комментарий от crutch_master

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

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

vinvlad ★★
()
Ответ на: комментарий от crutch_master

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

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

Artificial_Thought ★★★★
()

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

anonymous
()

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

onhydro
()
Ответ на: комментарий от crutch_master

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

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

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

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

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

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

Noob_Linux ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.