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

Вниз

SQL остаток товара на складе   Найти похожие ветки 

 
worldmen   (2010-04-28 12:32) [0]

Есть 3 БД:
1-я Наименование товара-
TOVAR
   ID,
   NAME
2-я Кол-во товара которое было принято
TOVAR_IN
   IDFK    
   KOLVO  
   PRICE_IN
   PRICE_OUT
   DATA_IN
3-я кол-во проданного товара
TOVAR_OUT
   IDFK      
   PRICE_OUT  
   DATA_OUT  
   KOLVO      
Нужно сделать запрос остатка товаров на складе.
Я уже и с JOIN пробовал, неполучается.

select a.id, a.name, b.kolvo
from tovar a
RIGHT JOIN tovar_in b on b.idfk=a.id
group by a.id, a.name, b.kolvo
order by a.name

Для начала у меня получается так:

ID..NAME..................... KOLVO
3..Athlon 5000................50  
4..Core 2 Duo.................20  
2..Блок питания 300V.......5  
1..Блок питания 400V.......2  
1..Блок питания 400V......10  

А должно быть сгрупировано две последних записи, почему они не группируются?


 
sniknik ©   (2010-04-28 12:43) [1]

> почему они не группируются?
количество разное, вот и не группируются > group by a.id, a.name, b.kolvo
группировка делается только по полностью совпавшим значениям


 
worldmen   (2010-04-28 13:04) [2]

А если убрать b.kolvo, то появляется ошибка: "invalid column reference."
Как тогда правильно сгруппировать?


 
worldmen   (2010-04-28 13:14) [3]

там надо было :
sum(b.kolvo)
Буду думать дальше.


 
Плохиш ©   (2010-04-28 13:15) [4]


> А должно быть сгрупировано две последних записи, почему
> они не группируются?

А в чём у вас сакраменный смысл группировки?


 
Sergey13 ©   (2010-04-28 13:34) [5]

> [0] worldmen   (28.04.10 12:32)
> 2-я Кол-во товара которое было принято
> 3-я кол-во проданного товара

Почему не в ОДНОЙ таблице? Тогда и думать бы не надо было. 8-)


 
Anatoly Podgoretsky ©   (2010-04-28 14:35) [6]

А чего тут думать, есть такое понятие соединение, после чего мы имеем ОДНУ таблицу


 
Anatoly Podgoretsky ©   (2010-04-28 14:36) [7]


> 1..Блок питания 400V.......2  
> 1..Блок питания 400V......10  

А с чего бы им группироватся, это разные записи. Тут надо использовать аггрегатную функцию SUM(b.kolvo)


 
xayam ©   (2010-04-28 14:50) [8]


> Sergey13 ©   (28.04.10 13:34) [5]
> > [0] worldmen   (28.04.10 12:32)
> > 2-я Кол-во товара которое было принято
> > 3-я кол-во проданного товара
> Почему не в ОДНОЙ таблице? Тогда и думать бы не надо было.
>  8-)

ага точно, плохая структура базы


 
worldmen   (2010-04-28 14:57) [9]


> Почему не в ОДНОЙ таблице? Тогда и думать бы не надо было.
>  8-)

Потому что, товар один и тот же закупается в разное время и по разным ценам.
> Тут надо использовать аггрегатную функцию SUM(b.kolvo)

Я в [3] уже написал это. Читайте внимательно.


 
xayam ©   (2010-04-28 15:01) [10]


> Потому что, товар один и тот же закупается в разное время
> и по разным ценам.

у тебя же все поля одни и те же, достаточно одной таблицы с такими же полями + поле для указания направления движения товара (два значения: IN и OUT)


 
worldmen   (2010-04-28 15:04) [11]

У МЕНЯ ВСЕ ПОЛУЧИЛОСЬ.

select a.id, a.name, sum(b.kolvo) klIN,sum(c.kolvo) klOut, (sum(b.kolvo)-sum(c.kolvo)) Sklad
from tovar a
RIGHT JOIN tovar_in b on b.idfk=a.id
left JOIN tovar_out c on c.idfk=a.id
group by a.id, a.name
order by a.name

РЕЗУЛЬТАТ

ID  NAME               KLIN  KLOUT  SKLAD
3  Athlon 5000          50                
4  Core 2 Duo           20      2     18  
2  Блок питания 300V     5                
1  Блок питания 400V    12                

А структура БД самая правильная. Вы просто никто не читали о нормальных формах.


 
worldmen   (2010-04-28 15:08) [12]


> у тебя же все поля одни и те же, достаточно одной таблицы
> с такими же полями + поле для указания направления движения
> товара (два значения: IN и OUT)

Т.е. сделать вместо tovar_in и tovar_out одну таблицу с полем в котором будет указано тип - ушел/пришел товар?
Тоже хорошо. Но думаю запрос был бы сложнее.


 
xayam ©   (2010-04-28 15:11) [13]


> worldmen   (28.04.10 15:08) [12]
> А структура БД самая правильная. Вы просто никто не читали
> о нормальных формах.

это сильно, к сведению мы об этом не только читали, но и не раз обсуждали, если же ты прочитал про это - не значит что у тебя правильно. Во-первых, потому что не соблюдается принцип одного корня (а как раз их у тебя 2) и, во-вторых, sql-запрос слишком сложен для такого простого результата, соответственно если данных много, то ничего хорошего не будет.


 
Petr V. Abramov ©   (2010-04-28 15:20) [14]


> worldmen   (28.04.10 15:08) [12]


> Т.е. сделать вместо tovar_in и tovar_out одну таблицу с
> полем в котором будет указано тип - ушел/пришел товар?

пришло - kol_vo со знаком плюс, ушло - со знаком минус
запрос становится тривиальным - select sum(kov_vo) from table1 group by fk_id


 
xayam ©   (2010-04-28 15:25) [15]


> пришло - kol_vo со знаком плюс, ушло - со знаком минус

ну да так даже лучше


 
worldmen   (2010-04-28 15:33) [16]

> пришло - kol_vo со знаком плюс, ушло - со знаком минус
Только потом с минусами мучится, когда нужно выводить сколько ушло.
В SQLе ведь нет модуля числа. Во всяком случае в InterBase


 
xayam ©   (2010-04-28 15:37) [17]


> xayam ©   (28.04.10 15:25) [15]
> > пришло - kol_vo со знаком плюс, ушло - со знаком минус
> ну да так даже лучше

но поле для направления движения лучше сохранить, можно использовать для статуса: ЗАКАЗАЛИ, ПРИШЛО НА СКЛАД, ВЫВЕЗЛИ В ЗАЛ, ПРОДАЛИ и так по кругу. У нас так в магазине и это поле в некоторых местах отображается.


 
Petr V. Abramov ©   (2010-04-28 15:37) [18]


> Только потом с минусами мучится, когда нужно выводить сколько
> ушло.

select -kov_vo
from table1
where kol_vo < 0
 and прочие условия

:)


 
xayam ©   (2010-04-28 15:41) [19]

в интербайсе такого нет :) так и запишем.


 
Petr V. Abramov ©   (2010-04-28 15:46) [20]


> xayam ©   (28.04.10 15:37) [17]


> можно использовать для статуса: ЗАКАЗАЛИ, ПРИШЛО НА СКЛАД,
>  ВЫВЕЗЛИ В ЗАЛ, ПРОДАЛИ и так по кругу.

а потом возникнут вопросы у кого заказали, на какой склад пришло, в какой зал вывезли, кому продали и так по кругу :)


 
xayam ©   (2010-04-28 17:05) [21]

а кому щас легко?


 
tesseract ©   (2010-04-28 17:49) [22]


> а потом возникнут вопросы у кого заказали,


Сначала возникнет вопрос - какого черта так долго примитивные остатки формируются и накладные по полдня проводится. Таки срезы придется делать по-любому.


 
oldman ©   (2010-04-28 18:46) [23]


> worldmen   (28.04.10 15:04) [11]
> А структура БД самая правильная.


Абсолютно неправильная.
Не нужно там 3 таблицы. Достаточно одной.

id (обязателен-ли?)
name
date_in
kolvo_in
price_in
date_out
kolvo_out
price_out

Все твои проблемы решаются вычисляемыми полями без всяких запросов.


 
Anatoly Podgoretsky ©   (2010-04-28 19:18) [24]

> xayam  (28.04.2010 15:01:10)  [10]

У него связь один ко многим, нельзя в одну таблицу.


 
Anatoly Podgoretsky ©   (2010-04-28 19:21) [25]

> worldmen  (28.04.2010 15:33:16)  [16]

Это его не красит.


 
MsGuns ©   (2010-04-28 20:31) [26]

Блин, еще один складописатель :)


 
oldman ©   (2010-04-28 20:56) [27]

Удалено модератором


 
Petr V. Abramov ©   (2010-04-28 21:35) [28]

Удалено модератором



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

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

Наверх




Память: 0.53 MB
Время: 0.054 c
6-1221744381
Сергей М.
2008-09-18 17:26
2010.08.27
Indy10 и условный акцепт соединений


15-1267286593
KilkennyCat
2010-02-27 19:03
2010.08.27
про американцев


2-1273570593
Фильтор
2010-05-11 13:36
2010.08.27
Как замерить производительность приложения


2-1266744427
Тима
2010-02-21 12:27
2010.08.27
передача массива в функцию


15-1266163521
БарЛог
2010-02-14 19:05
2010.08.27
Окружность-круг, а квадрат, треугольник и etc не имеют "пары"