| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Суммирование по БД. [D6, IB5.x]
off © (2003-05-15 07:19:00)Здравствуйте мастера. Использую I-Base. Есть две таблицы (Мастер-Детаил, связь один ко многим) "Счета" и "Оборот".
Вопрос: Что надо написать в IBQuery, что бы в итоге получить все счета на которых сумма оборотов за период превысила некоторое значение?
Zacho (2003-05-22 20:50:00) [1]
> off © (22.05.03 15:43)
> Судя по всему
> Zacho ©
> отдыхает может
Хрен тут отдохнешь :-) Работа навалилась.
> Хотелось бы по подробнее, что советуешь хранить в таблице
> (как я понимаю временной)?
Нет, не временной. А весьма даже постоянной. Примерно c такими полями: CODECONS - код потребителя, SUMMALL - сумма начислений по данному коду, SUMMPAY - сумма оплат по данному коду. И заполнять/изменять ее триггерами на таблицах COUNTCOM и PAY. В after insert - добавил к сумме, в after delete - отнял, в after update - добавил или отнял, в зависимости от нового значения.
off (2003-05-22 15:43:00) [2]Судя по всему
Zacho ©
отдыхает может
Johnmen ©
или Соловьев помогут?
off (2003-05-22 15:31:00) [3]Я немного с опозданием, просто не было времени этим заняться. Хотелось бы по подробнее, что советуешь хранить в таблице (как я понимаю временной)?
Zacho (2003-05-15 12:52:00) [4]Стандартный способ для ускорения подобных запросов - создать специальную таблицу для хранения агрегатов, и заполнять ее триггерами.
Johnmen (2003-05-15 12:03:00) [5]ХП - хранимая процедура...
off (2003-05-15 11:44:00) [6]
> Johnmen © (15.05.03 11:42)
> либо ХП
а что это такое?
off (2003-05-15 11:43:00) [7]
> Johnmen © (15.05.03 11:18)
Что, не знаешь? Вот и я тоже не знаю!
Johnmen (2003-05-15 11:42:00) [8]>off © (15.05.03 11:21)
>А как предлагаешь связать COUNTCONS И PAY,ведь у них нет ничего общего
Поэтому и связывать их не надо !
Короче - либо вложенные запросы (см.выше), как однозначно определяющие то, что нужно, либо ХП, либо запросы с анализом в приложении (самый неблагоприятный вариант).
off (2003-05-15 11:21:00) [9]Так с вложенными запросами тормозить будет!
А как предлагаешь связать COUNTCONS И PAY, ведь у них нет ничего общего, кроме денег, которые они нам должны?
Johnmen (2003-05-15 11:18:00) [10]>off © (15.05.03 10:54)
>- Связь осуществляется через CODECONS
Нет ! Это связь CONS с COUNTCOM и CONS с PAY !
Запрос должен иметь вложенные запросы в этом случае, т.к. ты хочешь получить некое обобществление различных сущностей (COUNTCOM и PAY). См. что предложил Zacho © (15.05.03 09:56).
И рой в том же направлении...:)
off (2003-05-15 11:14:00) [11]А какая логическая связь может м/ду "начиселением" и "оплатой"?
off (2003-05-15 10:54:00) [12]
> Johnmen © (15.05.03 10:51)
> Не видно логической связи между таблицами COUNTCOM и PAY
> !
- Связь осуществляется через CODECONS
> А если ее нет, то и запрос должен быть принципиально другим...
- А вот здесь, если можно, то по подробнее
Johnmen (2003-05-15 10:51:00) [13]Не видно логической связи между таблицами COUNTCOM и PAY !
А если ее нет, то и запрос должен быть принципиально другим...
off (2003-05-15 10:42:00) [14]Разумеется я описал не все поля, т.к. их слишком много, но мне кажется этого достаточно.
> Zacho © (15.05.03 09:56)
> Но тормозить это должно прилично.
А вот это как раз и не желательно!
off (2003-05-15 10:31:00) [15]Простите,что отвлекся.
Структура рпимерно следующая:
CONS:
- CODECONS - индивидуальный код потребителя;
- ADR - адрес;
- TEL - телефон;
- LIC - лицевой счет;
COUNTCOM:
- CODECOUNT - уникальный код начисления;
- SUMMALL - сумма начисления;
- DATECOUNT - дата начисления;
- CODECONS - индивидуальный код потребителя;
PAY:
- CODEPAY - уникальный код оплаты;
- DATEPAY - дата оплаты
- CODECONS - индивидуальный код потребителя;
- SUMMPAY - сумма оплаты
Zacho (2003-05-15 09:56:00) [16]
> off © (15.05.03 09:11)
Ну можно сделать просто:
SELECT C.CODECONS
FROM CONS C
WHERE (SELECT SUM(CCOM.SUMMALL) FROM COUNTCOM CCOM WHERE C.CODECONS=CCOM.CODECONS)-(SELECT SUM(P.SUMMPAY) FROM PAY P WHERE C.CODECONS=P.CODECONS)>XXX
Но тормозить это должно прилично. Так что лучше подождем структуру с комментариями.
Johnmen (2003-05-15 09:42:00) [17]Ну все понятно, сколько было начислений, во столько раз и увеличивается... А все это - от неверной организации структуры таблиц. Или идеологически неверного запроса.
Так что приводи полностью структуру таблиц, желательно с комментариями...
off (2003-05-15 09:11:00) [18]Это тоже не помогает. Всячески пробовал пробовал менять след. строки:
> FROM CONS
> INNER JOIN PAY ON (PAY.CODECONS = CONS.CODECONS)
> INNER JOIN COUNTCOM ON (CONS.CODECONS = COUNTCOM.CODECONS)
Тут еще кое-что попробовал. Если было 6-ть начислений и 5-ть оплат, то итоговая сумма начислений и оплат увеличивается в 6-ть и 5-ть раз соответственно.
Zacho (2003-05-15 08:42:00) [19]
> off © (15.05.03 08:35)
А если сделать
SELECT SUM( COUNTCOM.SUMMALL ) SUM_OF_SUMMALL, SUM( PAY.SUMMPAY ) SUM_OF_SUMMPAY, CONS.CODECONS
FROM CONS
INNER JOIN PAY ON (PAY.CODECONS = CONS.CODECONS)
INNER JOIN COUNTCOM ON (CONS.CODECONS = COUNTCOM.CODECONS)
GROUP BY CONS.CODECONS
HAVING SUM( COUNTCOM.SUMMALL )-SUM( PAY.SUMMPAY ) > XXX
И еще совет: всегда явно указывай алиасы таблиц, причем они не должны совпадать с названиями таблиц, иначе запрос может вернуть совсем не то, что ожидаешь :-)
off (2003-05-15 08:35:00) [20]Проблема заключается в следующем:
Если у потребитебля было 4 начисления и 1 одна оплата, то начисления суммируются правильно, а вот сумма оплаты увеличивается в четыре раза. На мой взгляд все дело в связи. Каждому (из 4-х) начислению сопоставляется одна и таже оплата, которая потом, соответственно и суммируется четыре раза. А что с этим сделать я не знаю.
| |
Страницы: 