Выборка из 10 и более таблиц Paradox

← →
alpine (2005-12-14 02:46) [0]

Доброго времени суток. Уважаемые мастаки, помогите.

Нужно составить SQL запрос, который делает выборку из 15 таблиц. ! Нужно чтоб выводились все записи одной из таблицы (например "товар.дб") а с остальных таблиц береётся только SUM(FIELD_SUMMA) и AVG(FIELD_PRICE). Таблицы связанны по полю КОД.

Очень нужно, не поленитесь, пожалуйста, ответить, если знаете конечно. Заранее благодарю.

← →
ЮЮ © (2005-12-14 03:21) [1]

И что все 14 таблиц одной структуры и теперь FIELD_SUMMA из всех таблиц надо складывать?

← →
evvcom © (2005-12-14 08:46) [2]

> не поленитесь, пожалуйста, ответить, если знаете конечно

конечно знаем, только ты сам не поленись и изложи минимально необходимые нам данные о структуре твоих таблиц

← →
msguns © (2005-12-14 10:10) [3]

Если в общем случае к-во исх.таблиц переменно, то надо создать "куммулятивную" таблицу и, предварительно очистив ее (DELETE FROM AGRTABLE), собирать там данные из исх.таблиц запросами типа
INSERT INTO AGRTABLE
SELECT <текст агрегирующего или выбирающего запроса>

В целом же, мне кажется, что вопрос поставлен просто некорректно из-за неверного понимания (или дизайна, если сам разрабатывал) модели данных в базе. Судя по всему речь идет о товарных остатках на складе, в качестве списка товаров понимается таблица, упомянутая "товар.дб", сами же остатки определяются суммированием движения, почему-то "растащенного" по 15 таблицам (по таблице на месяц что ли ?). Если так, то имеем пример дилетантской разработки модели БД, которую надо срочно выкрасить и выбросить, заменив на "классику": документ+фактура.

← →
Sergey13 © (2005-12-14 10:14) [4]

2[3] msguns © (14.12.05 10:10)
> почему-то "растащенного" по 15 таблицам (по таблице на месяц что ли ?)
А месяцев 15 что-ли?!!! 8-)

← →
Курдль © (2005-12-14 10:21) [5]

Если парадокс умеет такое:
select T.*, (select sum(FIELD_SUMMA) from TABLE_1 T1 whereT1.CODE = TV.CODE) as SUMMA, (select avg(FIELD_PRICE) from TABLE_2 T2 whereT2.CODE = TV.CODE) as PRICE, from TOVAR_BD TV

Если не умеет, то можно обдумать использование GROUP BY.

> Очень нужно, не поленитесь, пожалуйста, ответить, если знаете
> конечно.

Честно говоря, я поймал себя на мысли, что поленюсь. Т.к. для нормального запросотворчества мне нужна ER-диаграма. Или хотя бы качественное описание структуы БД в терминологии реляционного принципа типа "Есть таблица Т1, связанная "один-ко многим" с таблицей Т2 по внешнему ключу CODE..."

← →
alpine (2005-12-15 01:03) [6]

> Курдль ©

Вроде ошибку не выдаёт, но и не считает сумму (select sum(FIELD_SUMMA) from TABLE_1 T1 whereT1.CODE = TV.CODE) as SUMMA,), когда есть условие (whereT1.CODE = TV.CODE). Без условия считает, но это не нужно.

← →
alpine (2005-12-15 01:27) [7]

Я сделал такой запрос

SELECT DISTINCT Tovar.Kod, Tovar.Fullname, Tovar.Grup, Tovar.EdIzm, Tovar.Season, Tovar.Country, Tovar.ORGin, Tovar.CZrub, Tovar.CZye, Tovar.Nazenka,Tovar.Kurs, Tovar.OLDCZrub, Tovar.DataOldCZ, Tovar.Realis, Tovar.CP1rub, Tovar.CP1ye, Tovar.OLDCP1rub, Tovar.DataOldCP1, Tovar.CP2rub, Tovar.CP2ye, Tovar.Nazenka2, Tovar.CP3rub, Tovar.CP3ye, Tovar.Nazenka3, Tovar.Info, SUM( Zakupka.KOLICHESTVO ) Zakupka."Zakupka.KOLICHESTVO", AVG( Zakupka.PRICE ) Zakupka."Zakupka.PRICE", SUM( Otpusk.KOLICHESTVO ) Otpusk."Otpusk.KOLICHESTVO", AVG( Otpusk.PRICE ) Otpusk."Otpusk.PRICE", SUM( Skprod.KOLICHESTVO ) Skprod."Skprod.KOLICHESTVO", AVG( Skprod.PRICE ) Skprod."Skprod.PRICE", SUM( Shperem.KOLICHESTVO ) Shperem."Shperem.KOLICHESTVO", AVG( Shperem.PRICE ) Shperem."Shperem.PRICE", SUM( Skvosprod.KOLICHESTVO ) Skvosprod."Skvosprod.KOLICHESTVO", AVG( Skvosprod.PRICE ) Skvosprod."Skvosprod.PRICE", SUM( Skvoszak.KOLICHESTVO ) Skvoszak."Skvoszak.KOLICHESTVO", SUM( Skpereoc.KOLICHESTVO ) Skpereoc."Skpereoc.KOLICHESTVO", AVG( Skpereoc.PRICE ) Skpereoc."Skpereoc.PRICE", SUM( Skzakaz.KOLICHESTVO ) Skzakaz."Skzakaz.KOLICHESTVO", AVG( Skzakaz.PRICE ) Skzakaz."Skzakaz.PRICE", SUM( Skspis.KOLICHESTVO ) Skspis."Skspis.KOLICHESTVO", AVG( Skspis.PRICE ) Skspis."Skspis.PRICE", SUM( Shprod.KOLICHESTVO ) Shprod."Shprod.KOLICHESTVO", AVG( Shprod.PRICE ) Shprod."Shprod.PRICE", SUM( Skperem.KOLICHESTVO ) Skperem."Skperem.KOLICHESTVO", AVG( Skperem.PRICE ) Skperem."Skperem.PRICE", SUM( Shvosprod.KOLICHESTVO ) Shvosprod."Shvosprod.KOLICHESTVO", AVG( Shvosprod.PRICE ) Shvosprod."Shvosprod.PRICE", SUM( Shvosotpusk.KOLICHESTVO ) Shvosotpusk."Shvosotpusk.KOLICH", AVG( Shvosotpusk.PRICE ) Shvosotpusk."Shvosotpusk.PRICE", SUM( Shspis.KOLICHESTVO ) Shspis."Shspis.KOLICHESTVO", AVG( Shspis.PRICE ) Shspis."Shspis.PRICE" ");
DMFrm.OPERQUERY.SQL.Add(" FROM "Tovar.DB" Tovar LEFT OUTER JOIN "Zakupka.DB" Zakupka ON (Zakupka.KOD=Tovar.Kod) LEFT OUTER JOIN "otpusk.DB" Otpusk ON (Otpusk.KOD = Tovar.Kod) LEFT OUTER JOIN "SKPROD.DB" Skprod ON (Skprod.KOD = Tovar.Kod) LEFT OUTER JOIN "SHPEREM.DB" Shperem ON (Shperem.KOD = Tovar.Kod) LEFT OUTER JOIN "SKVOSPROD.DB" Skvosprod ON (Skvosprod.KOD = Tovar.Kod) LEFT OUTER JOIN "SKVOSZAK.DB" Skvoszak ON (Skvoszak.KOD = Tovar.Kod) LEFT OUTER JOIN "SKPEREOC.DB" Skpereoc ON (Skpereoc.KOD = Tovar.Kod) LEFT OUTER JOIN "SKZAKAZ.DB" Skzakaz ON (Skzakaz.KOD = Tovar.Kod) LEFT OUTER JOIN "SKSPIS.DB" Skspis ON (Skspis.KOD = Tovar.Kod) LEFT OUTER JOIN "SHPROD.DB" Shprod ON (Shprod.KOD = Tovar.Kod) LEFT OUTER JOIN "SKPEREM.DB" Skperem ON (Skperem.KOD = Tovar.Kod) LEFT OUTER JOIN "SHVOSPROD.DB" Shvosprod ON (Shvosprod.KOD = Tovar.Kod) LEFT OUTER JOIN "SHVOSOTPUSK.DB" Shvosotpusk ON (Shvosotpusk.KOD = Tovar.Kod) LEFT OUTER JOIN "SHSPIS.DB" Shspis ON (Shspis.KOD = Tovar.Kod) WHERE Tovar.Deleted = FALSE GROUP BY Tovar.Kod, Tovar.Fullname, Tovar.Grup, Tovar.EdIzm, Tovar.Season, Tovar.Country, Tovar.ORGin, Tovar.CZrub, Tovar.CZye, Tovar.Nazenka, Tovar.Kurs, Tovar.OLDCZrub, Tovar.DataOldCZ, Tovar.Realis, Tovar.CP1rub, Tovar.CP1ye, Tovar.OLDCP1rub, Tovar.DataOldCP1, Tovar.CP2rub, Tovar.CP2ye, Tovar.Nazenka2, Tovar.CP3rub, Tovar.CP3ye, Tovar.Nazenka3, Tovar.Info ORDER BY Tovar.Kod"

ВСЁ РАБОТАЕТ. ОШИБОК НЕ ВЫДАЁТ. НО ПРИ ПОДСЧЁТЕ SUM(ЛЮБОГО ПОЛЯ) ВЫДАЁТ НЕПРАВИЛЬНЫЙ РЕЗУЛЬТАТ. ОНА ВЫДАЁТ В ДВА РАЗА БОЛЬШЕ. В ЧЁМ ДЕЛО ?? ПОДСКАЖИТЕ ПОЖАЛУЙСТА.

← →
ЮЮ © (2005-12-15 03:45) [8]

>НО ПРИ ПОДСЧЁТЕ SUM(ЛЮБОГО ПОЛЯ) ВЫДАЁТ НЕПРАВИЛЬНЫЙ РЕЗУЛЬТАТ

И это правильно. Если например в таблице Zakupka есть 2 записи для какого-то товара, а в Otpusk - 6, то Zakupka LEFT JOIN Otpusk вернёт уже 6 записей. Теперь, окажись в Skprod ещё пара записей, и в Zakupka LEFT JOIN Otpusk LEFT JOIN Skprod их станет уже 12.

Так что то, что ОНА ВЫДАЁТ В ДВА РАЗА БОЛЬШЕ - это ещё только начало :)

Объединять следует после группировки

SELECT * FROM
Tovar
LEFT JOIN (
SELECT kod, SUM(KOLICHESTVO) ZakupkaSumKOLICHESTVO, AVG( (PRICE ) )AVGZakupkaPRICE
FROM Zakupka
GROUP BY kod
) Zakupka ON ON (Zakupka.KOD=Tovar.Kod)
LEFT JOIN ...

агрегирующие подзапросы оформляются в отдельные файлы, например ZakupkaGr.sql, помещаются в БД, а запрос тогда выглядит как

SELECT * FROM
Tovar
LEFT JOIN "ZakupkaGr.sql" Zakupka ON (Zakupka.KOD=Tovar.Kod)
LEFT JOIN ...

← →
evvcom © (2005-12-15 08:50) [9]

> alpine (15.12.05 01:27) [7]

Ты бы еще в двоичном коде привел бы свой запрос. Тебя форматированию кто-нибудь когда-нибудь учил? Посмотри как оформлен запрос в [8] и как у тебя. Разницу видишь? В твоем запросе только сумашедший станет разбираться.

← →
msguns © (2005-12-15 09:18) [10]

>alpine (15.12.05 01:27) [7]
>Я сделал такой запрос

Засстрелиться ! (с) Соловьев

← →
Курдль © (2005-12-15 11:36) [11]

> alpine (15.12.05 01:27) [7]
> Я сделал такой запрос........................................................

Не. Так дело не пойдет. Если хочешь, чтобы тебя поняли - изложи проблему в доступном виде. Проще всего - положи перед собой ER-диаграму твоей БД и зарисуй интересующий фрагмент хоть прямо здесь в псевдографике.
типа
---------- ----------- | TOVAR | >-----KOD = KOD--------+| ZAKUPKA | ---------- -----------

Или хотя бы опиши в терминологии РБД.

← →
alpine (2005-12-15 15:28) [12]

> ЮЮ ©

Если не сложно,пожалуйста, напишите поподробнее. Получается в выборке мне не надо указывать SUM(FIELD) ? Его надо указывать после LEFT JOIN ? И GROUP надо делать для каждого отдельно, то есть надо делать так:

select * from tovar
LEFT JOIN (
SELECT kod, SUM(KOLICHESTVO) ZakupkaSumKOLICHESTVO, AVG( (PRICE ) AVGZakupkaPRICE
FROM Zakupka
GROUP BY kod
) Zakupka ON (Zakupka.KOD=Tovar.Kod),
LEFT JOIN (
SELECT kod, SUM(KOLICHESTVO) OtpuskSumKOLICHESTVO, AVG( (PRICE ) )AVGOtpuskPRICE
FROM Otpusk
GROUP BY kod
) Otpusk ON (Otpusk.KOD=Tovar.Kod)

и тд... Правильно ?

← →
alpine (2005-12-16 01:04) [13]

У таблицы товар есть уникальное поле КОД ТОВАРА. Этот код проходит во всех операциях (продажа, закупка и тд. их 14). У каждой операции есть естественно своя таблица. Все таблицы берут "КОД ТОВАРА" из таблицы товар. После совершения любой операции, в таблицу данной операции вводятся код товара, количество, цена, сумма, дата и ещё пару полей.

ЗАДАЧА
Мне нужно вывводить движение товара. То есть сделать SQL запрос, который берёт данные со всех таблиц. Главная таблица естественно ТОВАР, с которой берётся полей 7, а со всех операционных таблиц нужно получить общее количество ТОВАР КОДА и среднее значение ЦЕНЫ. Так же могут быть критерии отбора, например может указваться период.

УВАЖАЕМЫ МАСТАКИ, не поленитесь ,пожалуйста, помогите. Очень нужно.

← →
evvcom © (2005-12-16 08:36) [14]

> и тд... Правильно ?

Вот теперь другое дело. Правильно. Теперь вроде придраться не к чему.

> УВАЖАЕМЫ МАСТАКИ, не поленитесь ,пожалуйста, помогите. Очень
> нужно.

Ну дык. Ты ж уже написал запрос. Разве еще что-то не работает?

← →
ЮЮ © (2005-12-16 09:08) [15]

>Так же могут быть критерии отбора, например может указваться период

Вот тут могут возникнуть проблемы при многопользовательском режиме, т.к. Local View (те самые подзапросы в текстовом файле) не могут содержать парамтры, т.е. для каждого пользователя лучше иметь собственные файлы, чтобы можно было их на лету корректировать.

Я в таких случаях использовал две БД - одны сетевую, другую - локальную + гетерогенные запросы. Т.е. для отчетов я создавал локальные таблицы нужной структуры, куда помещал результаты запросов с группировкой, заполнял их просто:
DELETE * FROM ":Local:Zakupka"

INSERT INTO ":Local:Zakupka"
SELECT kod, SUM(KOLICHESTVO), AVG( PRICE )
FROM Zakupka
WHERE <условия отбора>
GROUP BY kod

А затем

select *
from tovar
LEFT JOIN ":Local:Zakupka" Zakupka ON (Zakupka.KOD=Tovar.Kod),
...

← →
Sergey13 © (2005-12-16 09:34) [16]

2 [13] alpine (16.12.05 01:04)
> У каждой операции есть естественно своя таблица.
Это не естественно. Даже противоестественно. Даже, не побоюсь этого слова, извращенно. 8-)

← →
msguns © (2005-12-16 10:16) [17]

>alpine (16.12.05 01:04) [13]

Теперь изложено ясно, кратко, умело (почти по Воланду ;))

Охохонюшки.. Видимо, ты пошел по тому же тернистому пути со множеством таблиц (таблица для каждого типа док-та, а точнее даже две, а если еще учесть прододки, то как минимум три), по которому ходитли тысячи не шибко опытных разработчиков. Увы, и я в их числе..
Первое. Для сетевого парадокса такая модель может жить лишь в единственном случае: если помимо собственно "документых" таблиц есть еще подробная "карточка" с дублированием движения из всех документов. Т.е. при записи "в документ" надо писать и в карточку. И сделать "расчет", когда за период (обычно день или декаду - зависит от объемов и интенсивности пользовательских запросов к БД) данные из документов прописываются в предварительно вычищенную за этот же период картотеку.
Такая технология несколько громоздка и даже неудобно при "нагруженной" БД, но она дает гарантию 100% достоверности информации при любых сбоях и ошибках операторов.
Другая технология, в том числе и ведение таблицы актуальных остатков неизбежно приведет к потере достоверности и появлению "ошибок": остатки не соответсвуют "книжным", баланс "не идет", несоответствие сальдовок обороткам и т.д.

← →
Курдль © (2005-12-16 10:29) [18]

> У таблицы товар есть уникальное поле КОД ТОВАРА. Этот код
> проходит во всех операциях (продажа, закупка и тд. их 14).
> У каждой операции есть естественно своя таблица.

Я не делал товарных программ, зато делал множество биржевых, брокерских и т.п.
В общем случае хватает 2-х таблиц:
1. ТОВАР
2. СДЕЛКИ

ТОВАР - это справочник всего, чем можно торговать вне зависимости от того, есть это у тебя, или нет.
СДЕЛКИ - это покупка, продажа, залог, репо и т.п. Важно, что в результате сделки товар либо прибывает, либо убывает. Все! Этого достаточно, чтобы постоянно знать сколько и какого товара в наличии, почём куплен, насколько удачно перепродан.
Дальше сущности уже "добавлять по вкусу": КОНТРАГЕНТЫ, ДОКУМЕНТЫ, СЧЕТА и так далее.

Но откудова 15 таблиц?

← →
msguns © (2005-12-16 10:31) [19]

Поэтому, наипервейший совет - все же рассмотреть возможность перехода на полноценный клиент-сервер.

Второе. Я бы все же определился с таким вопросом: ДЛЯ ЧЕГО НУЖНЫ ОСТАТКИ ?
Если для актуального "горячего" отображения остатка на складе в момент выписки счетов (накладных) или менеджеру для оперативного отслеживания складских остатков при формировании, например, заявки поставщику, - это одно.
Если для отчетов за период, например, бухгалтерских или складских ведомостей или журналов - это совсем другое.
Твой отчет, интегрирующий все движение по товару (или группе товаров) методом многоступенчатого запроса к куче активно используемых таблиц, может быть досточно "верен" для "бухгалтеров" (т.к. обычно охватывает прошлые периоды), но абсолютно "отфонарный" для комплектовщика (кладовщика, грузчика) или менеджера.
Я в таких случаях обоходился тем, что в "карточке" добавил поле "остаток" и заводил еще одну таблицу, куда писал все движение из обрабатывающихся документов. В результате всегда имел точный остаток как сумму "основного" остатка и "дополнительного". При "расчете" (выполняемом, естественно, в режиме полной блокировке всех таблиц) данные из "доп" таблицы учитывались в "основном" остатке и "доп" таблицы очищались (кроме счетов, по которым учитывался т.н. "резерв").

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

← →
msguns © (2005-12-16 10:39) [20]

Третье. Эта схема (я имею в виду твою, даже с учотом добавленного мною) может работать на учете по товару и мгновенно "пускает петуха" при попытке вести учет по поставкам. Если не совсем понятно,поясню, что при первом все движение по гвоздю "откладывается" на одной карточке, даже если этот гвоздь приходил от надцати поставщиков с надцатью же учетными ценами. Во втором все последующее после прихода (поставки или как еще говорят "партии") движения товара фиксируются в БД именно по этому приходу (поставке). Т.е. если гвоздь поступал двумя приходами (даже если по одной цене и одного поставщика), то и любой расход будет вестись также с жесткой поставкой не только на гвоздь, но и на приходную накладную. Т.е. вместо ID товара "хэндлом" единицы движения в такой модели служит ID фактуры прихода.
Эта модель имеет кучу преимуществ и очень жаль, если разработка не позволяет перейти на нее.

← →
alpine (2005-12-17 01:50) [21]

РЕБЯТА Я ДЕЛАЮ ТО, ЗА ЧТО МНЕ ПЛАТЯТ И ТРЕБУЮТ, ЧТОБ БЫЛО ТАК.
Я думаю вы меня поймёте.

МНЕ НУЖНО ЗДЕЛАТЬ ВЫБОРКУ БЕЗ INSERT И СОЗДАНИЯ НОВОЙ ТАБЛИЦЫ.

ТОЛЬКО SELECT-ом. Неужели никто не может мне на примере хотя бы двух таблиц показать запрос ? Я думаю можете. ПОМОГАЙТЕ РЕБЯТА. УТОПАЮ (

← →
Курдль © (2005-12-19 10:12) [22]

> alpine (17.12.05 01:50) [21]

1. То, за что тебе платят можно сделать и не per rectum.
2. Я бы поостерегся платить за работу программисту, который не может правильно написать слово "сделать".
3. Чтобы тебе кто-то смог помочь, уже неоднократно просили четко изложить стуктуру базы и суть требований.
Можешь послать мне на мыло kurdl@mail.ru ER-диаграмму своей базы. Желательно концептуальную и физическую модель.

← →
evvcom © (2005-12-19 10:38) [23]

> Неужели никто не может мне на примере хотя бы двух таблиц
> показать запрос ?

Ну ты ж его в [12] уже сам написал! Или что-то не устраивает? Объясни уж, что тебе надо.

← →
msguns © (2005-12-19 11:08) [24]

>Курдль © (19.12.05 10:12) [22]
>evvcom © (19.12.05 10:38) [23]

Я замечаю, что чем развернутее ответы, тем "тупее" и настырнее становится клиент. А если уж попытаться наставить его на путь истинный, перемещая внимание с "как сделать запрос" на то, что надо пересмотреть модель БД, то часто даже можно нарваться на грубость.
Прав, тыщу раз прав АП, отвечая суперлаконично и даже с грам. и пункт.ошибками,- если захотят-врубятся, если нет, то никакая "Война и мир" не поможет.

msguns © (19.12.05 11:08) [24]
комуто это кажется прикольным, "включать дурку" в общении на форумах
http://www.livejournal.com/users/drakonka_666/20346.html?nc=6&style=mine

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

← →
alpine (2005-12-21 01:59) [26]

> evvcom ©

> Ну дык. Ты ж уже написал запрос. Разве еще что-то не работает?

Доброго времени суток. Я то запрос написал, но выдаёт ошибки и не выполняется. Может у меня синтаксис неверны. Если не трудно исправьте меня, пожалуйста.
Спасибо.

>Я то запрос написал, но выдаёт ошибки и не выполняется. Может у меня синтаксис неверны. Если не трудно исправьте меня, пожалуйста.

Уж не [7] ли ты предлагаешь исправлять? :)

← →
alpine (2005-12-21 21:54) [28]

> ЮЮ ©

Нет, что вы ... Я прошу, чтоб вы мне на примере 3 таблиц запрос показали, если вас это конечно не затруднит.

Заранее благодарю.

> Нет, что вы ... Я прошу, чтоб вы мне на примере 3 таблиц
> запрос показали

> Я то запрос написал

А чего нам пример какой-то выдумывать? Свое, что написал, выкладывай, только не в виде [7], а мы поправим.

alpine (15.12.05 01:27) [7]
Ты сам то с этой кашей как то ориентируешься?
И чего мы тебе такого плохого сделали?

← →
имя (2006-01-19 16:48) [31]

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

спамеров - к ногтю!

← →
имя (2006-01-23 15:28) [33]

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

Закрыть ветку !!!

Выборка из 10 и более таблиц Paradox Найти похожие ветки