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

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

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

Update одной таблицы по условию из другой таблицы [DB2]

Страницы: 1 2 3 4 >
Юрий Зотов © (2009-05-18 15:25:00)
Люди, что-то не соображу как сделать следующее

Есть таблица T1 с полями K11 (int), K12 (int), F1 (char) и таблица T2 с полями K21 (int), K22 (int), F2 (char). Поля K11 и K12 есть составной ключ некоего документа, такой же ключ составляют поля K21 и K22.

Требуется проапдейтить поле F1 в записях таблицы T1, удовлетворяющих условию:

T1.K11 = T2.K21
and
T1.K12 = T2.K22
and
T2.F2 = 'НЕЧТО'

И в силу недостаточного знания SQL не могу сообразить, как этот update написать. Поможите кто добрый, плз.

sniknik (2009-05-20 19:53:00) [1]
> быстрее, чем что?
читать не умеешь? или выборочно, раньше фразы ничего не воспринимается?
быстрее пакетных команд, типа проход курсором для апдейта быстрее чем апдейт с from, или составление рекордсета по курсору быстрее чем селект.
ну так получается, судя по тому что мне тут говорят. и не верить нельзя, т.к. говорят, что так в оракле который я не знаю.

Petr V. Abramov (2009-05-20 19:08:00) [2]

> sniknik © (20.05.09 16:58) [67]

> а в оракле значит в хелпе обманывают, что они быстрее? очень
> плохо.

быстрее, чем что?

Игорь Шевченко (2009-05-20 19:05:00) [3]

> возвращает выборку, т.е. рекордсет, куда, сервер/клиент
> неважно. если же это просто запись из которой другие команды
> берут условия для собственной работы, а она сама ничего
> не делает, то это не настоящий селект.

Я полагаю, есть смысл прекратить дискуссию

sniknik (2009-05-20 18:59:00) [4]
> критерии "настоящего" SELECT в студию
возвращает выборку, т.е. рекордсет, куда, сервер/клиент неважно. если же это просто запись из которой другие команды берут условия для собственной работы, а она сама ничего не делает, то это не настоящий селект.

> А о чем вообще дискуссия ?
не знаю. ты спрашиваешь/комментируешь, я отвечаю.

Alarm (2009-05-20 18:49:00) [5]
> Юрий Зотов © (18.05.09 17:15) [13]
> Люди, вы гиганты. Спасибо.

Хотя бы только из-за этого, я бы уже прекратил постить в эту ветку
:(

Игорь Шевченко (2009-05-20 18:49:00) [6]

> селект в описании курсора это не настоящий селект...

критерии "настоящего" SELECT в студию

> ну и что?

А о чем вообще дискуссия ?

sniknik (2009-05-20 18:30:00) [7]
> Там еще и SELECT участвует
селект в описании курсора это не настоящий селект... это всего лишь условие по которому выбираются записи. ну да, условие имеет вид селекта ну и что?

Игорь Шевченко (2009-05-20 18:21:00) [8]
sniknik © (20.05.09 17:29) [71]

> как же не с чем? а синтаксис с CURRENT OF, т.е. то с чего
> начали.

А почитать синтаксис не ? :) Там еще и SELECT участвует

sniknik (2009-05-20 17:29:00) [9]
> В update/insert нет курсоров - не с чем сравнивать.
как же не с чем? а синтаксис с CURRENT OF, т.е. то с чего начали.

Игорь Шевченко (2009-05-20 17:17:00) [10]
sniknik © (20.05.09 17:12) [69]

В update/insert нет курсоров - не с чем сравнивать.

А насчет срабатывания триггеров - в чудесном оракле есть возможность указать метод срабатывания триггеров - на каждую строку или на весь оператор

sniknik (2009-05-20 17:12:00) [11]
> триггеры на SELECT ?
на update/insert

Игорь Шевченко (2009-05-20 17:08:00) [12]

> т.к. если бы было подобие курсора то тригеры бы срабатывали
> на одну запись, а они работают там "на пакет".

триггеры на SELECT ?

sniknik (2009-05-20 16:58:00) [13]
> Любая СУБД, насколько мне известно, отдает полученные в result set записи той или иной формой курсора (явного, неявного - без разницы).
в mssql очевидно не так... т.к. если бы было подобие курсора то тригеры бы срабатывали на одну запись, а они работают там "на пакет".

> что в BOL прямо было прописано - по возможности ими не пользоваться.
а в оракле значит в хелпе обманывают, что они быстрее? очень плохо.

Игорь Шевченко (2009-05-20 16:54:00) [14]

> Массовые апдейты я вообще иногда инсертами делаю.

Дурное дело нехитрое

ANB (2009-05-20 16:35:00) [15]

> Если в MS SQL иначе

В ms sql курсоры мало того, что дебильные по синтаксису, так еще и настолько тормозные, что в BOL прямо было прописано - по возможности ими не пользоваться.

Anatoly Podgoretsky (2009-05-20 16:34:00) [16]
> Ega23 (20.05.2009 14:40:59) [59]

Да зачем мне курсоры, при наличии механизма FROM

ANB (2009-05-20 16:33:00) [17]

> Это как ? Ты хочешь сказать, что сформировать result set
> быстрее, чем двигаться по нему ?

Ну это даже в оракле быстрее.

Массовые апдейты я вообще иногда инсертами делаю.

Игорь Шевченко (2009-05-20 16:32:00) [18]
sniknik © (20.05.09 16:10) [61]

В чудесном оракле для получения result set можно указать, что нужно сделать быстрее - получить первую запись или получить все записи.
Как двигаться по вперед по result set после его получения - без разницы, скорость будет одинаковая. Любая СУБД, насколько мне известно, отдает полученные в result set записи той или иной формой курсора (явного, неявного - без разницы).

Если в MS SQL иначе - то вот вам еще одно различие между базами, непреодолимое способом записи SQL, по стандарту ANSI или по стандарту СУБД

sniknik (2009-05-20 16:10:00) [19]
> Ты хочешь сказать, что сформировать result set быстрее, чем двигаться по нему ?
смотря для чего, если выбрать одну запись где то ближе к началу то курсором быстрее (если есть индекс то может и нет), если цель в обработке всех то вариант пакетной команды очевидно будет быстрее чем перебор и обработка тех же самых записей по одной в курсоре.

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

Игорь Шевченко (2009-05-20 15:41:00) [20]

> Курсоры в TSQL медленные.

Это как ? Ты хочешь сказать, что сформировать result set быстрее, чем двигаться по нему ?

То есть,
SELECT foo FROM bar
будет быстрее, чем

CURSOR foobar IS SELECT foo FROM bar;

OPEN foobar;
FETCH foobar INTO foobardata;
...

?

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

Наверх

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