
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
26.06.2013, 12:47:44
|
|||
|---|---|---|---|
большая ли разница? jdbc и использование процедур/функций PostgreSQL |
|||
|
#18+
Появился у меня довольно-таки тяжелый отчет, с перебором многих клиентов, по которым надо найти счета за определенный период и выдать сумму оплат по этим счетам. В итоге, я думаю, что если использоваться запросы через JDBC или hibernate, то все будет ппц как медленно. Процедуры или как они там называются в PostgreSQL будут ли отрабатывать быстрее? Намного? Или получиться то же самое? Имеет ли смысл изучить ради этого функции PostgreSQL? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
26.06.2013, 12:54:02
|
|||
|---|---|---|---|
большая ли разница? jdbc и использование процедур/функций PostgreSQL |
|||
|
#18+
Nixic, - будет быстрее - функции изучать, если нет спеца умеющего писать Сложные SQL выражения ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
26.06.2013, 13:04:03
|
|||
|---|---|---|---|
|
|||
большая ли разница? jdbc и использование процедур/функций PostgreSQL |
|||
|
#18+
Если отдельных запросов очень много (проблема N+1 - число запросов растет с числом данных), то хранимка будет быстрее JDBC, за счет того что минимизируются затраты на общения Java/RDBMS и множество запросов становится одним. Если запросов мало, то ощутимой разницы между JDBC и хранимкой не будет. Hibernate - отдельная тема. Его использование для отчетов вопрос как спорный так и рискованый. Стандартным решением для проблемы вычисления по большому количеству данных является агрегация. Где-то это можно решить через SQL view, где-то через триггеры. Суть в том, что данные можно вычислять в RDBMS не во время печати отчета, а во время обновления данных в самой базе. Таким образом каждый INSTERT\UPDATE\DELETE транзакционно обвновляет счетчики, суммы и другие агрегации в базе. Таким образом CRUD становится немного дороже. Но зато отчеты работают намного быстрее, так как используют готовые агрегации, вместо того чтобы вычислять их каждый раз заново. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
26.06.2013, 14:28:45
|
|||
|---|---|---|---|
большая ли разница? jdbc и использование процедур/функций PostgreSQL |
|||
|
#18+
Blazkowicz, Именно так - счетчиками, сейчас и решил некоторую часть этого отчета - кол-во счетов, заявок, событий и последняя дата этих объектов. А вот с периодами и оплатами в эти периоды сложнее, они у пользователя рандомные))) Оказалось, что есть: таблица клиенты таблица счета таблица оплаты по счетам Связь между ними вполне понятно. Но я нашел, что когда-то давно прикрепил к данным в третьей таблице "оплаты по счетам" еще и айдишник клиента. Тем самым вторую таблицу "счета" можно опустить. Если отчет будет формироваться не больше минуты - пользователи переживут, так как такой отчет нужен не часто. А вот если будет нужна будет инфа и из второй таблицы "счета", то тут уже буду думать над изучением функций, специалиста по сложным SQL-выражений нет, так что придется самому вникать. Спасибо всем за отличные ответы :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
26.06.2013, 16:12:06
|
|||
|---|---|---|---|
большая ли разница? jdbc и использование процедур/функций PostgreSQL |
|||
|
#18+
Спец по "сложным" sql запросам тут врят ли поможет - объём данных постоянно растет, период за который пользователь может захотеть получить отчет тоже. Умные дяди давно поняли, что необходимо отделять динамическую часть системы ( OLTP) от бизнес-анализа на основе этих данных, поэтому придумали "хранилище данных" или "банк данных" над которыми проводится OLAP анализ. Короче, если по серьезному, то надо изучать OLAP и иже с ним. В одной банковской системе обходили OLAP навороты введя так называемые реперные дни, которые шли с определенным интервалом. В эти дни при их "закрытии" на основе динамики (всех банковских документов, порождающих проводки) расчитывалась статика - всякие там остатки по различным аналитикам счетов и т.д. и сохранялась в таблице. Т.о. для получения какого то отчета за определенный период - система находила ближайший реперный день и начинала считать опираясь на данные этого для плюс расчет динамики за интервал от реперного дня до конечной даты. Фактически это тоже хранилище данных, только свое самопальное интегрированное в действующую OLTP бд. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=59&mobile=1&tid=2129103]: |
0ms |
get settings: |
19ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
33ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
55ms |
get tp. blocked users: |
2ms |
| others: | 333ms |
| total: | 475ms |

| 0 / 0 |
