| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Выборка из 10 и более таблиц Paradox [D7, Paradox]
alpine © (2005-12-14 02:46:00)Доброго времени суток. Уважаемые мастаки, помогите.
Нужно составить SQL запрос, который делает выборку из 15 таблиц. ! Нужно чтоб выводились все записи одной из таблицы (например "товар.дб") а с остальных таблиц береётся только SUM(FIELD_SUMMA) и AVG(FIELD_PRICE). Таблицы связанны по полю КОД.
Очень нужно, не поленитесь, пожалуйста, ответить, если знаете конечно. Заранее благодарю.
msguns (2006-01-23 15:30:00) [1]Закрыть ветку !!!
(2006-01-23 15:28:00) [2]Удалено модератором
Desdechado (2006-01-19 17:01:00) [3]спамеров - к ногтю!
(2006-01-19 16:48:00) [4]Удалено модератором
Anatoly Podgoretsky (2005-12-22 10:11:00) [5]alpine (15.12.05 01:27) [7]
Ты сам то с этой кашей как то ориентируешься?
И чего мы тебе такого плохого сделали?
evvcom (2005-12-22 08:45:00) [6]
> Нет, что вы ... Я прошу, чтоб вы мне на примере 3 таблиц
> запрос показали
> Я то запрос написал
А чего нам пример какой-то выдумывать? Свое, что написал, выкладывай, только не в виде [7], а мы поправим.
alpine (2005-12-21 21:54:00) [7]
> ЮЮ ©
Нет, что вы ... Я прошу, чтоб вы мне на примере 3 таблиц запрос показали, если вас это конечно не затруднит.
Заранее благодарю.
ЮЮ (2005-12-21 03:03:00) [8]>Я то запрос написал, но выдаёт ошибки и не выполняется. Может у меня синтаксис неверны. Если не трудно исправьте меня, пожалуйста.
Уж не [7] ли ты предлагаешь исправлять? :)
alpine (2005-12-21 01:59:00) [9]
> evvcom ©
> Ну дык. Ты ж уже написал запрос. Разве еще что-то не работает?
Доброго времени суток. Я то запрос написал, но выдаёт ошибки и не выполняется. Может у меня синтаксис неверны. Если не трудно исправьте меня, пожалуйста.
Спасибо.
sniknik (2005-12-19 11:33:00) [10]msguns © (19.12.05 11:08) [24]
комуто это кажется прикольным, "включать дурку" в общении на форумах
http://www.livejournal.com/users/drakonka_666/20346.html?nc=6&style=mine
может тут тоже индивидум которому "слава" одного из таких покоя не дает.
(имхо конечно но думаю надо сразу прекращать при попытке автора "взять на слабо" -> "если знаете конечно", а также при игнорировании уточняющих вопросов (ясно сказано "зависит от того и того, как это у вас?", в ответ "ой не могу ваащее, но вы умные вы должны понять, спасите пожалуйста". утрировано конечно))
msguns (2005-12-19 11:08:00) [11]>Курдль © (19.12.05 10:12) [22]
>evvcom © (19.12.05 10:38) [23]
Я замечаю, что чем развернутее ответы, тем "тупее" и настырнее становится клиент. А если уж попытаться наставить его на путь истинный, перемещая внимание с "как сделать запрос" на то, что надо пересмотреть модель БД, то часто даже можно нарваться на грубость.
Прав, тыщу раз прав АП, отвечая суперлаконично и даже с грам. и пункт.ошибками,- если захотят-врубятся, если нет, то никакая "Война и мир" не поможет.
evvcom (2005-12-19 10:38:00) [12]
> Неужели никто не может мне на примере хотя бы двух таблиц
> показать запрос ?
Ну ты ж его в [12] уже сам написал! Или что-то не устраивает? Объясни уж, что тебе надо.
Курдль (2005-12-19 10:12:00) [13]
> alpine (17.12.05 01:50) [21]
1. То, за что тебе платят можно сделать и не per rectum.
2. Я бы поостерегся платить за работу программисту, который не может правильно написать слово "сделать".
3. Чтобы тебе кто-то смог помочь, уже неоднократно просили четко изложить стуктуру базы и суть требований.
Можешь послать мне на мыло kurdl@mail.ru ER-диаграмму своей базы. Желательно концептуальную и физическую модель.
alpine (2005-12-17 01:50:00) [14]РЕБЯТА Я ДЕЛАЮ ТО, ЗА ЧТО МНЕ ПЛАТЯТ И ТРЕБУЮТ, ЧТОБ БЫЛО ТАК.
Я думаю вы меня поймёте.
МНЕ НУЖНО ЗДЕЛАТЬ ВЫБОРКУ БЕЗ INSERT И СОЗДАНИЯ НОВОЙ ТАБЛИЦЫ.
ТОЛЬКО SELECT-ом. Неужели никто не может мне на примере хотя бы двух таблиц показать запрос ? Я думаю можете. ПОМОГАЙТЕ РЕБЯТА. УТОПАЮ (
msguns (2005-12-16 10:39:00) [15]Третье. Эта схема (я имею в виду твою, даже с учотом добавленного мною) может работать на учете по товаруи мгновенно "пускает петуха" при попытке вести учет по поставкам. Если не совсем понятно,поясню, что при первом все движение по гвоздю "откладывается" на одной карточке, даже если этот гвоздь приходил от надцати поставщиков с надцатью же учетными ценами. Во втором все последующее после прихода (поставки или как еще говорят "партии") движения товара фиксируются в БД именно по этому приходу (поставке). Т.е. если гвоздь поступал двумя приходами (даже если по одной цене и одного поставщика), то и любой расход будет вестись также с жесткой поставкой не только на гвоздь, но и на приходную накладную. Т.е. вместо ID товара "хэндлом" единицы движения в такой модели служит ID фактуры прихода.
Эта модель имеет кучу преимуществ и очень жаль, если разработка не позволяет перейти на нее.
msguns (2005-12-16 10:31:00) [16]Поэтому, наипервейший совет - все же рассмотреть возможность перехода на полноценный клиент-сервер.
Второе. Я бы все же определился с таким вопросом: ДЛЯ ЧЕГО НУЖНЫ ОСТАТКИ ?
Если для актуального "горячего" отображения остатка на складе в момент выписки счетов (накладных) или менеджеру для оперативного отслеживания складских остатков при формировании, например, заявки поставщику, - это одно.
Если для отчетов за период, например, бухгалтерских или складских ведомостей или журналов - это совсем другое.
Твой отчет, интегрирующий все движение по товару (или группе товаров) методом многоступенчатого запроса к куче активно используемых таблиц, может быть досточно "верен" для "бухгалтеров" (т.к. обычно охватывает прошлые периоды), но абсолютно "отфонарный" для комплектовщика (кладовщика, грузчика) или менеджера.
Я в таких случаях обоходился тем, что в "карточке" добавил поле "остаток" и заводил еще одну таблицу, куда писал все движение из обрабатывающихся документов. В результате всегда имел точный остаток как сумму "основного" остатка и "дополнительного". При "расчете" (выполняемом, естественно, в режиме полной блокировке всех таблиц) данные из "доп" таблицы учитывались в "основном" остатке и "доп" таблицы очищались (кроме счетов, по которым учитывался т.н. "резерв").
При такой модели можно было получить отчет первого типа. Правда, я и это реализовывал несколько нестандартно: я на форме показывал таблицу с "живыми" остатками, а юзер мог нажать "печать". При этом огроменными буквами ему писалось, что выведены будут остатки на такое-то время и для послной их достоверности необходимо свериться с сальовой ведомостью на начало дня и товарной обороткой за день.
Такая схема избавила меня от многочисленных "разборок" между кладовщиками и менеджерами, менеджерами и клиентами, клиентами и операторами выписки документов.
Курдль (2005-12-16 10:29:00) [17]
> У таблицы товар есть уникальное поле КОД ТОВАРА. Этот код
> проходит во всех операциях (продажа, закупка и тд. их 14).
> У каждой операции есть естественно своя таблица.
Я не делал товарных программ, зато делал множество биржевых, брокерских и т.п.
В общем случае хватает 2-х таблиц:
1. ТОВАР
2. СДЕЛКИ
ТОВАР - это справочник всего, чем можно торговать вне зависимости от того, есть это у тебя, или нет.
СДЕЛКИ - это покупка, продажа, залог, репо и т.п. Важно, что в результате сделки товар либо прибывает, либо убывает. Все! Этого достаточно, чтобы постоянно знать сколько и какого товара в наличии, почём куплен, насколько удачно перепродан.
Дальше сущности уже "добавлять по вкусу": КОНТРАГЕНТЫ, ДОКУМЕНТЫ, СЧЕТА и так далее.
Но откудова 15 таблиц?
msguns (2005-12-16 10:16:00) [18]>alpine (16.12.05 01:04) [13]
Теперь изложено ясно, кратко, умело (почти по Воланду ;))
Охохонюшки.. Видимо, ты пошел по тому же тернистому пути со множеством таблиц (таблица для каждого типа док-та, а точнее даже две, а если еще учесть прододки, то как минимум три), по которому ходитли тысячи не шибко опытных разработчиков. Увы, и я в их числе..
Первое. Для сетевогопарадокса такая модель может жить лишь в единственном случае: если помимо собственно "документых" таблиц есть еще подробная "карточка" с дублированием движения из всех документов. Т.е. при записи "в документ" надо писать и в карточку. И сделать "расчет", когда за период (обычно день или декаду - зависит от объемов и интенсивности пользовательских запросов к БД) данные из документов прописываются в предварительно вычищенную за этот же период картотеку.
Такая технология несколько громоздка и даже неудобно при "нагруженной" БД, но она дает гарантию 100% достоверности информации при любых сбоях и ошибках операторов.
Другая технология, в том числе и ведение таблицы актуальных остатков неизбежно приведет к потере достоверности и появлению "ошибок": остатки не соответсвуют "книжным", баланс "не идет", несоответствие сальдовок обороткам и т.д.
Sergey13 (2005-12-16 09:34:00) [19]2 [13] alpine (16.12.05 01:04)
> У каждой операции есть естественно своя таблица.
Это не естественно. Даже противоестественно. Даже, не побоюсь этого слова, извращенно. 8-)
ЮЮ (2005-12-16 09:08:00) [20]>Так же могут быть критерии отбора, например может указваться период
Вот тут могут возникнуть проблемы при многопользовательском режиме, т.к. 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),
...
| |
Страницы: 