Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2003.06.12;
Скачать: CL | DM;

Вниз

Суммирование по БД.   Найти похожие ветки 

 
off ©   (2003-05-15 07:19) [0]

Здравствуйте мастера. Использую I-Base. Есть две таблицы (Мастер-Детаил, связь один ко многим) "Счета" и "Оборот".
Вопрос: Что надо написать в IBQuery, что бы в итоге получить все счета на которых сумма оборотов за период превысила некоторое значение?


 
Zacho ©   (2003-05-15 07:25) [1]

Чио-то типа SELECT ..., SUM(..) FROM .. JOIN .. ON .. GROUP BY .. HAVING SUM(..)>..
Если хочешь более подробный ответ - приведи структуру таблиц, лучше сокращенно.


 
off ©   (2003-05-15 07:44) [2]

Спасибо!


 
off ©   (2003-05-15 07:51) [3]

А вот еще вопросик. Есть таблица потребителей и подчиненные таблицы начислений и оплаты. Для каждого потребителя нужно посчитать все начисления, все оплаты и посчитать разницу и в вывести только тех у кого разница > ХХХ.
Щас по подробней напишу ...


 
off ©   (2003-05-15 08:15) [4]

Ходят тут всякие, работать не дают, подумаешь комп из домена выпал :-)
Пишу следующее:
SELECT SUM( COUNTCOM.SUMMALL ) SUM_OF_SUMMALL, SUM( PAY.SUMMPAY ) SUM_OF_SUMMPAY, CONS.CODECONS
FROM PAY
INNER JOIN CONS ON (PAY.CODECONS = CONS.CODECONS)
INNER JOIN COUNTCOM ON (CONS.CODECONS = COUNTCOM.CODECONS)
GROUP BY CONS.CODECONS
, где
CONS - таблица потребителей,
COUNTCOM - таблица начислений,
PAY - таблица оплаты.
"CODECONS" - индивидуальный код потребителя,
"SUMMALL" - сумма начислений,
"SUMMPAY" - сумма оплат.


 
Zacho ©   (2003-05-15 08:25) [5]


> off © (15.05.03 08:15)

Добавь
HAVING SUM( COUNTCOM.SUMMALL )-SUM( PAY.SUMMPAY ) > XXX


 
off ©   (2003-05-15 08:35) [6]

Проблема заключается в следующем:
Если у потребитебля было 4 начисления и 1 одна оплата, то начисления суммируются правильно, а вот сумма оплаты увеличивается в четыре раза. На мой взгляд все дело в связи. Каждому (из 4-х) начислению сопоставляется одна и таже оплата, которая потом, соответственно и суммируется четыре раза. А что с этим сделать я не знаю.


 
Zacho ©   (2003-05-15 08:42) [7]


> 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 09:11) [8]

Это тоже не помогает. Всячески пробовал пробовал менять след. строки:

> FROM CONS
> INNER JOIN PAY ON (PAY.CODECONS = CONS.CODECONS)
> INNER JOIN COUNTCOM ON (CONS.CODECONS = COUNTCOM.CODECONS)

Тут еще кое-что попробовал. Если было 6-ть начислений и 5-ть оплат, то итоговая сумма начислений и оплат увеличивается в 6-ть и 5-ть раз соответственно.


 
Johnmen ©   (2003-05-15 09:42) [9]

Ну все понятно, сколько было начислений, во столько раз и увеличивается... А все это - от неверной организации структуры таблиц. Или идеологически неверного запроса.
Так что приводи полностью структуру таблиц, желательно с комментариями...


 
Zacho ©   (2003-05-15 09:56) [10]


> 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
Но тормозить это должно прилично. Так что лучше подождем структуру с комментариями.


 
off ©   (2003-05-15 10:31) [11]

Простите,что отвлекся.
Структура рпимерно следующая:

CONS:
- CODECONS - индивидуальный код потребителя;
- ADR - адрес;
- TEL - телефон;
- LIC - лицевой счет;

COUNTCOM:
- CODECOUNT - уникальный код начисления;
- SUMMALL - сумма начисления;
- DATECOUNT - дата начисления;
- CODECONS - индивидуальный код потребителя;

PAY:
- CODEPAY - уникальный код оплаты;
- DATEPAY - дата оплаты
- CODECONS - индивидуальный код потребителя;
- SUMMPAY - сумма оплаты



 
off ©   (2003-05-15 10:42) [12]

Разумеется я описал не все поля, т.к. их слишком много, но мне кажется этого достаточно.
> Zacho © (15.05.03 09:56)


> Но тормозить это должно прилично.
А вот это как раз и не желательно!


 
Johnmen ©   (2003-05-15 10:51) [13]

Не видно логической связи между таблицами COUNTCOM и PAY !
А если ее нет, то и запрос должен быть принципиально другим...




 
off ©   (2003-05-15 10:54) [14]


> Johnmen © (15.05.03 10:51)
> Не видно логической связи между таблицами COUNTCOM и PAY
> !
- Связь осуществляется через CODECONS



> А если ее нет, то и запрос должен быть принципиально другим...
- А вот здесь, если можно, то по подробнее


 
off ©   (2003-05-15 11:14) [15]

А какая логическая связь может м/ду "начиселением" и "оплатой"?


 
Johnmen ©   (2003-05-15 11:18) [16]

>off © (15.05.03 10:54)
>- Связь осуществляется через CODECONS

Нет ! Это связь CONS с COUNTCOM и CONS с PAY !

Запрос должен иметь вложенные запросы в этом случае, т.к. ты хочешь получить некое обобществление различных сущностей (COUNTCOM и PAY). См. что предложил Zacho © (15.05.03 09:56).
И рой в том же направлении...:)


 
off ©   (2003-05-15 11:21) [17]

Так с вложенными запросами тормозить будет!
А как предлагаешь связать COUNTCONS И PAY, ведь у них нет ничего общего, кроме денег, которые они нам должны?


 
Johnmen ©   (2003-05-15 11:42) [18]

>off © (15.05.03 11:21)
>А как предлагаешь связать COUNTCONS И PAY,ведь у них нет ничего общего

Поэтому и связывать их не надо !
Короче - либо вложенные запросы (см.выше), как однозначно определяющие то, что нужно, либо ХП, либо запросы с анализом в приложении (самый неблагоприятный вариант).


 
off ©   (2003-05-15 11:43) [19]


> Johnmen © (15.05.03 11:18)

Что, не знаешь? Вот и я тоже не знаю!


 
off ©   (2003-05-15 11:44) [20]


> Johnmen © (15.05.03 11:42)


> либо ХП

а что это такое?


 
Johnmen ©   (2003-05-15 12:03) [21]

ХП - хранимая процедура...


 
Zacho ©   (2003-05-15 12:52) [22]

Стандартный способ для ускорения подобных запросов - создать специальную таблицу для хранения агрегатов, и заполнять ее триггерами.


 
off ©   (2003-05-22 15:31) [23]

Я немного с опозданием, просто не было времени этим заняться. Хотелось бы по подробнее, что советуешь хранить в таблице (как я понимаю временной)?


 
off ©   (2003-05-22 15:43) [24]

Судя по всему
Zacho ©
отдыхает может

Johnmen ©
или Соловьев помогут?


 
Zacho ©   (2003-05-22 20:50) [25]


> off © (22.05.03 15:43)
> Судя по всему
> Zacho ©
> отдыхает может

Хрен тут отдохнешь :-) Работа навалилась.

> Хотелось бы по подробнее, что советуешь хранить в таблице
> (как я понимаю временной)?

Нет, не временной. А весьма даже постоянной. Примерно c такими полями: CODECONS - код потребителя, SUMMALL - сумма начислений по данному коду, SUMMPAY - сумма оплат по данному коду. И заполнять/изменять ее триггерами на таблицах COUNTCOM и PAY. В after insert - добавил к сумме, в after delete - отнял, в after update - добавил или отнял, в зависимости от нового значения.




Страницы: 1 вся ветка

Текущий архив: 2003.06.12;
Скачать: CL | DM;

Наверх




Память: 0.53 MB
Время: 0.011 c
8-34937
Tihas
2003-03-01 23:41
2003.06.12
Тут такая проблемма....


14-35040
Леприкон
2003-05-23 07:35
2003.06.12
Евровидение 2003


1-34843
V-A-V
2003-05-30 13:12
2003.06.12
Splitter


3-34696
pavel_guzhanov
2003-05-22 17:46
2003.06.12
Выбор по полю типа Date


4-35103
Clickmaker
2003-04-13 17:28
2003.06.12
Удаление ключа из HKEY_CLASSES_ROOT без прав админа