Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 10 11 12 13 14 15 16 17 [18] 19   вперед  Ctrl
 Re: Почему ораклисты так не любят MS SQL?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67447
Блог
pkarklin
Витеевато, получатеся, неправдали?! Ваша "школа"! :)

Хм. Мой педагогический талант, видимо, черезчур силен. Надеюсь только, что не он послужил причиной пяти грамматических ошибок ;)

pkarklin
Хм. Если один движок запрещает логичную и имеющую смысл операцию, которая в другом движке делалась в "одном" месте, но разрешает сделать ее в "другом" месте не менее логично - я не считаю это недостатком реализации.

Реализации чего именно? Возможности сделать outer join как таковой - безусловно. И если бы этого "одного" места не было, и все делалось бы в "другом" - никаких вопросов.

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

pkarklin
Да даже и не думал. :) Просто меня все больше поражает тот факт, что конкретные детали реализации конкретного движка преподносятся как "недостатки" реализации только по тому, что в другом движке эти конкретные детали реализованы по другому.

Если говорить о поражениях, я перманентно поражаюсь способности прискорбно многих MSSQL-евцев воспринимать любую мелочь как глобальную атаку. Например, если Вы при случае скажете, что поведение функции LENGTH в Oracle:

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нова воспользуюсь аналогией:

  • Отвратительный повар - способен приготовить посредственный обед из хороших продуктов.

  • Плохой повар - способен приготовить посредственный обед из посредственных продуктов.

  • Обычный повар - способен приготовить хороший обед из хороших продуктов и неплохой - из посредственных продуктов.

  • Отличный повар - способен приготовить неплохой обед из плохих продуктов и великолепный обед - из хороших продуктов.

    Качество продуктов от качества повара чаще всего не зависит. А вот качество результата - зависит.
  • 23 ноя 05, 13:45    [2099176]     Ответить | Цитировать Сообщить модератору
     Re: Почему ораклисты так не любят MS SQL?  [new]
    ChA
    Member

    Откуда: Москва
    Сообщений: 11377
    softwarer
    "Классическая математическая запись" заведомо более свободна, чем польская. Разумеется, они эквивалентны, но польская своей структурой задает четкий алгоритм выполнения, в то время как в классической математической он однозначен только в весьма редких случаях (когда в выражении нет ни одной пары равноприоритетных операций).
    Именно это, собственно, и пытался донести, разумеется, подразумевалось что "классическая математическая запись" - это запись с использованием JOIN-ов. При их использовании не надо выполнять "свертку" в виде derived table или того же view, чтобы можно было использовать "плюсики", а просто, скобками, как в обычной математике, групируем операции, задавая таким образом приоритет их выполнения, дабы получить искомый результат.

    softwarer
    Может быть, к тому времени join-ы станут настолько хороши, что плюсики отомрут естественным образом, говоря же про "сейчас" - если не ошибаюсь, объективной разницы мы пока не нашли, вопрос синтаксического удобства.
    JOIN-ы уже есть, и суть их, да и синтаксис тоже, вряд ли изменятся, так что выражение "станут настолько хороши" несколько туманно звучит. Если под объективностью, в данном контексте, понимать возможность получения одинаковых результатов использованием "плюсиков" или JOIN-ов, то можно сказать, что разницы не существует. Если же говорить о концептуальном подходе, то она существует. Ваше право с этим не согласиться.
    23 ноя 05, 13:56    [2099229]     Ответить | Цитировать Сообщить модератору
     Re: Почему ораклисты так не любят MS SQL?  [new]
    pkarklin
    Member

    Откуда: Москва (Муром)
    Сообщений: 74930
    softwarer
    pkarklin
    Витеевато, получатеся, неправдали?! Ваша "школа"! :)


    Хм. Мой педагогический талант, видимо, черезчур силен. Надеюсь только, что не он послужил причиной пяти грамматических ошибок ;)


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

    softwarer
    Реализации чего именно? Возможности сделать outer join как таковой - безусловно. И если бы этого "одного" места не было, и все делалось бы в "другом" - никаких вопросов.

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


    Как мне казалось, мы обсуждали стили написания запросов с внешним объединением?! И вот с этой Вашей фраза "Это - не объективная разница, это недостаток реализации "этого места в этом сервере" я абсолютно согласен. Возможно расценив Ваши высказывания:

    softwarer
    Хм. А что-нибудь типа

    where (t1.id, 1) *= (t2.id_fk_id, t2.some_id)

    Впрочем, в любом случае это во-первых означает таки желательность использования inline view, во-вторых, смело можно назвать недостатком реализации (по крайней мере логики в таком ограничении я не вижу).


    как "общий наезд" на внешние объединения в MS SQL. Если это не так, как я это трактовал, то приношу Вам свои извинения.

    softwarer
    pkarklin
    При этом более чем категорично высказыватесь о том, что должно быть во FROM, а что в WHERE.


    Замечательно. Давайте ради интереса проверим истинность этого Вашего утверждения.


    Ну что ж, давайте! Мое заявление о Вашей категоричности я основывал на следующем Вашем высказывании:

    softwarer
    Из-за этого достаточно часто начинают пихать в join дополнительные условия, которым вообще-то место именно в where или в подзапросе (то есть join с inline view), последний соответственно разбухает и становится еще менее читабельным.


    softwarer
    Как ни странно, я здесь опираюсь в точности на Вашу предыдущую фразу: "объединения во from, условия в where". Но Вы, оказывается, атакуете столь категоричную позицию....


    Согласен, здесь я немного категоричен в оценке Вашей категоричности, причем в оценке, совпадающей с моей.

    softwarer
    Если говорить о поражениях, я перманентно поражаюсь способности прискорбно многих MSSQL-евцев воспринимать любую мелочь как глобальную атаку.


    В данном контексте скорее следовало "многих MSSQL-евцев" заменить на "pkarklina". ;)

    softwarer
    Если бы Вы сразу сказали "в MS это криво реализованный рудимент и такое сравнение не имеет смысла" - повторюсь, не было бы никаких вопросов. Если Вы начали выдвигать глобальные утверждения ("не представляю, как реализовать"), в ходе этого напоролись на конкретную кривость конкретного рудимента конкретного движка, это было констатировано и Вам это не понравилось - ну извините... В конце концов никто не мешает Вам сделать то же самое с моими глобальными утверждениями.


    Во-первых, я действительно не представлял как это реализовать в WHERE без использования доп. телодвижений. Только теперь Вы делаете ошибочнй вывод о глобальности моих утверждений. :(

    softwarer
    pkarklin
    Особенно поражает эта категоричность в плане того, что оптимизатор сервера может "изменить" запрос до неузнаваемости,


    О чем Вы, кстати, предпочли не вспоминать, когда я в первый раз об этом упомянул - видимо, это мешало атаковать "далекую от реальности картину с картезианом".


    Я, кстати, пожалел чуть позже, что не упомянул об этом. Ибо в плане запроса в MS SQL действительно бы не было картезиана и фильтра.

    softwarer
    pkarklin
    что в конечном итоге может говорить лишь о том, что большинстве случаев оптимизатору монорельсово, как описано объединение, в "старом" или в "новом" стиле.


    Монорельсово. То есть - можно писать условия там, где их присутствие наиболее логично, не влияя на эффективность. Вас поражает стремление к логичности?


    Стремление к логичности меня не поражает. Под логичностью для себя я как раз понимал написание условий объединения во FROM.

    softwarer
    Недостаткам реализации конкретной возможности?


    Да, недостатком реализации внешних объединений в WHERE.

    softwarer
    По крайней мере уже далеко не в первый раз Вы во-первых выдвигаете глобальные утверждения, которые, как потом оказывается, верны только для MS SQL, во-вторых, из всех возможных трактовок той или иной фразы Вы выбираете именно ту, которую считаете "глобальным наездом на MS SQL вообще" и реагируете соответственно.


    Гм... Ну что ж, еще раз с Вами соглашусь. Порой я глобален в своих высказываниях и при этом опираюсь только на MS SQL, впрочем, как и втрактовках той или иной фразы.

    softwarer
    Идолопоклонничество или другая формулировка - не суть; внешне Вы показываете весьма трепетное отношение именно к MS SQL как таковому.


    И с этим соглашусь!

    softwarer
    Если хотите, сравните с моим отношением, которое можете найти по цитатам. Допустим, кто-то говорит нечто про Oracle. Я могу дать комментарий, подсказать какой-то аспект, согласиться - если помните, здесь я прежде всего согласился с Вами в противовес aZm. Если говорят что-то неграмотное - могу продемонстрировать неграмотность, в том числе довольно обидным для собеседника образом. Если скажут что-то новое для меня и верное - соглашусь и учту.


    И сравнивать нечего! Ваше отношение всегда славилось сбалансированностью и именно это у меня вызывает уважение к Вам.

    softwarer
    Вы предпочитаете трактовать многие мои фразу исходя из гипотезы моих наихудших побуждений.


    Ну, что ж ... И тут Вы правы. Как и во всем остальном, что я не буду цитировать.

    И так, попробуем подвести итог:

    1. Реализация внешних объединений в предложении WHERE в MS SQL не логична т.е. ее функционал реализован недостаточно, по сравнению с аналогичной реализацией в Oracle.
    2. Реализация внешних объединений в предложении FROM в MS SQL покрывает недостаток реализации в предложении WHERE, не внося дополнительных ограничений ни на ее использование конечным разработчиком, ни на возможности оптимизатора.
    3. Выбор между способом реализации объединения (в WHERE via во FROM) в запросе полностью лежит на плечах конечного разрабочика, причем для MS SQL с учетом имеющихся недостатков в реализации внешних объединений в предложении WHERE.
    23 ноя 05, 16:15    [2100103]     Ответить | Цитировать Сообщить модератору
     Re: Почему ораклисты так не любят MS SQL?  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 67447
    Блог
    ChA
    Именно это, собственно, и пытался донести, разумеется, подразумевалось что "классическая математическая запись" - это запись с использованием JOIN-ов.

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

    Собственно, пожалуй можно сказать, что в ходе этого обсуждения мы выявили одну деталь, которую можно назвать объективной разницей - отсутствие в where-синтаксисе транзитивности, операции типа a.id = b.id = c.id.

    ChA
    JOIN-ы уже есть, и суть их, да и синтаксис тоже, вряд ли изменятся, так что выражение "станут настолько хороши" несколько туманно звучит.

    Вы полагаете, они никак не изменятся? С моей точки зрения, например, более чем естественно при такой постановке вопроса сделать что-нибудь типа

    a key join b key join c on a.a_id, b.b_id

    ChA
    Если под объективностью, в данном контексте, понимать возможность получения одинаковых результатов

    Нет, конечно. Я имею в виду некую "большую разницу" в получении этого результата разными путями, то есть "тут легко, тут сложно", "тут удобно, тут приходится извернуться", "тут получается читаемый код, тут - нечитаемый". Объективность подразумевает либо нечто, достаточно формализуемое, без апелляций к нечетким личным оценкам, либо то, что разница достаточно велика и оспаривать ее существование откровенно глупо.
    23 ноя 05, 18:05    [2100781]     Ответить | Цитировать Сообщить модератору
     Re: Почему ораклисты так не любят MS SQL?  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 67447
    Блог
    pkarklin
    А Ваша "школа" -излагать мысли в таких сложных предложениях,....

    Да, моя очень средняя школа стимулировала подобные привычки, и если в серьезных документах я успеваю побыть еще и редактором своих изысков, то в быстрой письменной речи не всегда безупречен :)

    pkarklin
    трудно понять, что же Вы конкретно хотели сказать и как это расценивать. ;)

    В "моей школе" на этот случай припасены варианты "задать уточняющий вопрос" и "явно выделить варианты и ответы на каждую из возможных трактовок" ;)

    pkarklin
    Ну что ж, давайте! Мое заявление о Вашей категоричности я основывал на следующем Вашем высказывании:

    Безусловно, вопрос вкусов, но лично я не склонен считать высказывания с оборотами типа "вообще-то" столь уж категоричными. Во всяком случае, если пропарсить форум, опираясь на этот критерий, некатегоричных высказываний наберется довольно мало.

    Cобственно, в тот момент я полагал, что будет некое обсуждение "какие условия где лучше писать и почему". Подразумевая, что 100% условий во from не есть лучше и по крайней мере некоторые условия там будут.. весьма чужеродны.

    pkarklin
    softwarer
    Если говорить о поражениях, я перманентно поражаюсь способности прискорбно многих MSSQL-евцев воспринимать любую мелочь как глобальную атаку.


    В данном контексте скорее следовало "многих MSSQL-евцев" заменить на "pkarklina". ;)

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

    pkarklin
    Я, кстати, пожалел чуть позже, что не упомянул об этом. Ибо в плане запроса в MS SQL действительно бы не было картезиана и фильтра.

    Мм.. уточните пожалуйста. MS SQL заведомо не использует такую комбинацию или ее бы не было при использовании join?

    pkarklin
    Стремление к логичности меня не поражает. Под логичностью для себя я как раз понимал написание условий объединения во FROM.

    В такой формулировке становится вопросом - что есть условия объединения, а что - нет. Собственно это другая формулировка все того же "что где логичнее смотрится".

    pkarklin
    1. Реализация внешних объединений в предложении WHERE в MS SQL не логична т.е. ее функционал реализован недостаточно, по сравнению с аналогичной реализацией в Oracle.

    Я не считаю "логичной" либо "не логичной" разницу в возможностях; противопоставление тут не нужно. Я считаю нелогичной эту реализацию саму по себе, потому что она не замкнута. Грубо говоря, если я правильно Вас понял, то:

    -- не работает
    from a, b
    where a.id *= b.id and 1 *= b.some_value
    
    -- полагаю, работает
    from (select a.*, 1 some_value from a) a, b
    where a.id *= b.id and a.some_value *= b.some_value
    
    -- полагаю, работает
    from a, (select * from b where some_value = 1) b
    where a.id *= b.id

    Поскольку все это - формы одного и того же, на уровне тривиальных преобразований, я не понимаю такой разницы. Механизм, который умеет выполнить второй запрос, не может не уметь выполнить первый. Именно поэтому я назвал такую ситуацию нелогичной.
    23 ноя 05, 19:00    [2101015]     Ответить | Цитировать Сообщить модератору
     Re: Почему ораклисты так не любят MS SQL?  [new]
    mal_ora
    Member

    Откуда: Киев
    Сообщений: 40
    aZm
    вообще говоря, такие вопросы луше бы задавать на форуме по ораклу


    Извините, ориентировался по никам, а не по названию темы. Тема заезжаная, а люди спорят опытные, на это я и расчитывал.

    Опускать Оракле не хочу, т.к. неплохая СУБД. IMHO Единственное что админу надо делать немного больше телодвижений (неопытному). В МССКЛ многие вещи делаются на автомате, например та же устаревшая статистика не очень замедляет (или не ускоряет) выполнение запроса (построение оптимального плана и хеш таблиц).

    За ответы спасибо. Спрошу в другом форуме.
    23 ноя 05, 22:40    [2101486]     Ответить | Цитировать Сообщить модератору
     Re: Почему ораклисты так не любят MS SQL?  [new]
    ChA
    Member

    Откуда: Москва
    Сообщений: 11377
    softwarer
    Я, собственно, пытаюсь донести, что с тем же успехом эту аналогию можно трактовать наоборот.
    Возможно такая трактовка имела бы смысл, если бы в польской обратной записи были допустимы скобки, позволяющие избегать позиционности записи. Правда у нее есть другой плюс, парсинг элементарен, но этого недостаточно, чтобы стать поклонником языка Forth, если правильно помню название.
    softwarer
    Вы полагаете, они никак не изменятся? С моей точки зрения, например, более чем естественно при такой постановке вопроса сделать что-нибудь типа
    a key join b key join c on a.a_id, b.b_id
    Стандарты, как правило, имеют тенденцию расширятся, но не изменяться. Хотя шанс есть, "key join" отсутствует в стандарте, так что можете принять активное участие в работе комитета по SQL в продвижении предлагаемого варианта, почему бы и нет ?

    P.S. IMHO, SQL преследует родовое проклятие. Попытка создать язык для бухгалтеров привела к тому, что язык потерял строгость и однозначность в угоду пользователям, которые так и не научились и, соответственно, не стали им пользоваться. А посему варианты развития SQL, предлагаемые и фиксируемые ANSI, выглядят не всегда последовательно и убедительно, за что и критикуемы рядом теоретиков РМД.
    24 ноя 05, 00:00    [2101640]     Ответить | Цитировать Сообщить модератору
     Re: Почему ораклисты так не любят MS SQL?  [new]
    ASCRUS
    Member

    Откуда: МО Электросталь
    Сообщений: 5994
    softwarer
    Вы полагаете, они никак не изменятся? С моей точки зрения, например, более чем естественно при такой постановке вопроса сделать что-нибудь типа
    a key join b key join c on a.a_id, b.b_id

    В WatcomSQL есть "key join", причем если соединение идет только по FK-PK, то и "on" даже писать не надо:
    SELECT *
    FROM a 
      KEY JOIN b  // в итоге будет b.fk = a.pk
      KEY JOIN c ON c.field2 > 1 // в итоге будет c.fk = b.pk AND c.field2 > 1
    
    Хотя я этой штукой только когда в ISQL чего нибудь для себя ручками пишу, пользуюсь. А в рабочих запросах БД пишу обычные JOIN, так как неютно отдавать условия соединения таблиц на откуп оптимизатору, он конечно все соединит, но лучше самому ручками прописать, так надежнее. Ну а для клиентского приложения в запросах в основном уже хранимки используются, там key join вообще не будет работать
    24 ноя 05, 06:21    [2101794]     Ответить | Цитировать Сообщить модератору
     Re: Почему ораклисты так не любят MS SQL?  [new]
    pkarklin
    Member

    Откуда: Москва (Муром)
    Сообщений: 74930
    2 softwarer

    IMHO, про школу, категоричность и влияние чего-то на людей сказно уже давольно много, поэтому эти Ваши высказывания оставлю без ответа. Только по сути:

    softwarer
    Грубо говоря, если я правильно Вас понял, то:


    --не работает
    SELECT
      *
    FROM
      @T1 T1, @T2 T2
    WHERE 
      T1.id *= T2.id_FK_ID and 1 *= T2.SomeID
    
    --работает
    SELECT
      *
    FROM
      (SELECT T1.*, 1 SomeID FROM @T1 T1) T1, @T2 T2
    WHERE
      T1.id *= T2.ID_FK_ID AND T1.SomeID *= T2.SomeID 
    
    --работает
    SELECT
      *
    FROM
      @T1 T1, (SELECT * FROM @T2 WHERE SomeID = 1) T2
    WHERE
      T1.id *= T2.ID_FK_ID

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


    Вы знаете, я устал от беспредметного спора с Вами о том, чья логика "логичнее" Ваше или другая. Если Вы считаете абсолютно логичным только то, что считаете лично логичным, то это Ваше право! Но "абсолютной логичности", как и "абсолютной истины" не существует! Есть только наше субъективное восприятие этого! IMHO.


    softwarer
    pkarklin
    Я, кстати, пожалел чуть позже, что не упомянул об этом. Ибо в плане запроса в MS SQL действительно бы не было картезиана и фильтра.


    Мм.. уточните пожалуйста. MS SQL заведомо не использует такую комбинацию или ее бы не было при использовании join?


    Мной было сказано:

    pkarklin
    softwarer
    собственно я довольно часто повторяю фразу, что новичку проще всего представить себе выполнение sql-запроса как картезиан из таблиц во from, на который накладывается фильтр, заданный в where.


    Дежавю. ;) Т.е. представить совсем наоборот, как происходит на самом деле!


    Пример:

    SELECT
      *
    FROM
      @T1 T1
      INNER JOIN @T2 T2 ON
      T1.id = T2.ID_FK_ID
    
    SELECT
      *
    FROM
      @T1 T1, @T2 T2
    WHERE
      T1.id = T2.ID_FK_ID

    В обоих случаях план выполнения будет одинаковым и без картезиана с фильтром:


      |--Hash Match(Inner Join, HASH:([T1].[id])=([T2].[id_FK_ID]), RESIDUAL:([T2].[id_FK_ID]=[T1].[id]))
           |--Table Scan(OBJECT:(@T1 AS [T1]))
           |--Table Scan(OBJECT:(@T2 AS [T2]))
    
    (3 row(s) affected)
    24 ноя 05, 08:50    [2101961]     Ответить | Цитировать Сообщить модератору
     Re: Почему ораклисты так не любят MS SQL?  [new]
    tygra
    Member

    Откуда: Тверь (Иркутск, Край)
    Сообщений: 9997
    Что-то в сторону философии написания селектов куда-то унесло :))

    Мне лично больше нравится писать через join - так понятно сразу, по каким критериям таблица соединяется (не надо искать в многострочном where, особенно если много таблиц). Ну и left join понятнее. Мне лично.

    Если кто-то привык по-другому - ну хозяин барин.

    Главное, чтобы все, что надо, получилось и тем и тем спопобом. Я пока что не заметил, чтобы что-то не смоглось.

    -- Tygra's --
    24 ноя 05, 09:48    [2102170]     Ответить | Цитировать Сообщить модератору
     Re: Почему ораклисты так не любят MS SQL?  [new]
    4321
    Member [заблокирован]

    Откуда:
    Сообщений: 3573
    pkarklin
    "абсолютной истины" не существует! Есть только наше субъективное восприятие этого! IMHO.
    можно вопрос? Существует ли (на ваше имхо) мир, вне вашего восприятия?

    Поясню суть вопроса:
    Если "нет" - то нет и предмета спора, даже и сам спор существует только в вашем восприятии . Т.е. споря казалось бы с софтваре вы, на деле, занимаетесь мозговым онанизмом.
    Если же всё-таки "да", - то тянет ли он (мир) на абсолютную истину? (Оставим в стороне пока чисто физический релятивизм)
    24 ноя 05, 11:06    [2102665]     Ответить | Цитировать Сообщить модератору
     Re: Почему ораклисты так не любят MS SQL?  [new]
    pkarklin
    Member

    Откуда: Москва (Муром)
    Сообщений: 74930
    2 4321

    *?:деть - не мешки ворочать!
    24 ноя 05, 11:13    [2102720]     Ответить | Цитировать Сообщить модератору
     Re: Почему ораклисты так не любят MS SQL?  [new]
    4321
    Member [заблокирован]

    Откуда:
    Сообщений: 3573
    pkarklin
    2 4321

    *?:деть - не мешки ворочать!
    Вам, как вижу, виднее.


    ЗЫ. так это все, что вы можете ответить _по существу_ заданного вам вопроса?
    (бл@, терпеть ненавижу pizдунов, с этими их "аппсалютна атнасительными истинами".
    поубивав бы усих )
    24 ноя 05, 11:26    [2102839]     Ответить | Цитировать Сообщить модератору
     Re: Почему ораклисты так не любят MS SQL?  [new]
    pkarklin
    Member

    Откуда: Москва (Муром)
    Сообщений: 74930
    4321
    Вам, как вижу, виднее.


    А то?!

    4321
    ЗЫ. так это все, что вы можете ответить _по существу_ заданного вам вопроса?


    А из моего ответа softwarer разве этого непонятно?!

    4321
    (бл@, терпеть ненавижу pizдунов, с этими их "аппсалютна атнасительными истинами".
    поубивав бы усих )


    Нет, ребята, пулемета я вам не дам! ((с) Белое солнце пустыни)
    24 ноя 05, 11:32    [2102902]     Ответить | Цитировать Сообщить модератору
     Re: Почему ораклисты так не любят MS SQL?  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 67447
    Блог
    ASCRUS
    В WatcomSQL есть "key join", причем если соединение идет только по FK-PK, то и "on" даже писать не надо:

    Если обратите внимание, я и написал его только в одном из двух join-ов :)

    ASCRUS
    А в рабочих запросах БД пишу обычные JOIN, так как неютно отдавать условия соединения таблиц на откуп оптимизатору, он конечно все соединит, но лучше самому ручками прописать, так надежнее.

    А вот поэтому я и прописал поля во втором :)

    Если бы я разрабатывал реализацию такой конструкции, я бы специфицировал ее примерно так:

    - если используется key join без полей, и между таблицами только один FK, либо связь один к одному, используется этот FK, иначе - ошибка

    - если используется key join с перечислением полей с одного конца join-а, и есть FK опирающийся на этот набор полей, используется этот FK, иначе ошибка

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

    ASCRUS
    Ну а для клиентского приложения в запросах в основном уже хранимки используются, там key join вообще не будет работать

    Ээ.. в смысле, физически запрещено использовать их в хранимках? А чем вызвано такое ограничение?
    24 ноя 05, 11:45    [2103038]     Ответить | Цитировать Сообщить модератору
     Re: Почему ораклисты так не любят MS SQL?  [new]
    4321
    Member [заблокирован]

    Откуда:
    Сообщений: 3573
    2 pkarklin

    Однако:
    pkarklin
    4321
    ЗЫ. так это все, что вы можете ответить _по существу_ заданного вам вопроса?
    А из моего ответа softwarer разве этого непонятно?!
    Нет, не видно.
    Повторяю вопрос:
    4321
    Существует ли (на ваше имхо) мир, вне вашего восприятия?
    Если найдете в своем (каком из всех?) ответе softwarer ответ на данный вопрос - укажите.

    ещЁ раз: Даже если _всё_ существует в вашем "имхо" (восприятии), в т.ч. и мир и спор и т.п., то уже само ваше имхо "становится" (в фило-совском смысле становления) аппсалютной истиной. Т.е. опять приходим к противоречию.
    И если вы отказываете мне в пулемете, то я не откажу вам в мотке веревки и кусочечке мыльца.
    24 ноя 05, 12:08    [2103277]     Ответить | Цитировать Сообщить модератору
     Re: Почему ораклисты так не любят MS SQL?  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 67447
    Блог
    pkarklin
    Вы знаете, я устал от беспредметного спора с Вами о том, чья логика "логичнее" Ваше или другая. Если Вы считаете абсолютно логичным только то, что считаете лично логичным, то это Ваше право! Но "абсолютной логичности", как и "абсолютной истины" не существует! Есть только наше субъективное восприятие этого! IMHO.

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

    Если Вы внутри себя не поменяли своего мнения - это, безусловно, Ваше право. Это мне напоминает тот момент, когда Вы во второй раз начали рассказывать о большей для любой СУБД эффективности ХП по сравнению с обычными запросами.

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

    pkarklin
    Мной было сказано:

    Это меня не удивляет, но если вспомните, я говорил несколько о другом.

    https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=233233&pg=16#2096230

    Чуть после Вашего несоответствия действительности я привел пример запроса, где картезиан может оправданно присутствовать в плане. Еще чуть позже, если не ошибаюсь, аналогичное упоминание было у AI.

    В связи с чем, ответьте пожалуйста на следующий вопрос: существуют ли случаи, когда при запросе к связанным таблицам MS SQL будет использовать в плане картезиан. Если нет - почему, если известен ответ на этот вопрос. Если да - спасибо; информация про "большее соответствие джойнов действительности" окажется полученной.
    24 ноя 05, 12:11    [2103301]     Ответить | Цитировать Сообщить модератору
     Re: Почему ораклисты так не любят MS SQL?  [new]
    pkarklin
    Member

    Откуда: Москва (Муром)
    Сообщений: 74930
    4321
    ещЁ раз: Даже если _всё_ существует в вашем "имхо" (восприятии), в т.ч. и мир и спор и т.п., то уже само ваше имхо "становится" (в фило-совском смысле становления) аппсалютной истиной. Т.е. опять приходим к противоречию.


    Вы знаете, я плохой филосов, поэтому мне сложно, занимаясь "мозговым онанизмом", аргументированно, в филосовских терминах ответить на Ваш вопрос.
    24 ноя 05, 12:40    [2103517]     Ответить | Цитировать Сообщить модератору
     Re: Почему ораклисты так не любят MS SQL?  [new]
    ASCRUS
    Member

    Откуда: МО Электросталь
    Сообщений: 5994
    softwarer
    Если бы я разрабатывал реализацию такой конструкции, я бы специфицировал ее примерно так:

    - если используется key join без полей, и между таблицами только один FK, либо связь один к одному, используется этот FK, иначе - ошибка

    В ASA так и есть.

    softwarer
    - если используется key join с перечислением полей с одного конца join-а, и есть FK опирающийся на этот набор полей, используется этот FK, иначе ошибка

    Тут сделано по другому - для KEY и NATURAL JOIN-ов можно указывать правила соединения, например:
    // Соединить таблицу "a" по ее FK  с таблицами "b" и "с"
    SELECT *
    FROM a KEY JOIN (b, c);
    
    // Соединить каждую из таблиц "a" и "b" по их FK с таблицами "c" и "d"
    SELECT *
    FROM (a, b) KEY JOIN (c, d);

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

    С одной стороны да. С другой стороны не сказать, что в свете вышеприведенных примеров KEY JOIN для сложных запросов читабельней, чем обычный JOIN (для меня во всяком случае, конечно может дело привычки, как и читабельность соединений через JOIN vs WHERE).

    softwarer
    ASCRUS
    Ну а для клиентского приложения в запросах в основном уже хранимки используются, там key join вообще не будет работать

    Ээ.. в смысле, физически запрещено использовать их в хранимках? А чем вызвано такое ограничение?

    Внутри процедур ограничений никаких нет (это же WatcomSQL, а не TSQL ). Я имел ввиду такое:
    SELECT *
    FROM Proc1() p1
      KEY JOIN Proc2() p2;
    Самое интересное, что если обе процедуры являются inline (то есть могут свой план запроса включать в основной план запроса, как и представления), то ведь KEY JOIN сработает, вот только как - это можно будет узнать только после запуска запроса
    24 ноя 05, 13:00    [2103652]     Ответить | Цитировать Сообщить модератору
     Re: Почему ораклисты так не любят MS SQL?  [new]
    pkarklin
    Member

    Откуда: Москва (Муром)
    Сообщений: 74930
    softwarer
    Хм. Я уверен, что Вы не сможете показать ни одной цитаты, в которых я бы говорил о некоей "абсолютной логичности". Я также уверен, что могу показать более чем достаточно мест, где подчеркиваю, что это мое мнение - собственно, только в процитированном Вами моем абзаце таковых два. В прошлый раз мы кажется уже выяснили, что категоричность, с которой Вы боролись - Ваша собственная.

    Если Вы внутри себя не поменяли своего мнения - это, безусловно, Ваше право. Это мне напоминает тот момент, когда Вы во второй раз начали рассказывать о большей для любой СУБД эффективности ХП по сравнению с обычными запросами.

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


    Вы знаете, Ваши высказывания все больше начинают напоминать мне демагогию. Если Вы обратили внимание, то я сказал:

    pkarklin
    Если Вы считаете абсолютно логичным только то, что считаете лично логичным, то это Ваше право!


    Т.е. я сделал предположение ("Если ...") о Вашем отношении к этому вопросу, Вы же опять, используя словесные обороты, пытаетесь преподнести мои слова так, что я действительно говорю о том, чего не было. Так и скажите, что "нет, я так не считаю!", а не требуйте от меня подтверждения цитатами того, что я предположил. И дальше, "про оценку фактов". Мне каждый раз, когда я пишу в форум, надо у каждого слова ставить IMHO? Или сразу уж в автоподпись записать: "Все вышесказанное IMHO"?

    Теперь по делу.

    softwarer
    Чуть после Вашего несоответствия действительности я привел пример запроса, где картезиан может оправданно присутствовать в плане. Еще чуть позже, если не ошибаюсь, аналогичное упоминание было у AI.


    Да, да. Помню. Про запрос из трех таблиц и про star optimisation. Возможно, что оптимизатор Oracle делает это так, хотя я не считаю это самым оптимальным подходом. Я не видел ни разу в планах выполнения запросов в MS SQL получения картезианов, включая star запросы. Для таких запросов наиболее распространен оператор Nested Loops с поиском по индексу.
    24 ноя 05, 13:26    [2103827]     Ответить | Цитировать Сообщить модератору
     Re: Почему ораклисты так не любят MS SQL?  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 67447
    Блог
    ASCRUS
    Тут сделано по другому - для KEY и NATURAL JOIN-ов можно указывать правила соединения, например:

    То есть, если я правильно Вас понял, если таблицы соединены несколькими ключами, синтаксис KEY JOIN становится неприменимым. Или нет? Я как раз имел в виду дать возможность указать, какой именно ключ имеется в виду.

    ASCRUS
    С одной стороны да. С другой стороны не сказать, что в свете вышеприведенных примеров KEY JOIN для сложных запросов читабельней, чем обычный JOIN

    Если не детализировать соединение, то есть вариант единственного ключа, то наверное читабельнее. Хотя это безусловно вопрос привычки.

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

    ASCRUS
    Я имел ввиду такое:
    SELECT *
    FROM Proc1() p1
      KEY JOIN Proc2() p2;

    Спасибо, упустил из виду эту возможность.

    В принципе, для соединения с агрегированными объектами операция наверное идеологически неправильная. Вообще, имхо, такая операция должна давать ошибку всегда, когда существует несколько разных вариантов ее выполнения.Даже если между наборами таблиц, участвующих в Proc1 и Proc2, существует единственный ключ, даже если каждая построена как выборка из единственной таблицы, наверное синтаксис тоже будет неудачным - поскольку это будет нарушением инкапсуляции, использованием информации, упакованной внутрь процедуры и относящейся к ее реализации. Наконец, сама по себе задача "а используй ключ к той из таблиц, которая первой подвернется под руку" вряд ли удачно поставлена.

    Если поставить задачу развиваться в этом направлении, я бы, наверное, сделал возможность указать для ХП или view "основную", стержневую таблицу и воспринимал бы KEY JOIN как операцию именно с этой таблицей.
    24 ноя 05, 17:51    [2105676]     Ответить | Цитировать Сообщить модератору
     Re: Почему ораклисты так не любят MS SQL?  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 67447
    Блог
    pkarklin
    Теперь по делу.

    Предпочту вынести осмысленную часть вперед.

    pkarklin
    Да, да. Помню. Про запрос из трех таблиц и про star optimisation. Возможно, что оптимизатор Oracle делает это так, хотя я не считаю это самым оптимальным подходом.

    А каков самый оптимальный подход?

    pkarklin
    Для таких запросов наиболее распространен оператор Nested Loops с поиском по индексу.

    Для обеих связок?

    -----------------------------------------------------------------------

    pkarklin
    Вы знаете, Ваши высказывания все больше начинают напоминать мне демагогию. Если Вы обратили внимание, то я сказал:

    pkarklin
    Если Вы считаете абсолютно логичным только то, что считаете лично логичным, то это Ваше право!


    Т.е. я сделал предположение ("Если ...") о Вашем отношении к этому вопросу,

    К сожалению, сам по себе прием предположения может использоваться как демагогический. Для этого нужно предположить что-то, что создаст ложное впечатление, уведет разговор в сторону итп.

    Да, Вы правы, я мог сказать "я так не считаю", и может быть мне следовало так сделать. Я, однако, предпочел сфокусировать внимание на том, что ИМХО для такого предположения у Вас отсутствует база, основания.

    pkarklin

    Вы же опять, используя словесные обороты, пытаетесь преподнести мои слова так, что я действительно говорю о том, чего не было. Так и скажите, что "нет, я так не считаю!", а не требуйте от меня подтверждения цитатами того, что я предположил.

    Прямо в этом абзаце Вы пытаетесь преподнести мои слова так, словно я требую от Вас подтверждения цитатами "того что Вы предположили". Согласны?

    Далее, я сейчас перечитал свое письмо к Вам. Вы сделали предположение с отсутствующей альтернативой, то есть "Если так, то .... иначе <ничего не сказано>". Я ответил на "то", на <ничего не сказано> ответил тем же. Если Вы считаете, что этим я намеренно создаю превратное впечатление... что ж, учту, мне такое не приходило в голову. Я просто отвечаю на сказанное Вами.

    pkarklin
    И дальше, "про оценку фактов". Мне каждый раз, когда я пишу в форум, надо у каждого слова ставить IMHO? Или сразу уж в автоподпись записать: "Все вышесказанное IMHO"?

    Ну, во-первых, сначала атакуя "мою категоричность", а потом делая предположения об абсолютизации моей логики, Вы, похоже, хотите от меня именно этого :)

    Во-вторых - эта стандартная фраза, имхо, здесь не то что не подходит, а является вышеосужденной Вами игрой слов. Я - именно я - написал в форум некие факты и свою оценку. Далее, я предложил Вам, если это соответствует Вашему мнению, написать что-нибудь типа "не согласен с такой оценкой". При чем тут ИМХО, которое Вам якобы надо ставить у написанного Вами?
    24 ноя 05, 19:34    [2106084]     Ответить | Цитировать Сообщить модератору
     Re: Почему ораклисты так не любят MS SQL?  [new]
    Александр Гoлдун
    Member

    Откуда:
    Сообщений: 2290

    softwarer пишет:

    > То есть, если я правильно Вас понял, если таблицы соединены несколькими
    > ключами, синтаксис KEY JOIN становится неприменимым.

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

    Posted via ActualForum NNTP Server 1.3

    24 ноя 05, 19:50    [2106131]     Ответить | Цитировать Сообщить модератору
     Re: Почему ораклисты так не любят MS SQL?  [new]
    Рыжий Кот
    Member

    Откуда: Мягкий Диван; [забанен] Рустамом; [разбанен] П02;
    Сообщений: 21678
    про KEY JOIN

    KEY JOIN tableX AS Foreign_key_name

    полностью избавляют от проблем, поэтому зря вы его так ;)

    Картинка с другого сайта.
    24 ноя 05, 20:07    [2106181]     Ответить | Цитировать Сообщить модератору
     Re: Почему ораклисты так не любят MS SQL?  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 67447
    Блог
    Александр Гoлдун
    Просто несколько раз уже были ситуации, когда в процессе доработки структуры появлялись новые FK на те же таблицы и зашитый запрос становился неработоспособным.

    Поэтому я и предусмотрел в "своей спецификации" возможность выбора FK.

    Но даже здесь - пожалуй, вопрос. Может быть, я избалован инвалидными объектами оракла (На всякий случай: очень удобно, при изменении таблицы связанные автоматически объекты перекомпилируются и некорректность тут же станет видна. Это иногда мешает на production-ах, но удобно в разработке) - но полагаю, такой вот "становящийся неработоспособным" запрос не столь серьезной проблемой, а вот оставшийся работоспособным, но ставший по сути неверным (например, при добавлении поля в FK) - весьма и весьма опасным.
    24 ноя 05, 20:41    [2106230]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 .. 10 11 12 13 14 15 16 17 [18] 19   вперед  Ctrl
    Все форумы / Сравнение СУБД Ответить