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