Запрос из подчиненной таблицы

← →
Julia (2004-01-05 07:13) [0]

Подскажите, пожалуйста. Помогите найти другое решение.
Есть 2 таблицы: главная и подчиненная. Запросом беру необходимые данные из подчиненной и сравниваю циклом в цикле
while not eof Table1 и while not eof Запрос, и если Table1.Field1=Запрос.Field1, то Table1 корректирую и Table1.Field2 присваиваю значение из определенного поля запроса. Затем Table1.First, а Запос.Next и все сначала.
Процесс идет довольно длительно, учитывая что Table1 крутится с начала до самого конца столько раз, сколько записей в запросе. Может, есть другой выход?

← →
Ильш (2004-01-05 07:18) [1]

А зачем Table1.First? Ты же уже вроде бы проглядел все записи с начала Table1? Так иди дальше. Зачем First?

← →
Julia (2004-01-05 07:26) [2]

Я беру первую запись запроса. Работаю с ней. И в этот момент таблицу проглядываю с начала до конца. Нашла то, что надо в таблице и заполнила в ней поле. Затем яперехожу к следующей записи запроса и опять ищу то, что надо в таблице, конечно же сначала до конца.

← →
Julia (2004-01-05 07:50) [3]

Как сделать это через update?

← →
Sergey13 (2004-01-05 08:24) [4]

В общем случае примерно так:
update table1
set pole1=(select pole1 from table2 where ...)
В подзапросе по условию должна выводиться ОДНА запись.

← →
Julia (2004-01-05 08:45) [5]

SERGEY13.
У меня пример такой. Главная таблица содержит инф-цию по пациенту, подчиненная - услуги ему оказанные. Нужно запросом суммировать оплату за услуги по пациенту в подчиненной таблице и сумму подставить в главную таблицу. Как их связать в подобном Update по полю Table1.cod и Запрос на сумму.Cod. Была бы вместо запроса таблица я бы написала
update table1 as a
inner join table2 as b
on a.cod=b.cod
set a.summa=b.summa
Но проблема в том, что у меня не Table2, а запрос.

← →
Sergey13 (2004-01-05 09:04) [6]

2Julia (05.01.04 08:45) [5]
Ну во первых апдейтить таблицу пациентов при этом плохой тон. Я не говорю что это совсем уж неправильно, но криво - это точно.
Тебе (если уж шибко хочется) нужно примерно так:
update table1 a
set a.summa=(select sum(b.summa) from table2 b where a.cod=b.cod)

Но повторюсь, это неправильно. Эту сумму можно получать динамически, а не апдейтить главную таблицу при каждом новом платеже в подчиненной.
Нечто вроде:
select a.cod,sum(b.summa)
from table1 a,table2 b
where a.cod=b.cod
group by a.cod

>Но проблема в том, что у меня не Table2, а запрос.
Не понял, это то тут при чем?

← →
Julia (2004-01-05 09:15) [7]

Sergey13.
Это я первоначально и делала в динамике, но программа срезается после обработки нескольких пациентов. Дает ошибку памяти kernel32(т.к. я выполняю сразу и другие запросы на вычисление других сумм), видимо из-за того что память забивается этими запросами, хотя я их вроде и закрывала. В общем, устранить причину мне так и не удалось. Поэтому я и перехожу к апдейту, но делаю это не как ты думаешь при каждом новом платеже, а 1 раз в месяц перед выполнением расчетов.

← →
Sergey13 (2004-01-05 09:25) [8]

2Julia (05.01.04 09:15) [7]
>(т.к. я выполняю сразу и другие запросы на вычисление других сумм)
В потоках что ли?
>В общем, устранить причину мне так и не удалось
Но это не причина, ИМХО, для перехода к заведомо неправильному решению. Искать надо тщательнее. Велики ли объемы данных?

← →
Julia (2004-01-05 09:39) [9]

>В потоках что ли?
Нет, не в потоках, а сразу вполняется другой запрос на обработку других данных из подчиненной таблицы. И такого рода запросов видов 8-10.
>Велики ли объемы данных?
В том то и парадокс, что данных-то в базе не более 500, т.е. давольно-таки мало. А после обработки 16 пациентов дает ошибку памяти. Долго билась над этим. Чуть подкорректировала запросы, но единственно чего добилась, программа стала срезаться после скажем 26 пациентов.

← →
Sergey13 (2004-01-05 09:48) [10]

2Julia (05.01.04 09:39) [9]
>а сразу вполняется другой запрос на обработку других данных из подчиненной таблицы. И такого рода запросов видов 8-10.
Ну прям таки сразу. 8-)

>А после обработки 16 пациентов дает ошибку памяти.
Ты их в циклах гоняешь? Наверное тут собака порылась. Хотя точный диагноз возможен только в присутствии еще живого пациента.

И что значит "срезаться"? Может у тебя винда кривая? Файл подкачки не выключен случаем? Что то странно больно на таких объемах такое поведение.

← →
VAleksey (2004-01-05 09:50) [11]

Посмотри в FAQ рекомендации по настройке BDE.

← →
Julia (2004-01-05 09:56) [12]

>Ты их в циклах гоняешь?
Нет никаких циклов. Процесс идет так.
1. выполнила запрос типа:
select sum(b.summa)
from table2 b
2. Подстановка в table1:
table1.Edit
table1.Summa:=SQL.sum(summa)
table1.Post;

Может, ошибка от того, что постоянно идет Edit,Post?

>Может у тебя винда кривая?
Дело в том, что это наблюдается на 2-ух разных компьютерах.

← →
Sergey13 (2004-01-05 10:09) [13]

2Julia (05.01.04 09:56) [12]
>Нет никаких циклов. Процесс идет так.
По кнопке? И именно на 16 "срезается"? И как ты там "Чуть подкорректировала запросы"? Секцию "where" в select добавила? Потом, ты же пишешь, что "первоначально и делала в динамике" и только переходишь на апдейты, а тут те-же яйца, только вид с боку. 8-)

← →
Julia (2004-01-05 10:18) [14]

Нет, сейчас (с while not eof- точное описание работы в моем первом вопросе) все идет прекрасно. Только на моем компе со свободными ресурсами -86% идет расчет показателей (1 раз в месяц) в течение 15 минут, а на другом, где оперативка сильно забита и свободных ресурсов 73% расчет идет аж 2 часа. Вот я ищу другое решение и хочу перейти к апдейт. По-моему это корректно.

← →
Sergey13 (2004-01-05 10:33) [15]

2Julia (05.01.04 10:18) [14]
Совсем ты меня запутала. 8-)
Каких ресурсов? Нефтяных? И от чего проценты? Где оперативка забита там ее скока? 16М или 256М? Чем забита? Почему нельзя освободить? Какая ОС в конце концов? Какие камни на машинах? Данные по сети гоняются или локально?
Но при самом плохом раскладе 500 записей за 2 часа - это очень долго, ИМХО.

← →
paul_k (2004-01-05 10:38) [16]

что надо сделать?
насколько я понял выбрать все записи подчиненной таблицы связанные с записью в главной, проссумировать поле n в подчиненной и записать это значение в поле k главной таблицы?
если так то ответ дан в
Sergey13 © (05.01.04 08:24) [4]
только чуть чуть надо подумать и написать
update table1 set pole_k = (select sum(table2.pole_n) from table2 where table2.kodTable1=table1.kod) where тут пишем условия выбора полей из table1

← →
Julia (2004-01-05 10:42) [17]

Ну конечно же системные ресурсы, а не свободные ресурсы, Sergey13. Загляни у себя МОЙ КОМПЬЮТЕР, Свойства, быстродействие и поймешь о чем я. Оперативки и там и у меня 256, windows98.
> Данные по сети гоняются или локально?
Локально
>Но при самом плохом раскладе 500 записей за 2 часа - это очень долго, ИМХО.

В том то все и дело. А освобождать их оперативку не моя проблема. Лучше я от циклов перейду к апдейт. Вот и проблема времени обработки решится. Так-то всяко быстрее. Просто был вопрос, как этот апдейт написать.
Большой привет! 8-)

← →
VAleksey (2004-01-05 10:47) [18]

> Julia (05.01.04 10:42) [17]

а запрос типа, будет быстрее работать...
Ну ну..
Не факт.
А ресурсоемкость ;-) от использования запроса возможно и возрастет.

← →
Julia (2004-01-05 10:53) [19]

VAleksey © (05.01.04 10:47) [18]
Update, я думаю, будет быстрее, чем если база будет в цикле While not eof (что я описала в своем вопросе), тем более, что мне таким образом нужно корректировать несколько полей главной базы.

← →
Ильш (2004-01-05 11:02) [20]

> Нужно запросом суммировать оплату за услуги по пациенту
> в подчиненной таблице и сумму подставить в главную таблицу.

Эту сумму нужно получать динамически! А с ошибками надо разбираться. Подход предлагаемый тобой соершенно неверен. Кто ж так делает???
Главная проблема может крыться в самом Парадоксе. Тот еще движок :( Может на мыло киданешь базы. Интересно разобраться.

← →
Julia (2004-01-05 11:17) [21]

>Ильш © (05.01.04 11:02) [20]
>Подход предлагаемый тобой соершенно неверен
ПОЧЕМУ???????
Базы скинуть могу. Но что ты в них поймешь? Нужно кидать и все мои запросы.

← →
Johnmen (2004-01-05 11:25) [22]

>Julia

А самый главный вопрос - зачем это вообще нужно ? В чём резоны ?

← →
Julia (2004-01-05 11:29) [23]

Уменьшить время обработки. Прочти мой вопрос.

← →
Johnmen (2004-01-05 11:41) [24]

Очень сложная обработка ? Очень много записей в таблицах ?

>Прочти мой вопрос

А есть сомнения в том, что прочел ? Тогда - прочел... И там ни слова о том, зачем эта "обработка" вообще нужна...

← →
Sandman25 (2004-01-05 11:48) [25]

Я выполнял похожую вещь, с помощью update table1 set field1 = (select sum(amount*price) from table2 where table2.table1_id = table1.id) where id=?
И очень даже быстро работало. Тоже Paradox, правда, D6.

← →
Julia (2004-01-05 11:50) [26]

Прочти paul_k © (05.01.04 10:38) [16]. Он правильно понял и в общем-то я и решила перейти от циклов к update.

← →
Sandman25 (2004-01-05 11:54) [27]

[26] Julia (05.01.04 11:50)

Если это мне, то я в курсе. Прсото хотел написать, что дело не в том, что СУБД Paradox, а в настройках компьютера или самой программе.

← →
Julia (2004-01-05 11:58) [28]

>Sandman25 © (05.01.04 11:54) [27]
НЕТ-нет .Это не тебе. Это Johnmen © (05.01.04 11:41) [24]. А тебе Sandman25 большое спасибо за подтверждение моей мысли.

← →
Johnmen (2004-01-05 12:01) [29]

>Julia

Девушка, а вы мои посты читаете ? Вопросы уточняющие понимаете ?
Ещё раз. Зачем эта "обработка" вообще нужна ? В принципе ?

← →
Julia (2004-01-05 12:13) [30]

>Johnmen © (05.01.04 12:01) [29]
>Зачем эта "обработка" вообще нужна ? В принципе ?

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

← →
Johnmen (2004-01-05 12:17) [31]

>Julia

О, Господи ! Да понятно, что вы делаете !!! Я просто поинтересовался - ЗАЧЕМ ??? В ЧЕМ ВЫГОДА ОТ НАЛИЧИЯ СУММЫ В ГЛАВНОЙ ТАБЛИЦЕ ? (в данном конкретном случае...)

← →
Julia (2004-01-05 12:28) [32]

>Johnmen © (05.01.04 12:17) [31]
Прошу прощения, если вывела вас из себя. Все же это интерактивное общение, а не "в живую". Данные ДОЛЖНЫ быть собраны в главной (и не только эти, а многие другие. Они должны находиться в одном месте. Вот и собираю...). Если все понятно, ждем идей.

← →
Johnmen (2004-01-05 12:34) [33]

>Julia (05.01.04 12:28)
>Прошу прощения, если вывела вас из себя.

Не удастся :)

По поводу "сборки в одном месте" уже всё сказали.
Но мне интересно, зачем собирать, т.е.хранить, то, что всегда можно получить запросом... Насколько оправдана такая денормализация.

← →
Sandman25 (2004-01-05 12:47) [34]

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

← →
Julia (2004-01-05 12:47) [35]

>Johnmen © (05.01.04 12:34) [33]
Нужно обработать информацию по каждому пациенту (главная база), учитывая оказанные ему услуги (подчиненная таблица) ЗА МЕСЯЦ. И на основании этих данных (и еще многих других) расчитать МЕСЯЧНУЮ з/плату медицинскому персоналу (причем, по бюджету и платно), показатели их работы. Рыться то там, то там затруднительно и практически невыполнимо. Вся информация должна быть в одном месте, чтобы наряд по пациенту имел окончательный вид и был готов к многочисленным расчетам. Запрос не прокатит.
Если есть время и желание, можешь ещё отговаривать меня от идеи хранить в одном месте. Но в данном случае это целесообразно. Жду идей. А в общем-то, идеи уже были.

← →
paul_k (2004-01-05 12:49) [36]

2Julia
Если смотреть с точки зрения правильного проектирования БД мой ответ является бредом сивой кобылы.
Вы спросили как сделать фигню - я Вам это сказал. как говорится - какой вопрос, такой ответ.
Но должен добавить, что последующие ораторы абсолютно правы.
нельзя хрранить в главной таблице данные из подчиненных.
простейший пример: "продвинутый" усер через какой нибудь DbExpert грохнул запись в подчиненной. вывод - Ваши данные можно выбросить, или подобное "обновление" главной таблицы надо проводить на каждый просмотр.
То есть если Вы хотите хранить сумму каждого перечня в шапке просто для отображения в списке - это бред. Если Вы храните эту сумму как "контрольную" и рядом отображаете сумму перечня, то может это и имеет некий смысл. Но тогда логичнее хранить все контрольные суммы в отдельной таблице что-бы можно было видеть историю их изменения

← →
paul_k (2004-01-05 12:52) [37]

И в продолжение.
Для Вашей задачи , ИМХО, вообще дельфи практически не нужны.
Надо нарисовать красивый отчет в том-же CrystalReporte, например
и передав в отчет к примеру id клиента и период получить красивошную бамажку.

← →
Sandman25 (2004-01-05 12:53) [38]

[36] paul_k © (05.01.04 12:49)

О чем Вы говорите, тут ведь Paradox используется. Никаких триггеров, view, разделения прав доступа. А в таком случае с помощью редактирования записей можно добиться чего угодно. Никакая структура БД не защитит от злостных вредителей, изменяющих данные в свою пользу.

← →
paul_k (2004-01-05 13:00) [39]

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

← →
Sandman25 (2004-01-05 13:08) [40]

[39] paul_k © (05.01.04 13:00)

Как раз таки против непродвинутых лучше дублировать инфо. Если они исправят сумму только в той ("главной") таблице, по которой идет расчет отчетов, то верные данные можно будет восстановить по "детальной" таблице, найдя суммы заново :)

← →
paul_k (2004-01-05 13:12) [41]

2Sandman25
Все может быть.....
а логи писать надо

← →
Julia (2004-01-05 13:17) [42]

Мальчики, деликатно прерву ваш диалог. Идея понятна. На том и спасибочки. С новогодними вас праздниками :)

← →
Sandman25 (2004-01-05 13:17) [43]

Взаимно :)

← →
paul_k (2004-01-05 13:20) [44]

Julia
И Вас также
Sandman25
С прошедшими

← →
Sandman25 (2004-01-05 13:22) [45]

← →
Julia (2004-01-05 13:24) [46]

Ну и с наступающим РОЖДЕСТВОМ за одно!

Запрос из подчиненной таблицы Найти похожие ветки