проблема с объединением 2-х и более таблиц

← →
Jiny (2005-01-11 20:16) [0]

Проблема такая :
есть 2 табл. приход.и расход. кассовые ордера .
Как их связать таким образом, чтобы можно было отобразить и приход и расход за один день, примерно так :

Дата Ост.нач. Приход Расход Ост.кон.
--------------------------------------------------
12.01.05 100 90 110 80
13.01.05 80 120 20 180
14.01.05 180 40 20 200
и т.д.

Как это можно сделать ?

← →
DSKalugin © (2005-01-11 20:30) [1]

а где структура таблиц?
каким образом связаны 2е таблицы?

П.С. не достаточноисходных данных для решения этого простого вопроса

← →
Rule © (2005-01-11 20:41) [2]

DSKalugin © (11.01.05 20:30) [1]
присоединяюся, структуру таблиц в студию

← →
Yurisimus (2005-01-12 06:37) [3]

Структура таблиц такая (упрощенно):

id - уникальный идентификатор (INteger)
num_doctype - тип документа (Integer)
data_sd - дата выписки документа (timestamp)
num_kl - № контрагента (integer)
name_kl - наименование контрагента varchar(50)
sum_sd - numeric(15,2) сумма документа
note_sd - varchar(50) комментарий
+ штук 20 полей косвенных полей

← →
jiny (2005-01-12 06:39) [4]

обе таблицы с одинаковой структурой

← →
jiny (2005-01-12 07:52) [5]

И дабы не выходить за пределы данной темы вопрос еще такой :
есть 5 таблиц ( tovar,fr1_1,fr1_2,fp1_1,fp1_2)

tovar - товары , вот структура

num_tov - номер товара (integer),
num_firm - номер завода-изготовителя (integer),
name_firm - имя завода-изготовителя (varchar)
ost_tek - остаток текущий

fr1_1,fp1_1 - шапка расходных,приходных фактур , вот структура

id - integer
data_sd timestamp,
num_doctype integer,
num_kl integer,
name_kl varchar(50),
sum_sd numeric(15,2)

fr1_2,fp1_2 - спискок расходных,приходных фактур , вот структура

id - связка с шапкой к списку integer
id_tov - связка с таблицей Tovar integer
kol - количество проданного/купленного товара
cost_sd - цена по документу

нужно чтобы при запросе он выдавал следующую информацию, к примеру
по фирме (tovar.num_firm=35)

По фирме Рациофарм за период с 01.01.05 по 11.01.05

Товар Закуп Продано Остаток
--------------------------------------------------------
Диклофенак 300 200 100
Гепабене 250 50 200
Актиферрин 300 150 150
и т.д.
--------------------------------------------------------
т.е. брать приход и расход где
id_tov in (select num_tov from tovar where num_firm=35)
и объединять все это в разрезе каждого товара

← →
Johnmen © (2005-01-12 09:16) [6]

Напрягаться лень, но [0] одним запросом труднореализуем.
Рекомендую писать хранимую процедуру.

← →
ЮЮ © (2005-01-12 09:25) [7]

[4] + к том уже излишне ресурсоёмок, т.к. "Ост.нач." придется пересчитывать для каждой записи результирующего НД, а в ХП достаточно для первого дня периода.

← →
jiny (2005-01-12 09:52) [8]

можно конкретный пример как мне все это реализовать, заранее благодарен

← →
jiny (2005-01-12 11:10) [9]

т.е. я еще не работал с ХП, можно примерчик как мне реализовать сво сабж и 1, и 2 ?

← →
jiny (2005-01-12 12:03) [10]

Я так понимаю, все спят

← →
msguns © (2005-01-12 12:16) [11]

А вот вопросы еще:
А зачем приходы в один стакан, а расходы - в другой, если структура идентична ? И, если уж разлили в два разных стакана, то на кой ляд нужен "тип документа" ?
Судя по всему, справочники не для джидаев ? Если у меня 10000 разных товаров от одного завода-изготовителя, то в справочнике товаров его название будет повторено 10000 раз ? То же относится и к "клиентам".
Документы типа "Возвраты" или "Списания" не существуют в конторе как класс ? А если появятся, то мы для них заведем соответствующий "джентельменский набор" таблиц (стаканов) ?
Цена закупки товара что, не меняется ? А если меняется, то где видно почем купили-почем продали, т.е. как бы реализованную торговую наценку (или доход от продажи, если опт). Или учет по средневзвешенному ? НДС в Коране не предусмотрен ?

Мдя, представляю сколько будет зубовного скрежета у пользователей. Нет данных о складе, отсутствует даже намек на маркировку товара, его упаковку, ед.измерения, срок хранения и т.д. Бухгалтерией даже не пахнет.. Где данные о проплатах, заявках и т.д ?

← →
msguns © (2005-01-12 12:18) [12]

Вы не с того начинаете, уважаемый. Здание не строится с трубы или оконной рамы на мансарде. Оно сначала проектируется вообще-то

>msguns © (12.01.05 12:16) [11]

Во, что ты от него хочешь...:)
Это же полновесная система. А для её реализации надо въезжать в предметную область, как минимум !

← →
jiny (2005-01-12 14:24) [14]

для msguns
Опять повторюсь :
>>Структура таблиц такая (упрощенно):
слово УПРОЩЕННО вам о чем нибудь говорит ?!
в каждой из этих таблиц, как минимум 100 полей, просто все поля я не стал упоминать, т.к. к вопросу они не относяться, обос%ать продукт всегда просто, а вы попробуйте помочь, если вы считаетесь не ламером.
Если вернуться к разговору о "стаканах", то скажу, что разлил я их по разным "стаканам", т.к. механизм минусования/плюсования со скада я реализовал посредством триггеров, а объединить посредством UNION ничего не стоит, так что если не можете ответить на поставленный вопрос, не портите хотябы настроение, и так без факторов хватает.
Насчет "зубовного скрежета у пользователей"
Пока не слышал, надеюсь поделитесь опытом.
мда, доброжелателей не нашлось... обидно

А ты на на слабо не бери, результат будет совсем другой. Сообственно ты уже отсеял большую часть тех, кто пожелал бы ответить, а теперь это желание потеряли.

← →
jiny (2005-01-12 14:51) [16]

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

Для того, чтобы получить исчерпывающий ответ на вопрос, надо давать такие же исчерпывающие исходные данные.
Например, я не вижу смысла в наборе данных, указанном в сабже как цель запроса.
Есть оборотные ведомости, есть сальдовые, есть оборотно-сальдовые. Зачем изобретать новые ? Если же Вам надо другую, то хотя бы укажите для кого это надо: администрации, кладовщика, бухгалтера, менеджеров и т.д. По крайней мере это хоть наведет на мысль о том, что именно Вам надо получить. Не исключено, что Вы не совсем хорошо представляете себя специфику указанных категорий персонала и здесь Вас поправят или дадут хороший совет.
Я не считаю себя Мастером, но, поверьте, кое-что соображаю и в торговле, и в складском учете вообще. Да и в SQL в общем-то не новичок.

проблема с объединением 2-х и более таблиц Найти похожие ветки