pkarklinВитеевато, получатеся, неправдали?! Ваша "школа"! :)
Хм. Мой педагогический талант, видимо, черезчур силен. Надеюсь только, что не он послужил причиной пяти грамматических ошибок ;)
pkarklinХм. Если один движок запрещает логичную и имеющую смысл операцию, которая в другом движке делалась в "одном" месте, но разрешает сделать ее в "другом" месте не менее логично - я не считаю это недостатком реализации.
Реализации чего именно? Возможности сделать outer join как таковой - безусловно. И если бы этого "одного" места не было, и все делалось бы в "другом" - никаких вопросов.
Мы, если помните, сравнивали не движки, но "места"; возможность сделать операцию "в одном месте" и "в другом месте", искали объективную разницу между местами безотносительно сервера. Объективной разницы не нашли, но нашли невозможность сделать "нечто" в "этом" месте "этого" сервера. Это - не объективная разница, это недостаток реализации "этого места в этом сервере".
pkarklinДа даже и не думал. :) Просто меня все больше поражает тот факт, что конкретные детали реализации конкретного движка преподносятся как "недостатки" реализации только по тому, что в другом движке эти конкретные детали реализованы по другому.
Если говорить о поражениях, я перманентно поражаюсь способности прискорбно многих MSSQL-евцев воспринимать любую мелочь как глобальную атаку. Например, если Вы при случае скажете, что поведение функции LENGTH в Oracle:
1.
2.
3.
4.
SQL> select length ('') from dual;
LENGTH('')
----------
<null>
- неудобно и недостаток реализации, я просто соглашусь с Вами. С моей точки зрения было бы много удачнее возвращать в этом случае ноль. Безусловно, есть "другие способы", позволяющие получить этот ноль - но я почему-то не начну напирать на это, возмущаясь неоправданным наездом на Oracle. И меня поражает столь активная реакция по подобному поводу.
Боюсь, я не смог решить, как именно трактовать Вашу формулировку, поэтому дам два ответа, рассчитанных на разные варианты трактовки.
1. Я думаю о Вас хорошо, и полагаю, что под "конкретными деталями реализации" понимаются звездочки-плюсики, а под "по-другому" - поддержка либо неподдержка возможности связей типа показанных мной.
В этом случае - преподносятся как "недостатки реализации конкретной детали в конкретном движке", с учетом того, что не "по-другому", но "обгрызенно, неполно, причем там, где нет очевидных причин так ограничивать".
Если угодно - реализация через * хромает по сравнению с реализацией через join.
2. Я допускаю, что Вы имели в виду "по-другому" как сопоставление (+) в Oracle с join в MS SQL.
В этом случае ограничусь констатацией факта, что это крайне искаженная интерпретация сказанного мной.
pkarklinЯ бы согласился с Вам, но только в том случаи, если бы ограничения объединений в "старом стиле" не покрывались бы возможностями объединений во "новом стиле". Отсюда и мои заявления "не вижу недостатков".
Не видите недостатков объединения в старом стиле?
Повторюсь, меня поражает способность воспринимать любую мелочь как глобальный наезд.
pkarklinВы же называете "недостатком реализации" рудимент конкретного движка, которым мало кто пользуется и который в следующих версиях и поддерживаться не будет, при этом не обращая внимание на "возможности" объединений в "новом стиле".
Если коротко, то Вы врете.
Мы, если вспомните, сравниваем "рудимент", с "возможностями объединений в новом стиле", причем не в контексте MS SQL, но глобально. Как при этом я утитряюсь (если верить Вашим словам) не обращать внимания на второе - загадка.
Если бы Вы сразу сказали "в MS это криво реализованный рудимент и такое сравнение не имеет смысла" - повторюсь, не было бы никаких вопросов. Если Вы начали выдвигать глобальные утверждения ("не представляю, как реализовать"), в ходе этого напоролись на конкретную кривость конкретного рудимента конкретного движка, это было констатировано и Вам это не понравилось - ну извините... В конце концов никто не мешает Вам сделать то же самое с моими глобальными утверждениями.
pkarklinПри этом более чем категорично высказыватесь о том, что должно быть во FROM, а что в WHERE.
Замечательно. Давайте ради интереса проверим истинность этого Вашего утверждения.
Я подключился к этой теме в районе вот этого утверждения:
pkarklin Вы знаете. Вот в таком "простом" запросе действительно может быть и по-барабану. Но, когда в запросе джоиниться 3 десятка таблиц и накладывается с десяток условий, то "читабельнее", когда объединение выполнятеся во FROM, а условия в WHERE.
Насколько я понимаю, оно излишней категоричностью не страдает.
Ответы на это утверждение:
aZm тут уж знаете ли, кто к чему привык :)
DimaR IMHO как раз наоборот, с полюсиками текст более читабельный.
и среди прочих мое:
softwarerНе ощущаю. Имхо удобнее, когда вся информация по одному объекту собрана в одном месте, а не размазана по двум
Уже в этом месте мне интересно - будьте добры, расставьте пожалуйста "рейтинг категоричности" каждому из этих сообщений; какое более других категорично, какое - менее.
Не исключено, Вы предпочтете сказать что-нибудь про выборочное цитирование. В этом случае, будьте так добры - приведите пожалуйста невыборочную цитату в сравнении с выборочной, так, чтобы было видно, насколько я исказил смысл или хотя бы категоричность конкретного письма.
Что ж, пойдем дальше. Из того же моего письма:
softwarer
... Из-за этого достаточно часто начинают пихать в join дополнительные условия, которым вообще-то место именно в where или в подзапросе (то есть join с inline view)
Как ни странно, я здесь опираюсь в точности на Вашу предыдущую фразу: "объединения во from, условия в where". Но Вы, оказывается, атакуете столь категоричную позицию....
Any comments?
pkarklinОсобенно поражает эта категоричность в плане того, что оптимизатор сервера может "изменить" запрос до неузнаваемости,
О чем Вы, кстати, предпочли не вспоминать, когда я в первый раз об этом упомянул - видимо, это мешало атаковать "далекую от реальности картину с картезианом".
pkarklinчто в конечном итоге может говорить лишь о том, что большинстве случаев оптимизатору монорельсово, как описано объединение, в "старом" или в "новом" стиле.
Монорельсово. То есть - можно писать условия там, где их присутствие наиболее логично, не влияя на эффективность. Вас поражает стремление к логичности?
pkarklinИ это подверждает вышесказанное мной. Я понимаю, что приведенные Вами выражения объединения в "старом" стиле с точки зрения здравой логики ничем не отличаются. Но то, что детали реализации MS SQL не позволяют выполнить второе в "старом" стиле, а Oracle может, я, опять же повторюсь, не могу отнести к недостаткам реализации.
Недостаткам реализации конкретной возможности?
pkarklinС таким же успехом можно считать различия в деталях реализации ООП в Pascal и C++, как недостатки Pascal.
Кстати, удачный пример. Например, в C++ реализована крайне кривая с моей точки зрения идея неименованных конструкторов - и это безусловно недостаток реализации, вызывающий необходимость в тупом повторении определения конструкторов в каждом наследнике и в костылях типа Class Factory. Именованные виртуальные конструкторы в Pascal в этом ракурсе очень удобны.
С другой стороны, с точки зрения эффективности паскалевское безусловное размещение объектов в динамической памяти есть недостаток. Частично этот недостаток покрывается за счет оптимизированного менеджера памяти, частично его можно преодолеть за счет переопределения методов NewInstance/FreeInstance (аналог переопределения операторов new и delete в C++), но тем не менее если смотреть с точки зрения эффективности, это безусловный недостаток паскаль-реализации.
С третьей стороны, в Паскале есть рудимент в виде "старых объектов", очень похожих на объекты C++. Их можно назвать ответом с точки зрения эффективности, но и у них можно назвать недостатки, которые будут недостатками паскаль-реализации.
pkarklinИ приписывать мне идолопоклонстов к MS SQL по крайней мере некорректно. По крайне мере я стараюсь не преподносить отличия в деталях реализации MS SQL от других СУБД, как недостатки последних.
По крайней мере уже далеко не в первый раз Вы во-первых выдвигаете глобальные утверждения, которые, как потом оказывается, верны только для MS SQL, во-вторых, из всех возможных трактовок той или иной фразы Вы выбираете именно ту, которую считаете "глобальным наездом на MS SQL вообще" и реагируете соответственно.
Идолопоклонничество или другая формулировка - не суть; внешне Вы показываете весьма трепетное отношение именно к MS SQL как таковому.
Если хотите, сравните с моим отношением, которое можете найти по цитатам. Допустим, кто-то говорит нечто про Oracle. Я могу дать комментарий, подсказать какой-то аспект, согласиться - если помните, здесь я прежде всего согласился с Вами в противовес
aZm . Если говорят что-то неграмотное - могу продемонстрировать неграмотность, в том числе довольно обидным для собеседника образом. Если скажут что-то новое для меня и верное - соглашусь и учту.
pkarklinНадеюсь, Вы не сочтете мои высказывание на этот раз как "игру слов"?!
В данном случае, если выбрать изящную формулировку, Вы предпочитаете трактовать многие мои фразу исходя из гипотезы моих наихудших побуждений. Если же говорить об игре слов, то если бы у меня было желание формально поспорить, пожалуй я бы обосновал ее наличие в Вашем предыдущем абзаце, но такого желания у меня нет и я полагаю эту формулировку не более некорректной, чем некоторые использованные ранее, в том числе и мной.
pkarklin softwarerНе вижу неоднозначности. Вы написали два разных запроса, получили разные результаты и очень удивились. Я показал, что если писать их одинаково, то и результаты получатся одинаковыми - это, видимо, настолько оскорбило Вас, что Вы назвали такой подход "правильным в кавычках".
Я специально указал, если Вы обратили на это внимание, что эти запросы только кажуться одинаковыми, ибо на самом деле они разные.
Безусловно, я обратил на это внимание - иначе бы я просто указал Вам на ошибку.
Чего Вы не указали - так это где же неоднозначность? И вот на это, если Вы обратили внимание, указываю я. "Одинаковые запросы возвращают одинаковый результат" - самая что ни на есть однозначность. "Если писать с outer join или c (+), получаем один результат; если без того и без другого - можем получить другой", тоже все вполне однозначно.
pkarklin softwarerВ таком же виде это похоже на машину с двумя педалями тормоза: одна нормальная, а другая - только на правые колеса.
Простите, но теперь Вы играете словами. Повторять вышесказанное не буду.
Вы видите разницу между игрой словами и аналогией (возможно, некорректной с Вашей точки зрения)? Или же в Вашей терминологии это синонимы?
Я еще понимаю Вашу трактовку "наезда на MS SQL вообще" в других случаях, но здесь по-моему все расписано предельно однозначно.
softwarerТогда удивительно, что Вы вообще не набрасываетесь на идею преподавания. Зачем что-то объяснять, когда талантливый и сам разберется, а прочих - в дворники?
pkarklinНе вижу ничего удивительного в расхождении наших взглядов и на идею преподавания. К сожалению, предрасположенность человека к чисто механической работе (дворник) не зависит от "качества" преподавания.
Cнова воспользуюсь аналогией:
Отвратительный повар - способен приготовить посредственный обед из хороших продуктов.
Плохой повар - способен приготовить посредственный обед из посредственных продуктов.
Обычный повар - способен приготовить хороший обед из хороших продуктов и неплохой - из посредственных продуктов.
Отличный повар - способен приготовить неплохой обед из плохих продуктов и великолепный обед - из хороших продуктов.
Качество продуктов от качества повара чаще всего не зависит. А вот качество результата - зависит.
