Форум: "Начинающим";
Текущий архив: 2010.11.21;
Скачать: [xml.tar.bz2];
ВнизПросмотр результата SELECT по строкам в функции MySQL Найти похожие ветки
← →
mefodiy (2010-08-24 11:21) [0]Уважаемые мастера, можно ли в хранимой процедуре или функции MySQL сделать выборку командой SELECT, а потом каким-то образом промотреть все строки (например, как в WHILE DO), по ходу анализируя и суммируя значения в переменные по определенным столбцам (просто командой SUM с условиями не получается).
← →
Ega23 © (2010-08-24 11:21) [1]Курсор?
← →
12 © (2010-08-24 11:39) [2]
> просто командой SUM с условиями не получается
почему? и что именно?
лучше, чтоб получилось. Курсор не желателен
← →
12 © (2010-08-24 11:40) [3]тьфу, прочитал MSSQL
хотя, наверняка и в My тоже нежелателен
← →
Ega23 © (2010-08-24 11:46) [4]
> Курсор не желателен
Основание?
← →
12 © (2010-08-24 11:55) [5]
> Основание?
Книжку не помню, но из личного для MSSQL2000:
Все что переписывал без курсора, как бы сложно не было в запросе - работало быстрее.
← →
Игорь Шевченко © (2010-08-24 11:59) [6]
> Все что переписывал без курсора, как бы сложно не было в
> запросе - работало быстрее.
руки
← →
Anatoly Podgoretsky © (2010-08-24 12:15) [7]
> mefodiy (24.08.10 11:21)
Если MySQL поддерживает курсоры, то это оно, если нет, то никак.
← →
mefodiy (2010-08-24 12:19) [8]По описанию курсор - то, что надо. Буду пробовать. Спасибо
← →
Anatoly Podgoretsky © (2010-08-24 12:22) [9]> mefodiy (24.08.2010 12:19:08) [8]
Использование курсоров, как правило, признак неправильного дизайна.
← →
Ega23 © (2010-08-24 13:37) [10]
> Использование курсоров, как правило, признак неправильного
> дизайна.
Обход иерархической таблицы от корня к дереву.
← →
Ega23 © (2010-08-24 13:37) [11]Тьфу, к листу.
← →
12 © (2010-08-24 14:10) [12]метод Селко можно заюзать для MS
← →
Ega23 © (2010-08-24 15:26) [13]
> метод Селко можно заюзать для MS
Можно всё, можно и голову ногой почесать.
← →
mefodiy (2010-08-24 16:05) [14]Попробовал курсор. В принципе работает, но не так быстро как хотелось бы.
← →
Anatoly Podgoretsky © (2010-08-24 16:08) [15]Ну так навигационные, а не реляционные методы.
← →
12 © (2010-08-24 16:31) [16]
> mefodiy (24.08.10 16:05) [14]
Вы б привели таблицу и правило, по которому надо выбрать - может кто бы и запросом помог
← →
mefodiy (2010-08-25 10:16) [17]Есть таблица MySQL с примерной (для упрощения) структурой
Unit_code CHAR(4)
Out_date DATE
In_out CHAR(1)
Qty INT
Amount DECIMAL(20,2)
Ниже приведен "кусок" этой таблицы для одного кода товара ("0001")
Unit_code Out_date In_out Qty Amount
0001 08.07.2010 I 48 57,60
0001 11.07.2010 I 32 48,00
0001 13.07.2010 I 25 32,50
0001 15.07.2010 O 53 95,40
0001 12.07.2010 I 24 43,20
0001 13.07.2010 I 35 45,50
0001 14.07.2010 O 48 91,20
0001 25.07.2010 I 15 16,50
0001 30.07.2010 O 63 100,80
Таблица отражает товародвижение на складе. В столбце "In_out" "I" - это поступление, "O" - отпуск товара со склада.
Qty - количество товара, Amount - стоимость поступившего или отпущенного количества товаров. Причем, если для поступивших товаров - это стоимость покупки (т.е. покупная цена помноженная на кол-во), то для отпущенных товаров - это сумма продажи (цена продажи помноженная на кол-во).
Целью запроса является получение отчета по продажам вида (цифры точные)
Код Дата Кол-во Цена Сумма Цена Сумма
покупки покупки продажи продажи
0001 15.07.2010 53 1,32 69,71 1,80 95,40
0001 14.07.2010 48 1,42 67,93 1,90 91,20
0001 30.07.2010 63 1,35 85,34 1,60 100,80
Сложность в подсчете цены покупки, которая должна быть средней ценой на момент продажи. Алгоритм расчета такой: нужно просуммировать на момент отпуска товара все значения "Amount" для In_out="I" вычесть отсюда сумму покупки (себестоимсоть) уже проданных к этой дате товаров (если таковые имеются) и поделить на остаток товара на дату продажи (в количественном выражении).
Поскольку понять "словесное объяснение", наверняка будет трудно, приведу расчеты цен покупки для трех приведенных выше дат продажи, исходя из исходной таблицы:
15.07.2010: (57,60+48,00+32,50)/(48+32+25)=1,32
14.07.2010: (57,60+48,00+32,50+43,20+45,50-1,32*53)/(48+32+25+24+35-53)=1,42
30.07.2010: (57,60+48,00+32,50+43,20+45,50+16,50-1,32*53-1,42*48)/(48+32+25+24+35-53-48)=1,35
Вот эту последнюю часть пришлось запихнуть в функцию с курсором. Может кто предложит вариант получения отчета одним запросом?
← →
mefodiy (2010-08-25 12:56) [18]Удалено модератором
← →
12 © (2010-08-25 13:39) [19]ну как-то так бы начал,
и надо потом подогнать под расчеты на бумаге
Unit_code CHAR(4) - cod
Out_date DATE - od
In_out CHAR(1) - io
Qty INT - qty
Amount DECIMAL(20,2) - a
select sum(aa) aa, sum(aa2) aa2, sum(aa)/sum(aa2) from
(
select
case
when t.io = "I" then sum(A)
else -sum(A)
end aa,
case
when t.io = "I" then sum(qty)
else -sum(qty)
end aa2
from Test t
where t.od < "14.07.2010"
group by t.io
)
← →
mefodiy (2010-08-25 14:33) [20]Так не получится, так как для каждой даты продажи (отпуска товара) нужны результаты предыдущих продаж.
Например для даты 30.07.2010 нужны результаты 1,32 и 1,42, которые уже должны быть рассчитаны.
← →
12 © (2010-08-25 14:53) [21]че то неправильно
> для даты 30.07.2010 нужны результаты 1,32 и 1,42
каждый день пересчитывается цена, так что-ли?
а почему бы не хранить ее в таблице некой тогда, чтоб не пересчитывать?
а что будет, если в один из дней цена не пересчиталась? (не работали)
← →
mefodiy (2010-08-25 14:56) [22]Цена каждый день продажи не пересчитывается. Это нужно сделать в запросе. В том-то и сложность.
← →
mefodiy (2010-08-26 12:52) [23]Удалено модератором
Примечание: В форум по MySql
Страницы: 1 вся ветка
Форум: "Начинающим";
Текущий архив: 2010.11.21;
Скачать: [xml.tar.bz2];
Память: 0.5 MB
Время: 0.004 c