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

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

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

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

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

← →
sniknik © (2009-05-20 12:11) [41]

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

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

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

← →
Ega23 © (2009-05-20 12:21) [42]

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

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

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

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

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

← →
Игорь Шевченко © (2009-05-20 12:51) [43]

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

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

← →
Игорь Шевченко © (2009-05-20 12:55) [44]

Ega23 © (20.05.09 12:21) [42]

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

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

← →
Ega23 © (2009-05-20 12:59) [45]

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

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

← →
Ega23 © (2009-05-20 13:02) [46]

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

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

← →
Игорь Шевченко © (2009-05-20 13:07) [47]

Ega23 © (20.05.09 12:59) [45]

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

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

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

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

← →
Anatoly Podgoretsky © (2009-05-20 13:20) [48]

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

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

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

← →
sniknik © (2009-05-20 13:21) [49]

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

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

← →
ANB (2009-05-20 13:23) [50]

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

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

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

← →
Anatoly Podgoretsky © (2009-05-20 13:24) [51]

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

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

← →
ANB (2009-05-20 13:28) [52]

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

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

← →
Игорь Шевченко © (2009-05-20 13:36) [53]

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

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

← →
Ega23 © (2009-05-20 13:39) [54]

Я вот что скажу. Довольно долго сидел под MSSQL и нифига кроме TSQL ничего не знал. И тут потребовалось под Postgres писать. Скажу честно - я сам не заметил, как у меня поменялся стиль написания запросов. Потому что, когда сразу с несколькими СУБД приходится работать - в одной что-то подзабылось, в другой - тоже фигня какая-то своя. А так - более-менее унифицировано получается.

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

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

← →
Игорь Шевченко © (2009-05-20 13:41) [55]

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 этот синтаксис имеется

← →
Игорь Шевченко © (2009-05-20 13:48) [56]

Ega23 © (20.05.09 13:39) [54]

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

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

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

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

← →
Ega23 © (2009-05-20 13:53) [57]

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

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

← →
Anatoly Podgoretsky © (2009-05-20 14:29) [58]

> Игорь Шевченко (20.05.2009 13:41:55) [55]

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

← →
Ega23 © (2009-05-20 14:40) [59]

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

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

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

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

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

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

CURSOR foobar IS SELECT foo FROM bar;

OPEN foobar;
FETCH foobar INTO foobardata;
...

?

← →
sniknik © (2009-05-20 16:10) [61]

> Ты хочешь сказать, что сформировать result set быстрее, чем двигаться по нему ?
смотря для чего, если выбрать одну запись где то ближе к началу то курсором быстрее (если есть индекс то может и нет), если цель в обработке всех то вариант пакетной команды очевидно будет быстрее чем перебор и обработка тех же самых записей по одной в курсоре.

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

← →
Игорь Шевченко © (2009-05-20 16:32) [62]

sniknik © (20.05.09 16:10) [61]

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

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

← →
ANB (2009-05-20 16:33) [63]

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

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

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

← →
Anatoly Podgoretsky © (2009-05-20 16:34) [64]

> Ega23 (20.05.2009 14:40:59) [59]

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

← →
ANB (2009-05-20 16:35) [65]

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

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

← →
Игорь Шевченко © (2009-05-20 16:54) [66]

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

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

← →
sniknik © (2009-05-20 16:58) [67]

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

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

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

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

> триггеры на SELECT ?
на update/insert

sniknik © (20.05.09 17:12) [69]

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

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

> В update/insert нет курсоров - не с чем сравнивать.
как же не с чем? а синтаксис с CURRENT OF, т.е. то с чего начали.

sniknik © (20.05.09 17:29) [71]

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

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

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

> Юрий Зотов © (18.05.09 17:15) [13]
> Люди, вы гиганты. Спасибо.

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

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

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

> ну и что?

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

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

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

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

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

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

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

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

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

Update одной таблицы по условию из другой таблицы Найти похожие ветки