Почему SQL ANSI-92 не является стандартным лучше принятый по ANSI-89?

Oracle не реализует ANSI-92 вообще хорошо. У меня было несколько проблем, не в последнюю очередь потому что таблицы данных в Приложениях Oracle так очень хорошо обеспечены столбцами. Если число столбцов в Ваших соединениях превысит приблизительно 1 050 столбцов (который очень легко сделать в Приложениях), то Вы получите эту побочную ошибку, которая не имеет абсолютно никакого логического смысла:

ORA-01445: cannot select ROWID from a join view without a key-preserved table.

Перезапись запроса для использования старого синтаксиса соединения стиля заставляет проблему исчезнуть, который, кажется, обвиняет вины прямо при реализации соединений ANSI-92.

, Пока я не встретился с этой проблемой, я был устойчивым покровителем ASNI-92 из-за преимуществ в сокращении шанса случайного перекрестного объединения, которое слишком легко сделать с синтаксисом старого стиля.

Теперь, однако, я нахожу намного более трудным настоять на нем. Они указывают на плохую реализацию Oracle и говорят, что "Мы сделаем это наш путь, спасибо".

Я не могу говорить за все школы, но в моем университете, когда мы делали модуль SQL нашего курса, они не преподавали ANSI-92, они преподавали ANSI-89 - старой системе VAX в этом! Я не был представлен ANSI-92, пока я не начал рыть вокруг в Доступе, создававшем некоторые запросы с помощью разработчика запроса и затем роя в код SQL. При понимании я понятия не имел, как это завершало соединения или последствия синтаксиса, который я начал рыть глубже, таким образом, я мог понять его.

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

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

Странно, мне кажется, что много программистов выходит из школы и прекращает совершенствоваться; думание, что, потому что это - то, что им преподавали, это - то, как это сделано. Это - только когда Вы снимаете свои проблесковые огни, Вы понимаете, что школа была только предназначена, чтобы преподавать Вам основы и дать Вам достаточно понимания для изучения остальных самим и что действительно Вы едва поцарапали поверхность того, что там должен знать; теперь это - Ваше задание для продолжения того пути.

, Конечно, это - просто мое мнение на основе моего опыта.

Я могу ответить с точки зрения среднего разработчика, зная, что как раз достаточно SQL понимает оба синтаксиса, но все еще гугля точный синтаксис вставки каждый раз мне нужен он...:-P (я весь день не делаю SQL, просто решая некоторые проблемы время от времени.)

ну, на самом деле, я нахожу первую форму более интуитивной, не делая очевидной иерархии между этими двумя таблицами. Факт, который я изучил SQL с возможно старыми книгами, показав первой форме, вероятно, не помогает...;-)
И первая ссылка я нахожу на выбор sql поиск в Google (который дает главным образом французские ответы для меня...), первые шоу более старая форма (тогда объясняют вторую).

Просто предоставление некоторых подсказок на, "почему" вопрос... ^_^ я должен прочитать хорошую, современную книгу (агностик DB) по теме. Если у кого-то есть предложения...

Я не знаю ответ наверняка.. это - religous война (альбит меньшего градуса, чем ПК Mac или другие)

, предположение А - то, что до справедливо недавно, Oracle, (и возможно другие поставщики также) не приняла стандарт ANSI-92 (я думаю, что это было в Oracle v9, или поблизости), и так, для Разработчиков DBAs/Db, работающих в компаниях, которые все еще использовали эти версии, (или хотел, чтобы код был портативным через серверы, которые могли бы использовать эти версии, они должны были придерживаться старого стандарта...

Это - позор действительно, потому что новый синтаксис соединения намного более читаем, и старый синтаксис генерирует неправильно (неправильные) результаты в нескольких хорошо зарегистрированных сценариях.

• А именно, внешние объединения, когда существуют условные предикаты фильтрации на связанных с несоединением столбцах от таблицы на "внешней" стороне соединения.

Сначала позвольте мне сказать, что в SQL Server синтаксис внешнего объединения (* =) не дает корректные результаты все время. Существуют времена, когда это интерпретирует это как перекрестное объединение и не внешнее объединение. Так тут же серьезное основание прекратить использовать его. И тот синтаксис внешнего объединения является устаревшей функцией и не будет в следующей версии SQL Server после SQL Server 2008. Вы все еще будете в состоянии сделать внутренние объединения, но с какой стати кто-либо хотел бы? Они неясны и намного намного более тверды поддержать. Вы легко не знаете то, что является частью соединения и что действительно просто где пункт.

Одна причина, почему я верю Вам, не должна использовать старый синтаксис, то, что понимание соединений и что они делают и не делать, является критическим шагом для любого, кто запишет код SQL. Вы не должны писать код SQL, не понимая соединения полностью. Если Вы поймете их хорошо, Вы, вероятно, придете к выводу, что синтаксис ANSI-92 более ясен и легче поддержать. Я никогда не встречал эксперта по SQL, который не использовал синтаксис ANSI-92 в предпочтении к старому синтаксису.

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

Несколько причин приходят на ум:

• люди делают это из привычки
• , люди ленивы и предпочитают "старый стиль" соединения, потому что они включают меньше ввода
• , у новичков часто есть свои проблемы при обертывании их голов вокруг синтаксиса соединения SQL-92
• , люди не переключаются на новый синтаксис просто, потому что это там
• , люди не знают о преимуществах новое (если Вы хотите назвать его, что) синтаксис имеет, прежде всего, что это позволяет Вам отфильтровать таблицу прежде , Вы делаете внешнее объединение, и не после него, когда все, что Вы имеете, является оператором Where.

С моей стороны, я делаю все свои соединения в синтаксисе SQL-92, и я преобразовываю код, где я могу. Это - инструмент для очистки, больше читаемого и мощного способа сделать это. Но трудно убедить кого-то использовать новый стиль, когда они думают, что это повреждает их с точки зрения большего количества работы ввода, не изменяя результат запроса.

Хорошо стандарт ANSI092 включает некоторый довольно отвратительный синтаксис. Естественные Соединения один, и ИСПОЛЬЗОВАНИЕ Пункта является другим. По моему скромному мнению, дополнение столбца к таблице не должно повреждать код, но ЕСТЕСТВЕННОЕ СОЕДИНЕНИЕ прерывает самый вопиющий вид. "Лучший" способ повредиться ошибкой компиляции. Например, если Вы ВЫБИРАЕТЕ * где-нибудь, дополнение столбца могло сбой для компиляции. Следующим лучшим способом перестать работать была бы ошибка периода выполнения. Это хуже, потому что Ваши пользователи могут видеть его, но это все еще дает Вам хорошее предупреждение, что Вы повредили что-то. При использовании ANSI92 и запросов записи с ЕСТЕСТВЕННЫМИ соединениями он не повредится во время компиляции, и он не повредится во время выполнения, запрос просто внезапно начнет приводить к неправильным результатам. Эти типы ошибок коварны. Отчеты идут не так, как надо, потенциально раскрытие финансовой информации являются неправильными.

Для незнакомых с ЕСТЕСТВЕННЫМИ Соединениями. Они присоединяются к двум таблицам на каждом имени столбца, которое существует в обеих таблицах. Который действительно прохладен, когда у Вас есть ключ на 4 столбца, и Вы устаете вводить его. Проблема входит, когда Table1 имеет существующий ранее столбец под названием ОПИСАНИЕ, и Вы добавляете новый столбец к названному Table2, о, я не знаю, что-то безвредное как, mmm, ОПИСАНИЕ, и теперь Вы присоединяетесь к этим двум таблицам на поле VARCHAR2(1000), которое является свободной формой.

ИСПОЛЬЗОВАНИЕ пункта может привести к общей неоднозначности в дополнение к проблеме, описанной выше. В другом ТАК сообщение , кто-то показал этот ANSI-92 SQL и обратился за помощью к чтению его.

SELECT c.* 
FROM companies AS c 
JOIN users AS u USING(companyid) 
JOIN jobs AS j USING(userid) 
JOIN useraccounts AS us USING(userid) 
WHERE j.jobid = 123

Это абсолютно неоднозначно. Я поместил столбец UserID в обе Компании и пользовательские таблицы и нет никакой жалобы. Что, если столбец UserID в компаниях является идентификатором последнего человека, который изменит ту строку?

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

я думаю, что счет корректен, что существует большая база разработчика кто скопировать/вставить там путь посредством кодирования. На самом деле я могу признать, что я - вид одного когда дело доходит до ANSI-92. Каждый пример, который я когда-либо видел, показал несколько соединений, вкладываемых в круглых скобках. Честность, которая делает выбирание таблиц в sql трудном в лучшем случае Но тогда SQL92 evangilist объяснил, что это на самом деле вызовет порядок соединения. ИИСУС... все те пасторы Копии, которых я видел, теперь на самом деле вызывают порядок соединения - задание, это составляет 95% времени, лучше оставленный оптимизаторам особенно copy/paster.

Tomalak разобрался в нем, когда он сказал,

, люди не переключаются на новый синтаксис просто, потому что это там

, Это должно дать мне что-то, и я не вижу позитивный аспект. И если существует позитивный аспект, отрицательные стороны альбатрос, слишком большой, чтобы быть проигнорированным.

Инерция и практичность.

ANSI-92 SQL похож на печатание слепым методом. Некоторым теоретическим способом это могло бы сделать все лучше когда-нибудь, но я могу ввести намного более быстрое рассмотрение ключей с четырьмя пальцами теперь. Я должен был бы пойти назад для движения вперед без гарантии, что когда-либо будет выплата.

SQL Записи составляет приблизительно 10% моего задания. Если мне будет нужен ANSI-92 SQL для решения проблемы, которую ANSI-89 SQL не может решить тогда, то я буду использовать его. (Я использую его в Доступе на самом деле.) При использовании всего этого время помогло бы мне решить свои существующие проблемы намного быстрее, я провел бы время для ассимиляции его. Но я могу выкрикнуть ANSI-89 SQL, никогда не думая о синтаксисе. Мне платят для решения проблем - думающий о синтаксисе SQL, пустая трата моего времени и денег моего работодателя.

Когда-нибудь, молодой Кузнечик, Вы будете защищать свое использование синтаксиса SQL ANSI-92 против молодых людей, жалующихся это, необходимо использовать SQL3 (или безотносительно). И затем Вы поймете.:-)

In response to the NATURAL JOIN and USING post above.

WHY would you ever see the need to use these - they weren't available in ANSI-89 and were added for ANSI-92 as what I can only see as a shortcut.

I would never leave a join to chance and would always specify the table/alias and id.

For me, the only way to go is ANSI-92. It is more verbose and the syntax isn't liked by ANSI-89 followers but it neatly separates your JOINS from your FILTERING.