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

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

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

UPDATE НА БОЛЬШОЙ ОБЪЕМ ДАННЫХ В INTERBASE [IB6.x]

Александр Николаевич © (2003-05-30 12:50:00)
Нужна помощь!
Есть следующий запрос на UPDATE.

UPDATE OS_ALLOCACCOUNT A SET A.DATE_MOVE = (SELECT D.DATE_MOVE FROM OS_DVIG D WHERE D.ID = A.IDDVIG)

Так вот выполняется БОЛЕЕ10 мин на хорошей машине.
D.ID - PRIMARY KEY
A.IDDVIG - FOREIGN KEY
OS_DVIG - record count 37 000
OS_ALLOCACCOUNT - record count 5 000
Не очень то и много.

Zacho (2003-05-31 13:34:00) [1]

> kaif © (31.05.03 05:12)
> Но пока мне не удается получить значения RDB$DB_KEY из своих
> таблиц. Сервер Yaffil ss 821. Все строки select-а возвращают
> одну и ту же закорюку, причем в каждой таблице свою

C помощью IBX или инструмента типа IBExpert и не удастся. Почему - не знаю, я и сам пока плохо понимаю, что такое RDB$DB_KEY и с чем его едят :-)
Попробуй стандартный isql.exe - будешь приятно удивлен.

kaif (2003-05-31 05:12:00) [2]
2 Zacho © (31.05.03 01:26)
совершенно потрясающая информация...
именно для задач массовых update-ов.
Но пока мне не удается получить значения RDB$DB_KEY из своих таблиц. Сервер Yaffil ss 821. Все строки select-а возвращают одну и ту же закорюку, причем в каждой таблице свою.
Но я еще поэкспериментирую. Может IBX-ы неверный тип поля используют...

Zacho (2003-05-31 01:26:00) [3]

> kaif © (31.05.03 01:16)

Про RDB$DB_KEY могу дать еще пару ссылок http://www.cvalde.com/document/mysteriousDbKey.htm
http://www.cvalde.com/document/practical_use_of_the_rdb.htm

kaif (2003-05-31 01:16:00) [4]
2 Zacho © (30.05.03 17:13)

Спасибо за ссылку. Очень ценная и компактная статья. Правда там мой вариант приведен (изменение update и select местами). Но я впервые узнал о возможности обращения as cursor. И вообще не знал про поле RDB$DB_KEY. Хотя я пока в сомнении насчет версионного механизма и контекста транзакции. Будет ли это всегда работать (RDB$DB_KEY)?

Zacho (2003-05-30 17:13:00) [5]

> kaif © (30.05.03 17:00)

На http://www.ibase.ru/devinfo/updsame.htmесть парочка более быстрых вариантов :-)

kaif (2003-05-30 17:00:00) [6]
Сама конструкция запроса медленная.
Она проходит 5000 записей в одной таблице и для того, чтобы заменить значение каждый раз вызывает SELECT к таблице, в которой 37000 записей.
Надеюсь, что хотя бы, что поле ID это просто PRIMARY KEY и поиск идет по индексу.
Предлагаю сделать иначе.
Нужно сделать хранимую процедуру, вней конструкцию FOR с объединением таблиц и UPDATE 1 записи внутри цикла.

create procedure quick_update
as
declare variable tmp_id integer;//это уточните
declare variable tmp date;
begin
for select A.ID, D.DATE_MOVE
from OS_ALLOCACCOUNT A, OS_DVIG D
where WHERE D.ID = A.IDDVIG
into :tmp_id, :tmp _date
do
UPDATE OS_ALLOCACCOUNT
SET DATE_MOVE = :tmp_date
WHERE ID = :tmp_id;
end

Здесь использован первичный ключ таблицы OS_ALLOCACCOUNT - условно ID. В вашем запросе он не используется, поэтому я его вынужден был додумать.
Но идея, я думаю, Вам ясна.

Остнется лишь запустить потом процедуру

execute procedure quick_update;

Я думаю, что это должно сработать секунд за 5 - 10.

Александр Николаевич (2003-05-30 13:11:00) [7]
>stone
В том то и дело, что нет

stone (2003-05-30 13:09:00) [8]
А интербэйз такие кострукции поддерживает?

UPDATE OS_ALLOCACCOUNT
SET DATE_MOVE = D.DATE_MOVE FROM OS_DVIG D INNER JOIN OS_ALLOCACCOUNT A ON D.ID = A.IDDVIG

Zacho (2003-05-30 13:06:00) [9]

> Александр Николаевич (30.05.03 13:04)

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

Zacho (2003-05-30 13:04:00) [10]

> Александр Николаевич (30.05.03 12:58)

Imho, если это единичная операция, то можно и 10 мин. подождать, а если подобное требуется постоянно, то ХП типа описанных в http://www.ibase.ru/devinfo/updsame.htm- самое то.

Александр Николаевич (2003-05-30 13:04:00) [11]
Привязываешся к конкретной СУБД. При переходе на другое СУБД(SQL, ORACLE) придется много чего перелопачивать

Ann (2003-05-30 13:03:00) [12]
я тоже считаю, что ХП лучше использовать да и отработает быстрее..

Соловьев (2003-05-30 13:01:00) [13]

> А без ХП никак???

а что в них плохого?

Александр Николаевич (2003-05-30 12:58:00) [14]
А без ХП никак???
А использование Yafill or Firebird никак не помогет? В Yafill можно ведь строить планы на UPDATE

Соловьев (2003-05-30 12:54:00) [15]
а ХП не пробовал?

Zacho (2003-05-30 12:54:00) [16]
Смотри http://www.ibase.ru/devinfo/updsame.htm

Александр Николаевич (2003-05-30 12:52:00) [17]
Sorry!
Вопрос то забыл написать! Как оптимизировать скорость?????

Наверх

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