Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Обновление первых записей [D6, dBase, FoxPro]

Страницы: 1 2 >
skiph © (2005-08-31 07:51:00)
Нужно выполнить запрос вида:
Update fkuude SET ПОЛЕ=НОВОЕ_ЗНАЧЕНИЕ FROM (SELECT TOP 100 * FROM fkuude WHERE некоторый запрос) AS t1 WHERE t1.ID_Rec=fkuude.ID_REC

Т.е. мне нужно изменить не все записи, соответствующие "некоторому запросу", а только первые сто. Но при выполнении этого запроса Delphi ругается на первый FROM (тот, что после SET). Похоже, что здесь он не реализован. Как по другому можно решить эту задачку? Можно, конечно, отдельно выполнить
SELECT TOP 100 *
FROM fkuude
WHERE некоторый запрос
а затем, для каждой строчки, производить Update, но это чрезвычайно долго!
Заранее благодарен

Sergey13 (2005-09-05 10:18:00) [1]
2[26] skiph © (05.09.05 05:01)
Ну тогда я бы предложил решение "в лоб".
1.Формируешь нужный список
2.Определяешь количество записей в списке
3.Определяешь количество телефонистов
4.Делишь первое на второе и получаешь среднюю загрузку на человека
5.В цикле апдейтишь полученный набор вставляя дату и исполнителя
6.Печатаешь списки по исполнителям на дату.

skiph (2005-09-05 05:01:00) [2]
2 Sergey13
> Если есть, то давай телефонистам диапазон первичного ключа. Если таблица сильно модифицируемая (сомневаюсь), можно добавить отдельное поле типа "номер по порядку", которое периодически обновлять для исключения больших дыр и соответственно более равномерного распределения нагрузки для телефонистов.

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

Sergey13 (2005-09-02 15:25:00) [3]
2[24] Anatoly Podgoretsky © (02.09.05 15:13)
>Пока он ничего другого не указывает
Пока он вообще молчит. Ждем-с. 8-)

Anatoly Podgoretsky (2005-09-02 15:13:00) [4]
Sergey13 © (02.09.05 14:21) [23]
Не на примерно равные, а на равные и именно по 100, за исключением последней конечно. Пока он ничего другого не указывает и это не вся информация которая нужна для решения, возможно и решение не может быть. Просто взгляни на задачу шире.

Sergey13 (2005-09-02 14:21:00) [5]
2 [21] Anatoly Podgoretsky © (02.09.05 13:29)
Ты напираешь на "именно 100 записей". В сабже так и сказано. Правильно. Но по смыслу (как я понял), автору надо кучу записей делить на примерноравные кучки.

[12] skiph © (02.09.05 05:38)
> то и вводится дробление базы по частям (не обязательно на сотни, это уже >пользователь сам указывает, я только для примера назвал это число).

И с этим предложенный мной вариант справится. Может и не идеально, но справится. А с оговоркой из [13] про доп.поле справится почти идеально.

В прочем, я и не настаиваю на единственности этого решения.

wertolet (2005-09-02 14:19:00) [6]
Если списки формируются один раз в день, тогда можно добавить вычисляемое поле с номером по порядку.

Anatoly Podgoretsky (2005-09-02 13:29:00) [7]
Sergey13 © (02.09.05 10:05) [17]
Исключено по причине принципов работы БД и SQL и казаном варианте запрос и указаном требовании именно 100 записей, а не записи между 1 и 100. Подумай внимательнее, не сгоряча.

-=snoop=- (2005-09-02 11:40:00) [8]
2 Anatoly Podgoretsky © (02.09.05 10:00) [16]
Это тривиально, но в принципе неправильно, такое работает только на таблицах, в которых запрещено удаление

можно после каждого удаления делать апдейт поля.
конечно будет меняться содержание списка, но оно и так будет меняться...

2skiph © а сколько записей в базе? есть зависимые таблици?

Виталий Панасенко (2005-09-02 10:54:00) [9]

> Anatoly Podgoretsky © (02.09.05 10:13) [18]
> Привожу цитату "а только первые сто", указаный тобой запрос
> не удовлетворяет эту условию, кроме особых случаев.
> Решение есть, оно близкое, но оно другое.

Поменять движок...:-))) АДО(даже с этим форматом TOP 100 работает),ЖарПтица...:-)))

Anatoly Podgoretsky (2005-09-02 10:13:00) [10]
Привожу цитату " а только первые сто", указаный тобой запрос не удовлетворяет эту условию, кроме особых случаев.
Решение есть, оно близкое, но оно другое.

Sergey13 (2005-09-02 10:05:00) [11]
2 [16] Anatoly Podgoretsky © (02.09.05 10:00)
Работает это везде без исключения. Просто важно решить - устроит ли заказчика результат работы. 8-)

Anatoly Podgoretsky (2005-09-02 10:00:00) [12]
Виталий Панасенко (02.09.05 09:56) [15]
select * from table where keyfield between 1 and 100
select * from table where keyfield between 101 and 200
и тд... Это тривиально...

Это тривиально, но в принципе неправильно, такое работает только на таблицах, в которых запрещено удаление

Виталий Панасенко (2005-09-02 09:56:00) [13]
сорри, не туды кликнул с просонья....

> Sergey13 © (02.09.05 09:30) [13]
> 2 [12] skiph © (02.09.05 05:38)

> то давай телефонистам диапазон первичного ключа.

человек дело говорит.. тогда и страдания твои отпадут (наверное..:-))
select * from table where keyfield between 1 and 100
select * from table where keyfield between 101 and 200
и тд... Это тривиально...
но идея очень (мне так кажется) хорошая..

Виталий Панасенко (2005-09-02 09:52:00) [14]

> Sergey13 © (02.09.05 09:30) [13]
> 2 [12] skiph © (02.09.05 05:38)

Sergey13 (2005-09-02 09:30:00) [15]
2 [12] skiph © (02.09.05 05:38)
Я и говорю - не туда ты роешь. 8-)
В таблице клиентов есть первичный ключ? Если нет - добавь обязательно. Если есть, то давай телефонистам диапазон первичного ключа. Если таблица сильно модифицируемая (сомневаюсь), можно добавить отдельное поле типа "номер по порядку", которое периодически обновлять для исключения больших дыр и соответственно более равномерного распределения нагрузки для телефонистов.

skiph (2005-09-02 05:38:00) [16]
> Sergey13 ©

Ладно, раз пошла такая пьянка, придется видимо углубляться в назначение всего этого. Сие есть база телефонов клиентов/потенциальных клиентов. Периодически их нужно обзванивать. Обзванивают несколько человек с домашних телефонов. Поскольку одному человеку за день несколько тысяч фирм обзвонить не реально (и в то же время нужно, чтобы дважды за день в одну фирму не звонили), то и вводится дробление базы по частям (не обязательно на сотни, это уже пользователь сам указывает, я только для примера назвал это число). Т.е. приходит утром Иванов (формированием будет заниматься только один человек, 2-й даже не нужен, отсюда и уверенность), формирует списки по количеству телефонистов и отдает им. Все. Даже если Иванову будет помогать Петров, то различать метки совсем не обязательно.

>Виталий Панасенко. Вообще база не моя, я тут человек временный, на время болезни человека, поэтому радикально менять прав таких не имею (мне так и сказали). А вот насчет Locate это я действительно забыл, попробую, поэкспериментирую. Спасибо.

Виталий Панасенко (2005-09-01 10:14:00) [17]

> > Виталий Панасенко
> все дело в том, что Tbl - это запрос(TQuery) с сортировкой,
> поэтому так просто изменить в нем нельзя. Приходится отыскивать
> через фильтр эту запись в другой таблице и редактировать
> там
>
> В любом случае, всем спасибо!

А зачем фильтр и тд.. FindKey/Locate не быстрее будет ? Или индексов нет (или табу на использование индексов - есть у меня такой знакомый... НИ В ОДНОЙ ИЗ ПРОГРАММ НЕ ИСПОЛЬЗУЮТСЯ ИНДЕКСЫ - у него, наверное, индексофобия..:-)... Правда они и не большие... )))

Anatoly Podgoretsky (2005-09-01 10:01:00) [18]
Sergey13 © (31.08.05 10:54) [4]
Я не знаю твоих условий, но ты, ИМХО, не туда роешь.

Известно куда - в могилу

Sergey13 (2005-09-01 09:26:00) [19]
2[8] skiph © (01.09.05 04:27)
>так что вероятность того, что 2 пользователя одновременно подадут 1 запрос практически нулевая.
Не понял я твоей уверенности.
2 узера запросили записи. Первый чуть раньше, и потому "пометил" "свою" сотню. Второй получит только вторую сотню, потому что первая уже помечена как просмотренная (но не им!!!), и соответственно пометит ее. Если продолжать дальше то 5 узеру может вообще вернуться пустой запрос.
А как и когда снимать метки "просмотренности"? Как различать метки Иванова и Петрова? Как... Короче геморой ты себе придумал, ИМХО.

Вместо этого, ИМХО, надо работать над тем, что бы давать узеру только то, что нужно, а не сотни считать.

skiph (2005-09-01 04:27:00) [20]
>Sergey13 © (31.08.05 10:54) [4]
>А если двое сразу смотрят?

Как только пользователь подает запрос на эту сотню записей, она автоматически редактируется (то бишь как раз этот запрос должен выполняться), так что вероятность того, что 2 пользователя одновременно подадут 1 запрос практически нулевая.

> Виталий Панасенко
все дело в том, что Tbl - это запрос(TQuery) с сортировкой, поэтому так просто изменить в нем нельзя. Приходится отыскивать через фильтр эту запись в другой таблице и редактировать там

В любом случае, всем спасибо!

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »