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



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

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

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

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

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

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


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

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




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

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


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

Ega23 ©   (20.05.09 12:21) [42]


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


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

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


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

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


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

Ega23 ©   (20.05.09 12:59) [45]


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


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

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

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

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

Я нашел синтаксис в стандарте SQL-99, но это не одно и тоже,


Я же не про курсоры говорил, хотя возможно и ими можно сделать в контексте

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

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

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

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

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

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

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

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

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

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

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


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

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

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

то теперь



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

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 ©   (20.05.09 13:39) [54]

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

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

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

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

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


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

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

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

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


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