Мастера 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 написать. Поможите кто добрый, плз.

Ega23 (2009-05-20 14:40:00) [21]

> хотя я там пробовал искать, но видимо не там.

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

Anatoly Podgoretsky (2009-05-20 14:29:00) [22]
> Игорь Шевченко (20.05.2009 13:41:55) [55]

Да просто под рукой 99 и выше оказались. Кроме того и T-SQL тоже обнаружился, хотя я там пробовал искать, но видимо не там.

Ega23 (2009-05-20 13:53:00) [23]

> или код на паскале, где идентификаторы содержат в себе подчеркивание

Я так только константы именую. с_[аббривиатура категории]_[мнемоническое имя]

Игорь Шевченко (2009-05-20 13:48:00) [24]
Ega23 © (20.05.09 13:39) [54]

Э...Я довольно долго писал запросы под Oracle и под Interbase, а также под разную для меня экзотику - как ни странно, ни разу не было желания писать что-то единое для всех. Обычному SELECT-у пофиг, а всякие частности - они все одно у каждого свои и запросы писались так, чтобы они были похожи на принятые для этой СУБД привычные формы.

К примеру, NVL и DECODE в Oracle не во всех версиях можно заменить CASE, хотя бы потому, что CASE не во всех версиях включен в синтаксис :)

А что касается твоего примера с JavaScript - я, опять же, довольно долго служил ямщиком на почте, то есть, писал на C, паскале и C#
Как только я вижу код на С, в котором идентификаторы написаны с большой буквы или код на паскале, где идентификаторы содержат в себе подчеркивание (this_is_ident), моя рука тянется к пистолету, так как существуют неписанные традиции для языка, и знание этих традиций облегчает понимание кода.

Кстати, за что я никогда не любил Borland C++ builder - он смешивает традиции.

Игорь Шевченко (2009-05-20 13:41:00) [25]
Anatoly Podgoretsky © (20.05.09 13:20) [48]

> Я нашел синтаксис в стандарте SQL-99, но это не одно и тоже,
>
> where current of <cursor>
> Я же не про курсоры говорил, хотя возможно и ими можно сделать
> в контексте

Я наверное тебя запутал в начале :) Синтаксис WHERE CURRENT OF конечно же подразумевает WHERE CURRENT OF <cursor>, собственно с этой конструкцией я познакомился еще в WATCOM SQL, когда он не был продан Sybase, и в описании тамошнего синтаксиса было написано, что конструкция соответствует стандарту ANSI SQL. А это было до 1999-года :)

В SQL-92 этот синтаксис имеется

Ega23 (2009-05-20 13:39:00) [26]
Я вот что скажу. Довольно долго сидел под MSSQL и нифига кроме TSQL ничего не знал. И тут потребовалось под Postgres писать. Скажу честно - я сам не заметил, как у меня поменялся стиль написания запросов. Потому что, когда сразу с несколькими СУБД приходится работать - в одной что-то подзабылось, в другой - тоже фигня какая-то своя. А так - более-менее унифицировано получается.

Тоже самое произошло, когда на JavaScript начал писать. Сам не заметил, как все локальные переменные в любом языке начал с LowerCase писать. Если раньше
var i, CurrID : Integerто теперь
var i, currID : Integer

Собственно, речь об этом, а не о том, что "необходимо стандарта придерживаться"

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

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

полная ерунда

ANB (2009-05-20 13:28:00) [28]

> ну ты же отказываешься от дополнительных возможностей явных
> джойнов пользу привычных тебе методов объединений

Никто от них не отказывается. Когда нужны эти доп. возможности - пользуемся явными джойнами. Только это так редко нужно . . .

Anatoly Podgoretsky (2009-05-20 13:24:00) [29]

> Нафиг не нужна унифицированность синтаксиса. Каждая СУБД
> (и каждый язык программирования, кстати), предоставляют
> свои уникальные возможности, и не использовать их было бы
> глупо. К примеру, в том же Oracle есть масса встроенных
> функций и конструкций SQL, которые уникальны для Oracle,
> но позволяют решать задачи оптимальным образом.
> И что, от них отказываться в пользу унифицированности ?

Полностью согласен.

ANB (2009-05-20 13:23:00) [30]

> А не только тому, кто знает Oracle.

А тому, кто не знает, оно, как правило, и не надо.

И у плюсов есть свое достоинство - на 8-ке работают только они. А 8-ку снесли еще далеко не все.

sniknik (2009-05-20 13:21:00) [31]
> И что, от них отказываться в пользу унифицированности ?
ну ты же отказываешься от дополнительных возможностей явных джойнов пользу привычных тебе методов объединений, ради привычки, почему бы не отказаться и в этом случае ради "великой идеи"?
(хотя я то как раз не предлагал ни от чего отказываться, но раз уж зашел разговор...)

> мало писать понятные запросы
вообще то понятные запросы, если они по стандарту, в общем случае лучше "перевариваются" оптимизатором и планировщиком, и как правило чаще всего быстрее запутанных.
хотя, оракл в число близко знакомых мне баз не входит, допускаю что там может быть по другому. (написан толпой индусов без четкой "линии партии" ;), может наиболее отлаженные как раз старые алгоритмы.)

Anatoly Podgoretsky (2009-05-20 13:20:00) [32]

> > Может быть и так, но это синтаксис Оракла и я не уверен
>
> > на присутствие в стандарте
>
>
> Вообще-то это синтаксис SQL-92

Я нашел синтаксис в стандарте SQL-99, но это не одно и тоже,
where current of <cursor>
Я же не про курсоры говорил, хотя возможно и ими можно сделать в контексте

> где количество источников столько сколько нужно и нет ограничения
> на тип и без вложеных запросов.

Игорь Шевченко (2009-05-20 13:07:00) [33]
Ega23 © (20.05.09 12:59) [45]

> Но если (+) и Outer join абсолютно равнозначны по скорости
> выполнения запроса, то ЛИЧНО Я бы написал outer join, т.
> к. это будет более понятно ЛЮБОМУ человеку. А не только
> тому, кто знает Oracle.

Лично для тебя - синтаксис OUTER JOIN в Oracle появился гораздо позже (+).
Собственно почему я и пишу про ЛИЧНО СВОЮ разницу в восприятии.

Лично для тебя - по скорости не различается, в плане исполнения запроса и в том и в другом случае будет стоять JOIN OUTER.

Мы не ставим целью писать запросы, понятные человекам, знакомым с другими СУБД - что толку писать часть запроса стандартно, а далее, в том же запросе использовать кучу Оракловских фич - запрос от этого понятнее человеку, незнакомому с Oracle, не станет.

Ega23 (2009-05-20 13:02:00) [34]

> Ega23 © (20.05.09 12:59) [45]

Вдогонку.
Собственно, с чего всё началось. Да, в MSSQL есть UPDATE ... WHERE CURRENT OF. Но поскольку реализовано это дело через курсор, а они в MSSQL - штука довольно тяжёлая - проще Update..From использовать.

Ega23 (2009-05-20 12:59:00) [35]

> Для Оракла выполнение одинаково написанного запроса может
> отличаться от выполнения его же на MS-SQL, Sybase, Informix,
> DB2, далее со всеми остановками до станции Можайск Смоленского
> направления.

Блин. Игорь, пойми, я не агитирую за то, чтобы все всегда писали по стандарту. Естественно, в конкретной СУБД есть свои фичи. И не пользоваться ими - просто глупо, а зачастую и "преступно".
Но если (+) и Outer join абсолютно равнозначны по скорости выполнения запроса, то ЛИЧНО Ябы написал outer join, т.к. это будет более понятно ЛЮБОМУ человеку. А не только тому, кто знает Oracle.

Игорь Шевченко (2009-05-20 12:55:00) [36]
Ega23 © (20.05.09 12:21) [42]

> Но, по-идее, правильнее - третий вариант. Он будет понятен
> вообще любому, кто с зачатками ANSI SQL знаком.

Понимаешь, в чем дело - мы MS-SQL-щиков, например, на работу не берем. Мы берем тех, кто знает Оракл. Причина простая - мало писать понятные запросы, надо еще знать различия в их выполнении на разных СУБД. Для Оракла выполнение одинаково написанного запроса может отличаться от выполнения его же на MS-SQL, Sybase, Informix, DB2, далее со всеми остановками до станции Можайск Смоленского направления.
А нам важно, чтобы народ писал запросы с учетом особенностей Oracle, а не с учетом стандартов ANSI

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

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

Нафиг не нужна унифицированность синтаксиса. Каждая СУБД (и каждый язык программирования, кстати), предоставляют свои уникальные возможности, и не использовать их было бы глупо. К примеру, в том же Oracle есть масса встроенных функций и конструкций SQL, которые уникальны для Oracle, но позволяют решать задачи оптимальным образом.
И что, от них отказываться в пользу унифицированности ?
Нафиг надо

Ega23 (2009-05-20 12:21:00) [38]

> Ну и что, что не везде. Один хрен, попытка писать запросы
> так, чтобы выполнялись на всех СУБД - полностью бестолковая
> затея.
> Зато с (+) на оракле и читать удобнее и писать меньше.

А я не говорю, что нужно писать так, чтобы на любой СУБД выполнилось. Вот уж действительно бестолковая затея.
Но. Когда я вижу Outer Join - я понимаю, о чём идёт речь. Причём понимаю вне зависимости от диалекта. А вот с (+) или ещё с какой-нибудь фигнёй - уже надо лезть в доку по конкретному диалекту и смотреть - а что же это такое?

Для T-SQL данные конструкции равнозначны и равновозможны:

Select Name=CatName from Categories Select CatName Name from Categories Select CatName as Name from Categories

Но, по-идее, правильнее - третий вариант. Он будет понятен вообще любому, кто с зачатками ANSI SQL знаком.

sniknik (2009-05-20 12:11:00) [39]
> Один хрен, попытка писать запросы так, чтобы выполнялись на всех СУБД - полностью бестолковая затея.
смысл не в том чтобы везде выполнялось одно и тоже, а в унифицированности синтаксиса... т.е. где бы то ни было начинаешь писать по стандарту, и если не заработало сразу, то мелкие изменения делаются прямо на месте по "наводке" ошибок от компилятора.

и кстати вопрос к поборникам (+) (не к Игорю, он признает, что пишет так по привычке) вы писали долгое время используя только join? (чтобы привычка была ~ одинакова)
я просто писал и так и так, на первасвиле, когда у него явных джойнов не было, года полтора, потом пришлось на accecc... и было поначалу очень непривычно, но варианта с альтернативой попросту не было... привык. а когда поработал с полгода так и понял что явные удобнее, именно по читабельности, т.к. запрос структурирован, объединения отдельно, условия отдельно, а + в большой массе условий может попросту потеряться.
не говоря уже о том, что у явных возможностей больше (естественно, новое развивается, старое застаивается).

> Всегда считал C понятнее паскаля.
что же ты тогда тут делаешь?

ANB (2009-05-20 12:00:00) [40]

> Зато с (+) на оракле ичитать удобнее иписать меньше.

> и C на порядок понятнее дельфей (ну как же вместо begin
> (6) пишут { (1), и т.д.).

Всегда считал C понятнее паскаля.

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

Наверх

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