|
|
|
хранимые агрегаты
|
|||
|---|---|---|---|
|
#18+
Здравствуйте. Задумался сделать для нескольких больших отчетов хранимые агрегаты. Источник для отчета - две таблицы. шапка с некоторыми атрибутами и тело. Создал таблицы для хранимых агрегатов. хранение агрегатов сделал по неделям. сформировал. вроде все ок. Но есть одно но. при расчете отчета используются не только две основных таблицы данных, но в зависимости от значения некоторых полей шапки необходимо джойнить другие таблицы. и соответственно проводить дополнительные вычисления. Вот как быть с этим не знаю. В таблицах агрегатов нет этих данных. Если их туда внести - смысл их практически пропадет. Что посоветуете? Спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.01.2012, 23:26 |
|
||
|
хранимые агрегаты
|
|||
|---|---|---|---|
|
#18+
sergq Если их туда внести - смысл их практически пропадет.Если вы приведете примеры то вероятность внятного ответа повысится. Пока, увы, я не улавливаю смысл вашей проблемы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.01.2012, 04:09 |
|
||
|
хранимые агрегаты
|
|||
|---|---|---|---|
|
#18+
SERG1257, исходные таблицы Код: sql 1. 2. 3. 4. 5. 6. 7. Код: sql 1. 2. 3. 4. 5. 6. таблица агрегатов Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. все агрегаты с эту таблицу собрал. все красиво. Но есть еще две других таблицы Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. т.е. в этих двух таблицах хранятся исключения. в зависимости от CORR_TYPE для вычисления берется либо ATTR1_ID либо ATTR2_ID либо ATTR3_ID. И в зависимости от наличия этих значений в таблице HEAD корректируются значения агрегатов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.01.2012, 12:50 |
|
||
|
хранимые агрегаты
|
|||
|---|---|---|---|
|
#18+
sergq, Видимо Вам надо в Вашем SELECT использовать оператор CASE. Без Вашего оператора выборки трудно фантазировать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.01.2012, 15:48 |
|
||
|
хранимые агрегаты
|
|||
|---|---|---|---|
|
#18+
ARTURV, Это понятно что CASE нужен. Проблема в том, что в таблице агрегатов нет полей ATTR1_ID ,ATTR2_ID, ATTR3_ID. Если их туда внести, то смысл таблица агрегатов приблизится по объему к исходным таблицам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.01.2012, 16:16 |
|
||
|
хранимые агрегаты
|
|||
|---|---|---|---|
|
#18+
sergqПроблема в том, что в таблице агрегатов нет полей ATTR1_ID ,ATTR2_ID, ATTR3_ID. Нет, пролема в том, что эти поля есть в других таблицах. Прежде чем базу денормализовывать, её надо нормализовать. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.01.2012, 16:28 |
|
||
|
хранимые агрегаты
|
|||
|---|---|---|---|
|
#18+
Давайте разберемся, чтобы лучше понимать друг-друга У вас есть таблицы head и body - с этим все понятно. У вас есть таблица исключений (то что она составная это пока не важно) зависимая от PEOPLE_ID и DATEE. (ее можно считать функцией) далее у вас есть проблемный запрос к таблицам head и body, CORR и CORR_BODY (его вы не привели, но я попробую воссоздать, если ошибусь поправьте) Код: sql 1. 2. 3. 4. 5. 6. 7. для решения этого запроса вы предложили таблицу AGG. И ваша таблица AGG никак не помогает улучшить проблемный запрос ибо таблица AGG должна содержать уже откорректированные значения то есть проблемный запрос должен переписываться как Код: sql 1. 2. 3. 4. Значит надо заменить красивую таблицу AGG на полезную для запроса таблицу AGG. Возможно у вас есть другие запросы для которых ваша таблица AGG будет полезна, и если вы их приведете то возможно мы поможем скрестить ужа с ежом и убить двоих зайцев одним выстрелом ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.01.2012, 18:50 |
|
||
|
хранимые агрегаты
|
|||
|---|---|---|---|
|
#18+
SERG1257, корректирующие таблицы могут заполняться как после основных, так и до. т.е. коррекция может быть внесена еще до основных данный. Получается что в триггерах на основных таблицах надо сразу проверять на исключения, и в триггерах на таблицах исключений проверять основные таблицы и если это исключение какие либо данные затрагивает, то сразу корректировать агрегаты? Правильно мыслю? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.01.2012, 20:02 |
|
||
|
хранимые агрегаты
|
|||
|---|---|---|---|
|
#18+
sergq Правильно мыслю?Давайте танцевать от печки (то бишь от исходного запроса). Исходный запрос как и запрос к производной таблице должны давать ОДИНАКОВЫЕ результаты независимо от того до или после основных заполняются корректирующие. В идеале это должна быть материализуемая (индексируемая) вьюха (с автоматическим пересчетом в случае изменений) и будет совсем хорошо, если СУБД сама догадается использовать вьюху переписав основной запрос. К сожалению, это далеко не всегда возможно, так что хочешь сделать что-либо хорошо сделай это сам. sergq Получается что в триггерах на основных таблицах надо сразу проверять на исключения, и в триггерах на таблицах исключений проверять основные таблицы и если это исключение какие либо данные затрагивает, то сразу корректировать агрегаты? решение на триггерах имеет право на жизнь. К сожалению, если триггер отключен, то у вас нет абсолютно никаких гарантий , что производная таблица консистентна с базовыми. Крайне рекомендую завести джоб который будет проверять (или пересчитывать) расхождения в период наименьшей нагрузки системы и высылать их (расхождения) по емайлу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.01.2012, 20:36 |
|
||
|
хранимые агрегаты
|
|||
|---|---|---|---|
|
#18+
SERG1257, собственно две части исходного запроса соединение корректирующих таблиц Код: sql 1. 2. 3. и case который считает сумму отклонений. Слегка корявый но работает ) Код: sql 1. 2. 3. 4. 5. 6. 7. 8. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.01.2012, 20:57 |
|
||
|
хранимые агрегаты
|
|||
|---|---|---|---|
|
#18+
sergq соединение корректирующих таблицНесмотря на неточности (вызваные опечатками, а не желанием запутать) выходит в главном я был прав. 1 Не вносите дополнительные поля в производную таблицу, чтобы рассчитывать конечное значение "на лету" - вместо этого рассчитайте конечное значение Код: sql 1. сразу, (кстати хитрое выражение лучше оформить в виде функции) 2 Вносите дополнительные поля, только если есть другие запросы которым требуются похожие данные или другие фильтры для отбора данных. 3 Выбранный период агрегации (неделя) как-то обоснован? Я к тому, что он не бьется с месяцами и годами - гораздо более распространенными. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.01.2012, 23:00 |
|
||
|
хранимые агрегаты
|
|||
|---|---|---|---|
|
#18+
SERG1257sergq соединение корректирующих таблицНесмотря на неточности (вызваные опечатками, а не желанием запутать) выходит в главном я был прав. 1 Не вносите дополнительные поля в производную таблицу, чтобы рассчитывать конечное значение "на лету" - вместо этого рассчитайте конечное значение Код: sql 1. сразу вот тут не понял ) Сразу это когда? в самом отчете? Тогда придется от хранимых отказываться. А неделя обоснована. это минимальный интервал за который делают этот отчет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.01.2012, 23:11 |
|
||
|
хранимые агрегаты
|
|||
|---|---|---|---|
|
#18+
sergq вот тут не понял ) Сразу это когда? в самом отчете?Сразу, это значит рассчитать в производной таблице. А в отчете просто запросить. sergq А неделя обоснована. это минимальный интервал за который делают этот отчет. Тогда хозяин - барин. Но если потребуется вывести тоже самое за месяц или год, то придется делать еще одну зависимую таблицу или хитрить с union all запросом из базовой таблицы для первой неполной недели + union all целые недели + запрос из базовой таблицы на последнюю неполную неделю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.01.2012, 23:36 |
|
||
|
|

start [/forum/topic.php?fid=32&fpage=54&tid=1541873]: |
0ms |
get settings: |
10ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
40ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
28ms |
get tp. blocked users: |
1ms |
| others: | 227ms |
| total: | 330ms |

| 0 / 0 |
