"Сложный" запрос и Group By

Grigoriy 29.03.2004 - 12:08 | Есть две таблицы. В одной - Приход и Расход по препарату с номером NNUM В другой текущие остатки, расчитанные по самой поздней дате из первой таблицы. Мне надо получить треью таблицу, в которой будет сумма продаж за две недели по препарату NNUM и остатки его. Т.е. что-то типа: Номер Препарата/Наименование/ Продано за Х дней/ Остаток Написал такой запрос: select sum("D:\MDOCM.DBF".KOL), "D:\MDOCM.DBF".NNUM, "D:\MDOCM.DBF".VID from "D:\MDOCM.DBF", "D:\MKART.DBF" where (("D:\MDOCM.DBF"."Date">"14.01.04") AND ("D:\MDOCM.DBF"."DATE"<"27.01.04")) GROUP BY "D:\MDOCM.DBF".NNUM, "D:\MDOCM.DBF".VID Запускаю, машина "умирает" минут на 10, потом Access Violation.
Наф 1 - 29.03.2004 - 12:16 | D:\MKART.DBF - что то я не понял как используется?
Наф 2 - 29.03.2004 - 12:18 | Конечно "умирает", пока она создаст выборку прямого произведения 2 таблиц. Представь, если в одной таблице 10000 записей и в другой столько же? имеем 100000000
Grigoriy 3 - 29.03.2004 - 12:48 | наф, я просто в запросе пробовал работать с Group By, запрос не по заданию А файлы огромные, ты прав - MKART=144Мега, MDOCM поменьше, там "всего" 160Метров... Так что они без этого долго работают... Ну а как быть?
VaS 4 - 29.03.2004 - 14:44 | Попробуйте убрать D:\MKART.DBF из выражения FROM.
Grigoriy 5 - 29.03.2004 - 18:18 | Это я неверно запрос написал - писа в дельфи в одну строку и забыл про МКАРТ Перенес на АДО, подправил немного... SELECT MD.NNUM, MK.NAME FROM "MDOCM_Lite.DBF" MD, "MKART_Lite.DBF" MK WHERE (MK.NNUM=MD.NNUM) AND (Md.DATE > ''01.01.2004'' Запрос упрощен намеренно, т.к. уже затык на сравнении дат - "несоответствие типов данных" пишет... dBase+ADO // GetSum:=GetSum+'Group BY MD.NNUM, MK.Name, Mk.Koltek';
VaS 6 - 29.03.2004 - 20:02 | Вместо Md.DATE > ''01.01.2004'' напиши Md.DATE > :date1 ... Q.Parameters.ParamValues['date1'] := EncodeDate(2004, 1, 1);
Grigoriy 7 - 30.03.2004 - 10:27 | VaS, я сделал так: ADOQuery1.Parameters.ParamByName('d1').Value := StrToDate('14.01.2004');
VaS 8 - 30.03.2004 - 10:40 | Посмотри реализацию StrToDate() - она весьма нетривиально парсит строку. Нет ничего медленнее разбора строк :)
Grigoriy 9 - 30.03.2004 - 11:22 | VaS, ты прав, исправил.
Grigoriy 10 - 30.03.2004 - 16:49 | Вот это в результате работает. SELECT MD.NNUM, ML.Name, sum(MD.KOL) as "Продано FROM "MDOCM_Lite.DBF" MD, "MLabel.DBF" ML WHERE (ML.NNUM=MD.NNUM) AND (MD."Date" between :d1 and :d2) Group BY MD.NNUM, ML.Name Order By sum(MD.KOL) Однако так и не удалось подлючить поле KOLTEK из файа MKART. При подключении этой колонки, добавляю его (вынужден) в Group By и всё рушиться... прога уходит куда-то вглубь, зависает вобщем..
VaS 11 - 30.03.2004 - 17:10 | Надеюсь, индексы по полям, по которым осуществляется связь (join) таблиц имеются?
Grigoriy 12 - 31.03.2004 - 09:09 | нет. Я эту тему уже поднимал - есть причины, по которым индексы удалены и пофиксен байт в файле - dbf файлы, если есть индекс, пишет про "неподдержку расширенных функций" или что-то похожее... Пришлось без индексов. Хотя, т.к, я делаю lite копии эти файлов (работать с таблицами размером 144 и 160 метров - не самое большое удовольствие) 16 и 40 Мб, то возможно индекс добавить можно... Но ускорит ли это процесс? ЗЫ Ошибку нашел - В случае, когда я делаю расчет "Продано" по всем точкам - работатает. А вот с JOIN и расчетом по каждой розничной точке - большой затsr и невозможность - работает только последний запрос :(
VaS 13 - 31.03.2004 - 12:31 | Ускорит ли Join наличие соответствующего индекса??? Ты шутишь?
Grigoriy 14 - 31.03.2004 - 15:19 | Нет, не шучу. Просто я, работая с Парадоксом, был ВЫНУЖДЕН отказаться от индекса. Там была трабла с работой оператора LIKE. в dBase была трабла с переиндексацией существующего файла... Вот отсюда такой вопрос...
Grigoriy 15 - 01.04.2004 - 10:39 | Не знаю, имеет ли смысл это писать здесь, т.к. я от БДЕ, в силу его ограниченных, увы, возможностей. Но т.к. тема открыта, надо доводить до конца. Вот такой апрос решил мою проблему (частично) TRANSFORM SUM(MD.KOL) SELECT MD.NNUM, MK.NAME FROM "MDocm_Lite.dbf" MD, "MKART_LITE.dbf" MK WHERE (MD.SCHET<'4141' AND MD.SCHET>'4130') AND (MD.NNUM=MK.NNUM) GROUP BY MD.NNUM , MK.NAME PIVOT MD.SCHET
KVV 16 - 01.04.2004 - 13:59 | Grigoriy Используй вложенные запросы не городи все до кучи простой пример Selct ost.NNUM, ost.ostatok-(sum(PR.prih)-sum(PR.rash)) From ostatok.dbf ost, PrihRash.dbf PR Where ost.NNUM in (Select NNUM From PrihRash.dbf Where период дат...) And PR.NNUM = ost.NNUM В реальности надо пробовать на таблицах...(бест?)
Grigoriy 17 - 01.04.2004 - 15:30 | KVV, да, я тоже склоняюсь к вложенным запросам. Трудность в том, что номер из одной таблицы, суммы по продажам из нее же, имя из другой, оттуда же и остаток. Итого в Group by попадает 4 поля, и строки повторяются, неудобно. Кроме того, трудность в том, что скажем таблица содержит два счета по одной точке и надо либо создавать новое поле и заполнять его для розничной точки, либо выпендриваться с запросом. ЗЫ БЭСТ, он родимый...
Grigoriy 18 - 01.04.2004 - 15:32 | Кроме того, ты забыл про группирование, оно ОЧЕНЬ задалбывает
KVV 19 - 01.04.2004 - 18:04 | Что сложного в группировке, просто в конце всего этого напиши Group by и все...
Grigoriy 20 - 02.04.2004 - 09:06 | А то, что группировать надо по одному полю, а приходится по всем перечисленным. Вобщем, вложенные запросы юзать буим...
Grigoriy 21 - 05.04.2004 - 13:26 | Как удалить поля с Delete = True? Логические поля не могу никак прикрутить - в Where вставил MD.DELETE=FALSE плевал он на меня. так же и с MD.DELETE<>True и MD.'DELETE'='FALSE'
KVV 22 - 05.04.2004 - 19:19 | Grigoriy На счет сложного запроса можно еще Insetr, посмотри SQL,
Grigoriy 23 - 06.04.2004 - 11:20 | Инсерт? KVV, буду ли я прав, если предположу, что ты работал с БЭСТ? Я делаю так: сначала "облегчаю" чудовища-файлы, размером по 160 мегов... LiteMkart:='SELECT * INTO "Mkart_Lite.dbf" FROM "mkart.dbf" Where Partia is null'; LiteMDocm:='SELECT * INTO "MdocM_Lite.dbf" FROM "mdocm.dbf" Md Where ("Date" between :d1 and :d2) AND (VID=''2'') AND (TYPE=''9'') AND ("DELETE"=:L1)'; Потом основной запрос делаю (указан выше). Проблема в том, что когда юзер в одном окошке выбирает позицию, в другом по этой позиции должны быть И продажи И остаток И вычисляемое поле прогноза продаж. А это уже геммороидально... ЗЫ Кстати, если ты с БЭСТ знаком, могу я консультироваться у тебя по асе или мылу?

>>