|
суммирование нарастающим итогом
|
|||
---|---|---|---|
#18+
Добрый день! Такой вопрос. Есть таблица, в которой хранятся ежедневные значения счётчиков. Например есть 20 колонок, каждый день в таблицу записывается значение расхода для каждой из 20-ти колонок. Сам расходомер обнуляется и начинает уже считать следующий день. То есть каждый в таблице появляется 20 строк. Есть вью на эту таблицу. Одно из полей вьхи - сумма, нарастающий итог по строкам для каждой колонки. То есть за 365 дней будет 20*365 строк и соответственно 20 значений сумм за 365 дней для каждой колонки. И всё было хорошо, но появился объект, где колонок 400 (изначально пару лет назад в ТЗ было оговорено, что колонок будет не более 30-ти). Так вот теперь выходит 400 и если взять за год, то выборка начинает заметно, не критично, но заметно тормозить. Предполагаю, что проблема именно в том, что каждый запрос к вью - это суммирование всех значений за период. Ограничения на период сейчас нет. Только столкнулись с задачей, кто что посоветует, как лучше начать решать? авторOracle Database 11g Express Edition Release 11.2.0.2.0 - Production ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2019, 22:05 |
|
суммирование нарастающим итогом
|
|||
---|---|---|---|
#18+
ТС, структура таблиц, возможно, помогла бы нам лучше ответить на ваш вопрос. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2019, 09:07 |
|
суммирование нарастающим итогом
|
|||
---|---|---|---|
#18+
rtyts, Выложите текст Вью но появился объект, тип обьекта известен? ps попробовать переписать через пипелинед pss SQL> select 400*365 from dual; 400*365 ---------- 146000 SQL> ето мало даже для фокса, не должно тормозить ..... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2019, 10:09 |
|
суммирование нарастающим итогом
|
|||
---|---|---|---|
#18+
ultrasonic7, Структура такова: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
Вью: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
То есть примере всего 4 колонки и 2 даты. Вью показывает сумму по всем датам (в примере это5-е и 6-е число) на последнюю дату. Так вот когда колонок более 300, а дат уже 365, то есть история от года, то работа вьюхи становится медленнее. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2019, 10:15 |
|
суммирование нарастающим итогом
|
|||
---|---|---|---|
#18+
rtytsТо есть примере всего 4 колонки да же в первом классе умеют считать до трех ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2019, 10:28 |
|
суммирование нарастающим итогом
|
|||
---|---|---|---|
#18+
rtytsultrasonic7, Структура такова: я неправильно выразился, нужен текст вью все равно станно, медленнее ето насколько? из того что Вы привели, вьюшка простейшая select id,sum(value) s,max(dat) md from t group by id на 200тис не должно, а если еще и проиндексировано ... ..... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2019, 10:35 |
|
суммирование нарастающим итогом
|
|||
---|---|---|---|
#18+
Stax, это я просил структуру таблиц. Не помешает знать, как хранятся данные. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2019, 11:02 |
|
суммирование нарастающим итогом
|
|||
---|---|---|---|
#18+
С текстом вьюхи согласен, мне такой же приходит на ум. Правда, сначала смутили слова "нарастающий итог". Сначала подумалось, что ТС хочет последовательно наращивать сумму, а для этого нужно писать запрос с аналитической функцией, с разбитием по ID и сортировкой по дате. А по факту всё проще. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2019, 11:09 |
|
суммирование нарастающим итогом
|
|||
---|---|---|---|
#18+
Нужно знать, на каких столбцах сделаны индексы, есть ли составные индексы на два поля (id, дата). Нужно делать, проверять. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2019, 11:14 |
|
суммирование нарастающим итогом
|
|||
---|---|---|---|
#18+
Вью, как Stax написал. PK на ID и всё. Если делать запрос Код: plsql 1.
То заметна пауза перед выводом. Клиентом является JAVA приложение, но такое же поведение демонcтрирует и SQL Developer и SQL PLus тоже замирает как-то перед выводом. Нажимаешь выполнить, ждёшь, порой секунд 10, и потом срабатывает. Это пока на тест машине, виртуалка. Может попробовать увеличить размер выделяемой памяти? Или даже не стоит такое пробовать? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2019, 11:46 |
|
суммирование нарастающим итогом
|
|||
---|---|---|---|
#18+
rtytsВью, как Stax написал. PK на ID и всё. Если делать запрос Код: plsql 1.
То заметна пауза перед выводом. Клиентом является JAVA приложение, но такое же поведение демонcтрирует и SQL Developer и SQL PLus тоже замирает как-то перед выводом. Нажимаешь выполнить, ждёшь, порой секунд 10, и потом срабатывает. Это пока на тест машине, виртуалка. Может попробовать увеличить размер выделяемой памяти? Или даже не стоит такое пробовать? шо-то не то (PK на ID )? SQL> set long 50000 SQL> select OWNER,TEXT from all_views where VIEW_NAME='OUR_VIEW'; зи імхо, 10 сек на 160тис много ..... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2019, 11:55 |
|
суммирование нарастающим итогом
|
|||
---|---|---|---|
#18+
rtyts, Почасовки пытаешся суммировать и в колонки разложить? не взлетит. никогда. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2019, 12:01 |
|
суммирование нарастающим итогом
|
|||
---|---|---|---|
#18+
Vint, не, "поднёвки" Каждую ночь я получаю значение за прошедший день. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2019, 13:51 |
|
суммирование нарастающим итогом
|
|||
---|---|---|---|
#18+
rtyts, как вариант. сделай pipelined функцию куда будешь принимать год и отдавать просуммированные данные, заодно можно и паралелить, я так понимаю у тебя чистое чтение. в представление может не пройти пушпредикат. Увеличь фетчсайз для jdbc у тебя 300*365 строк выбирается, если фетчсайз = 100, то можешь ждать ответ пока оно много раз будет пинать базу. еще как вариант создай агрегатную таблицу и перекладывай туда при изменении данных. P.S. У тебя нет ни 300 столбцов ни нарастающего итога. научись пользоваться терминами. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2019, 16:08 |
|
суммирование нарастающим итогом
|
|||
---|---|---|---|
#18+
Vintrtyts, у тебя 300*365 строк выбирается, с чего бы (группировка уменьшит до 400)? .... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2019, 16:54 |
|
суммирование нарастающим итогом
|
|||
---|---|---|---|
#18+
Vint, "Колонки" это конечно не столбцы. Термин с задачи подхватился - авто-заправочная колонка. Сейчас проблема с вью, в которой, да не нарастающий итог, а просто итог. А есть ещё вью, где итог нарастающий. Но с ней почему то проблем нет. В общем попробую pipelined. Спасибо! ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2019, 17:25 |
|
суммирование нарастающим итогом
|
|||
---|---|---|---|
#18+
rtyts"Колонки" это конечно не столбцы. select count(*) cc,sum(VALUE) sv from OUR_VIEW за скоко по времени результат получаете? select count(*) cc,sum(VALUE) sv from t (аблица, в которой хранятся ежедневные значения счётчиков) значения совпадают? .... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2019, 18:05 |
|
суммирование нарастающим итогом
|
|||
---|---|---|---|
#18+
rtytsPK на ID и всё. PK - Primary Key, первичный ключ. Служит для обеспечения уникальности. Он не может быть навешен только на ID, потому что в таблице значения ID каждый день повторяются. Его надо на оба поля навешивать - на ID и дату. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2019, 13:13 |
|
|
start [/forum/topic.php?fid=52&msg=39804709&tid=1882557]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
243ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
others: | 281ms |
total: | 623ms |
0 / 0 |