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

Откуда: Москва (Муром)
Сообщений: 74930
softwarer
С другой стороны, с декларативным подходом никаких непониманий не возникает; написали фильтр, сервер выбрал наиболее эффективный способ его реализации, все замечательно.


Вне зависимости от того, что это - объединение
22 ноя 05, 17:56    [2096404]     Ответить | Цитировать Сообщить модератору
 Re: Почему ораклисты так не любят MS SQL?  [new]
pkarklin
Member

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

softwarer
С другой стороны, с декларативным подходом никаких непониманий не возникает; написали фильтр, сервер выбрал наиболее эффективный способ его реализации, все замечательно.


Вне зависимости от того, что это - объединение во FROM или фильтр в WHERE сервер в любом случаи выберет оптимальный план.
22 ноя 05, 17:57    [2096408]     Ответить | Цитировать Сообщить модератору
 Re: Почему ораклисты так не любят MS SQL?  [new]
Витал
Member

Откуда: Россия, Санкт-Петербург
Сообщений: 2035
А вообще-то, лично я счастлив, что есть Оракл (и ДБ2 и другие скули и бейсы), хоть я и мсскулист-сервист.
Что происходит при отсутствии конкуренции? Со временем превращается в г... в плохой продукт. А пока мы спорим есть надежда, что этого не произойдет. Так что дай Бог здоровья и процветания Ораклу.
22 ноя 05, 17:59    [2096421]     Ответить | Цитировать Сообщить модератору
 Re: Почему ораклисты так не любят MS SQL?  [new]
AI
Member

Откуда: Москва
Сообщений: 2817
pkarklin

Я не представляю уровень новичка, которому нужно было бы объяснять про прямое, левое и правое объединение более, чем их определение!!! Или этому новичку надо чем-нибудь другим заниматься. А вот "объяснение" с искажением сути происходящего, то есть с искажением того, что он увидит в плане выполнения запроса считаю в корне не правильным.


А если после "a join b join c" в плане выполнения стоит порядок связки "a-c-b"? Вот тут-то новички (у меня на курсе сейчас как раз такие сидят) и "приплывают". Им абсолютно непонятно, почему при, казалось бы, заданном явно порядке связок сервер работает совсем по-другому...

В этом смысле связки в where более отражают суть происходящего на сервере. Кстати, в случае star optimization oracle делает из кучи таблиц-справочников декартово соединение, накладывает на него where и только потом полученный результат связывает с оставшейся таблицей фактов. Я уж не говорю о системе query rewrite или star transformation, которые вообще изменяют исходный запрос на более оптимальный.
22 ноя 05, 18:25    [2096541]     Ответить | Цитировать Сообщить модератору
 Re: Почему ораклисты так не любят MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
softwarer
ASCRUS
То есть как раз JOIN-ы позволяют явно описать порядок соединения таблиц и таким образом избавиться от неоднозначности и дать возможность оптимизатору построить наиболее эффективный план запроса.

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

Чем же план будет менее эффективным, позвольте полюбопытствовать и как/чем он сужается ?

P.S. Я не отрицаю, что у каждой СУБД свой оптимизатор и свои алгоритмы работы. Поэтому для более правильного ведения диалога уточняю - в Sybase ASA никакой порядок построения запросов не может навязывать оптимизатору план построения (вплоть до того, что написанный LEFT JOIN будет в плане стоять как INNER JOIN, если по метаструктуре БД по другому быть бы и не могло), но зато может "подсказывать" оптимизатору, в какую сторону копать. Думаю проф. любой РСУБД может сказать, что в сложных запросах оптимизатор может запросто лажануться, особенно когда в соединениях участвуют таблицы с огромных кол-вом записей. Поэтому "подсказка" оптимизатору в запросах через порядок соединения JOIN или LATERAL (внутреннее соединение - расширение вендора Watcom), во всяком случае в ASA можно мягко подтолкнуть оптимизатор в сторону правильного выбора планов, без какого либо навязывания хинтов (кстати показательно, что в приведенном Вашем варианте хинт таки, да стоял, я же пока не залезу в BOL, даже не вспомню, как там правильно в ASA указывать хинты, которые и появились ко всему прочему не так давно, можно сказать на всякий пожарный).
22 ноя 05, 18:42    [2096601]     Ответить | Цитировать Сообщить модератору
 Re: Почему ораклисты так не любят MS SQL?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
pkarklin
Такой запрос для MS SQL синтаксически не верен.

Увы.

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

Эээ... Не вижу недостатка ни в использовании inline view

Не кажется ли Вам, что Ваша формулировка решительно не соответствует сказанному мной и в свете этого может быть квалифицирована как игра слов, создающая превратную картину?

pkarklin
(хоть такого термина и не существует для MS SQL), и уж тем более в реализации.

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

Если бы MS SQL не поддерживал такого синтаксиса вообще - это было бы проектным решением, которое можно считать хорошим или плохим, и ничего более. Если поддерживает в виде огрызка - это, увы, печальный факт, недостаток реализации.

Судя по дальнейшему тону, Вы вошли в агрессивный режим, но я все-таки попытаюсь воззвать к Вашему разуму. Представьте себе, гипотетически, что Oracle поддерживает join-синтаксис только для inner join-ов. Представьте себе, что на основании этого я говорю что-нибудь типа "не представляю себе, как в этом синтаксисе написать outer join".

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

pkarklin
Вряд ли можно отнести к недостатку реализации "запрет" на написание всего и вся в предложении WHERE. IMHO.

И снова Вы играете словами. Условия

/*1*/ a.id (+) = 1 and
/*2*/ a.id (+) = b.id

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

pkarklin
Я ничуть не сомневался, что вы напишите "правильный" запрос. Хотя ввод ANSI стандартом объединение во FROM как раз и был призван устранить неодназначность, которую я описал!

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

pkarklin
Конечно, ограничена. Просто часть "возможностей" реализована в другом месте (FROM), что опять же лично я не считаю недостаткоом реализации, а совсем наоборот.

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

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

pkarklin
Хотя вот эта фраза, которую Вы непервый раз произносите:
....
Полностью объясняет Вашу "любовь" к WHERE.

Переворачиваете с ног на голову. Впрочем, не первый раз.

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

Тогда совет - никогда не занимайтесь преподаванием новичкам. Талантливые, конечно, выдержат, а вот обычных покалечите.

pkarklin
Или этому новичку надо чем-нибудь другим заниматься.

Тогда удивительно, что Вы вообще не набрасываетесь на идею преподавания. Зачем что-то объяснять, когда талантливый и сам разберется, а прочих - в дворники?

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

В чем абсолютно правы, кстати. Если хотите, уточню свою формулировку (заменю "представить выполнение" на "представить результат"), чтобы Вы больше не могли играть на этом, но Вы и так это знаете, поэтому, полагаю, Вашего отношения никак не изменит.
22 ноя 05, 18:44    [2096608]     Ответить | Цитировать Сообщить модератору
 Re: Почему ораклисты так не любят MS SQL?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
ASCRUS
ASCRUS
То есть как раз JOIN-ы позволяют явно описать порядок соединения таблиц

Чем же план будет менее эффективным, позвольте полюбопытствовать и как/чем он сужается ?

Явно описать порядок соединения - значит, отсечь планы, опирающиеся на другой порядок соединения. Или давайте уточнять, как Вы описали дальше.

ASCRUS
Поэтому "подсказка" оптимизатору в запросах через порядок соединения JOIN или LATERAL (внутреннее соединение - расширение вендора Watcom), во всяком случае в ASA можно мягко подтолкнуть оптимизатор в сторону правильного выбора планов, без какого либо навязывания хинтов

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


ASCRUS
(кстати показательно, что в приведенном Вашем варианте хинт таки, да стоял, я же пока не залезу в BOL, даже не вспомню, как там правильно в ASA указывать хинты,

Вы полагаете, я не залез в документацию?

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

ASCRUS
которые и появились ко всему прочему не так давно, можно сказать на всякий пожарный).

Ну так - он и наступил :)

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

Откуда: 127.0.0.1
Сообщений: 67463
Блог
Витал
Где-то с полгода назад в Инете читал статейку, где JOIN & WHERE проходили под таким соусом

Подозреваю, это было в лучшем случае верно для какого-либо конкретного сервера.

Если говорить про Oracle, то и оба утверждения безусловно не соответствует действительности, и я сильно подозреваю, что между этими вариантами вообще нет никакой разницы (то есть оптимизатор просто приводит один из них ко второму перед тем, как начинать вычислять план запроса).
22 ноя 05, 18:56    [2096640]     Ответить | Цитировать Сообщить модератору
 Re: Почему ораклисты так не любят MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
softwarer
Ладно, забьем. Я сильно плохо знаю Оракл, чтобы спорить, ты совсем не знаешь ASA

P.S. Кстати когда я просил пример, я совсем не имел ввиду WITH, в моем понимании - это "выкрутиться". Так что тогда уж вопрос в тему - с какой версии Oracle появилась поддержка CTE, мы вроде как 8-ку обсуждали без поддержки JOIN-ов, был там CTE ?
22 ноя 05, 19:25    [2096703]     Ответить | Цитировать Сообщить модератору
 Re: Почему ораклисты так не любят MS SQL?  [new]
ChA
Member

Откуда: Москва
Сообщений: 11380
Особенно эффектно выглядит FULL OUTER JOIN в старом стиле :) Но это так, лирическое отступление.

Основной смысл появления JOIN в ANSI-стандарте заключался в том, чтобы выделить операции слияния именно как операции с множествами, а не произведение всех на все с дальнейшем отсечением ненужного фильтрами. Грубая аналогия, можно цепочку математических операций писать как польскую обратную запись
ab+c*
, а можно классическим математическим
(a+b)*c
. JOIN-ы можно заключать в скобки, что позволяет легче формулировать требуемый конечный результат, хотя, конечно же, никто не мешает использовать и derived table.
В принципе, результат будет одинаков, но вторым способом человеку писать несколько легче, особенно, когда число отношений, участвующих в запросе растет самым неподобающим образом.

P.S. Опять же, нарисовал несколько пересекающихся кружков, как отношения, и легко написал в стиле JOIN-ов, как операций над множествами.
22 ноя 05, 19:26    [2096705]     Ответить | Цитировать Сообщить модератору
 Re: Почему ораклисты так не любят MS SQL?  [new]
AI
Member

Откуда: Москва
Сообщений: 2817
ChA
Особенно эффектно выглядит FULL OUTER JOIN в старом стиле :) Но это так, лирическое отступление.


FULL OUTER JOIN - просто синтаксическая конструкция для того, чтобы не писать два противоположных по смыслу запроса, связывая их через union. Во всяком случае, oracle строит именно такой план запроса.

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

2 softwarer

Может, не стОит продолжать бесить поклонников одной религии, утверждениями о том, что другая может то же самое и даже обещает больше чудес?
22 ноя 05, 21:20    [2096900]     Ответить | Цитировать Сообщить модератору
 Re: Почему ораклисты так не любят MS SQL?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
ASCRUS
P.S. Кстати когда я просил пример, я совсем не имел ввиду WITH, в моем понимании - это "выкрутиться".

Там можно и без WITH, просто с моей точки зрения так более читабельно, чем писать подзапрос во FROM.

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

-- Ваш вариант
SELECT * FROM a
LEFT JOIN (b INNER JOIN c ON c.b_id = b.b_id) ON b.a_id = a.a_id

-- Промежуточный вариант
SELECT * FROM a
LEFT JOIN (SELECT * FROM b, c WHERE c.b_id = b.b_id) d ON d.a_id = a.a_id

-- Мой вариант
SELECT * FROM a, (SELECT * FROM b, c WHERE c.b_id = b.b_id) d
WHERE a.a_id = d.a_id (+)

-- Он же с WITH
WITH d as (SELECT * FROM b, c WHERE c.b_id = b.b_id) 
SELECT * FROM a, d where a.a_id = d.a_id (+)

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

ASCRUS
Так что тогда уж вопрос в тему - с какой версии Oracle появилась поддержка CTE, мы вроде как 8-ку обсуждали без поддержки JOIN-ов, был там CTE ?

WITH в смысле CTE появился с 9.0.1. Что, впрочем, ничуть не мешало написать указанный мной запрос и в более ранних версиях (только, пожалуйста, не спрашивайте меня, с какой версии это было возможно - я не столько занимаюсь Oracle, чтобы знать ответ).
22 ноя 05, 22:03    [2096990]     Ответить | Цитировать Сообщить модератору
 Re: Почему ораклисты так не любят MS SQL?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
ASCRUS
Поэтому "подсказка" оптимизатору в запросах через порядок соединения JOIN или LATERAL .... можно мягко подтолкнуть оптимизатор в сторону правильного выбора планов, без какого либо навязывания хинтов

Кстати, пришел в голову такой вот вопрос: а как мне быть, если мне хочется записать JOIN-ы в некотором удобном мне порядке (соответствующем логической структуре запроса итп), но это мягко подталкивает оптимизатор в сторону неправильного выбора плана? С хинтом я по крайней мере свободен не писать его...
22 ноя 05, 22:12    [2097025]     Ответить | Цитировать Сообщить модератору
 Re: Почему ораклисты так не любят MS SQL?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
ChA
Основной смысл появления JOIN в ANSI-стандарте заключался в том, чтобы выделить операции слияния именно как операции с множествами, а не произведение всех на все с дальнейшем отсечением ненужного фильтрами.

То есть - отойти от декларативного смысла SQL, внешне, синтаксически приблизиться к алгебраической реализации. При этом это ложное ощущение, поскольку реальный план выполнения может оказаться совсем другим (как я говорил раньше, план, построенный для a join b join c может включать в себя как раз картезиан, примерно такой ( a * c ) join b.

ChA
Грубая аналогия, можно цепочку математических операций писать как польскую обратную запись
ab+c*
, а можно классическим математическим
(a+b)*c
.

Насколько я понимаю, вопрос этой аналогии в том, какой из способов соотнести какому из вариантов синтаксиса.

Если мы рассмотрим выражение a+b+c, его можно вычислить как

ab+c+
c++
ac+b+
bc+a+

и множеством других способов. Наоборот, имея один из

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

P.S. Опять же, нарисовал несколько пересекающихся кружков, как отношения, и легко написал в стиле JOIN-ов, как операций над множествами.[/quot]
22 ноя 05, 22:22    [2097051]     Ответить | Цитировать Сообщить модератору
 Re: Почему ораклисты так не любят MS SQL?  [new]
ChA
Member

Откуда: Москва
Сообщений: 11380
AI
FULL OUTER JOIN - просто синтаксическая конструкция для того, чтобы не писать два противоположных по смыслу запроса, связывая их через union. Во всяком случае, oracle строит именно такой план запроса.
Так все JOIN-ы - просто синтаксические конструкции, а как СУБД будет строить план запроса, абсолютно все равно, это его сугубо личное дело. Этот план может зависеть от чего угодно, но только не от синтаксиса, который дан лишь для того, чтобы нам проще было выражать свои мысли. SQL - декларативный язык, он не определяет алгоритм выполнения, он лишь описывает желаемый результат и JOIN-ы позволяют сделать этот процесс проще, всего-навсего.

P.S. Впрочем, можете считать, что в комитете ANSI сидят недоумки, которым заняться больше нечем, кроме как стандарты выпускать. Такое мнение тоже имеет право на существование.
P.P.S. В далекой молодости тоже не понимал, зачем нужны символьные наименования переменных, адреса переменных же и так известны.
22 ноя 05, 22:45    [2097081]     Ответить | Цитировать Сообщить модератору
 Re: Почему ораклисты так не любят MS SQL?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
Прошу прощения, похоже я нажал что-то не то и дописывал письмо уже после того, как оно было отправлено. Поэтому частично повторю ранее опубликованное.

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

То есть - отойти от декларативного смысла SQL, внешне, синтаксически приблизиться к алгебраической реализации. При этом это ложное ощущение, поскольку реальный план выполнения может оказаться совсем другим (как я говорил раньше, план, построенный для a join b join c может включать в себя как раз картезиан, примерно такой:
(a ∙ c) join b
.

ChA
Грубая аналогия, можно цепочку математических операций писать как польскую обратную запись
ab+c*
, а можно классическим математическим
(a+b)*c
.

Насколько я понимаю, вопрос этой аналогии в том, какой из способов соотнести какому из вариантов синтаксиса.

Если мы рассмотрим выражение a+b+c, его можно вычислить как

ab+c+
bca++
ac+b+
bc+a+

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

ChA
JOIN-ы можно заключать в скобки, что позволяет легче формулировать требуемый конечный результат, хотя, конечно же, никто не мешает использовать и derived table.

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

ChA
В принципе, результат будет одинаков, но вторым способом человеку писать несколько легче, особенно, когда число отношений, участвующих в запросе растет самым неподобающим образом.

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

ChA
P.S. Опять же, нарисовал несколько пересекающихся кружков, как отношения, и легко написал в стиле JOIN-ов, как операций над множествами.

Хм. А кто мешает столь же легко сделать это в стиле плюсиков?

P.S. С моей точки зрения Вы немного зря говорите об операциях со множествами - множества это все-таки UNION, INTERSECT, MINUS (не знаю их MSSQL аналогов, поэтому пишу так, как в Oracle), а JOIN совершенно не соответствует классическим операциям над множествами.
22 ноя 05, 22:53    [2097086]     Ответить | Цитировать Сообщить модератору
 Re: Почему ораклисты так не любят MS SQL?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
AI
Может, не стОит продолжать бесить поклонников одной религии, утверждениями о том, что другая может то же самое и даже обещает больше чудес?

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

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

Откуда: Киев
Сообщений: 40
С ORACLE работаю недолго, самоучка. Поправьте если что не так.

1. Почему в моей практике если оракл в плане запроса есть hash join то он почти всегда тормозит (на MSSQL hash join работает также быстро, как loop join по проиндексированной таблице). Спасает хинт USE_NL чтоб заставить его делать nested loops. Или хинт DYNAMIC_SAMPLING. После привода статистики 90 процентах случаев оракл начинает делать nested loops без подсказок, но все же бывают случай когда в плане запроса попадается hash join и сразу запрос очень тормозит.
Предположение: может что-то с настройками сервера в плане hash join не так, у кого такое встечалось?

2. Хинт DYNAMIC_SAMPLING вроде не когда в моей практике не замедлял запрос, запрос ставал работать быстее или так-же. Может его использовать как панацею? У кого-то DYNAMIC_SAMPLING влиял на скорость в худшую сторону?
23 ноя 05, 00:15    [2097162]     Ответить | Цитировать Сообщить модератору
 Re: Почему ораклисты так не любят MS SQL?  [new]
ChA
Member

Откуда: Москва
Сообщений: 11380
softwarer
То есть - отойти от декларативного смысла SQL, внешне, синтаксически приблизиться к алгебраической реализации. При этом это ложное ощущение, поскольку реальный план выполнения может оказаться совсем другим
Да нет тут никакого отхода, речь ведь и идет о реляционной алгебре. План же запроса играет только практическую роль, так как ЭВМ не умеют выполнять реляцонные операторы, кроме как раскладывая их на множество конкретных алгоритмических операций.

softwarer
Если мы рассмотрим выражение a+b+c, его можно вычислить как

ab+c+
bca++
ac+b+
bc+a+

и еще восемью другими способами. Наоборот, имея один из этих вариантов, мы имеем однозначное указание выполнять вычисление именно так (хотя, конечно, имеем право на эквивалентное преобразование, если оно нам нужно). Cоответственно, "свободный синтаксис" с соединениями в where имеет как минимум столько же оснований претендовать на ассоциацию с "классическим математическим", как и явный синтаксис join-ов.
C практической точки зрения, наверное, но с точки зрения ANSI, увы. В примере Вы рассматриваете тривиальный случай, когда используется только один вид операций, тогда как INNER, LEFT или FULL JOIN несколько различны и свободные перестановки операндов и операторов недопустимы, если только нам не наплевать на результат.

softwarer
первые два варианта, которые я сформулировал в письме к ASCRUS - боюсь, не вижу ни малейшего "легче"
Об этом уже упоминал выше, разумеется, можно воспользоваться derived table или view, это очевидно, но выглядит ли это проще, чем через JOIN не скажу. На данный момент - дело вкуса, кто как привык, тот так и пишет. В будущем, хотим мы этого или не хотим, но плюсики будут считаться анахронизмом. Вы же не думаете, что Oracle ввел JOIN только чтобы угодить комитету ANSI и на этом все закончится ? Возможно они еще долго будут для backward compatibility, но будущее их, IMHO, печально.

softwarer
С моей точки зрения Вы немного зря говорите об операциях со множествами - множества это все-таки UNION, INTERSECT, MINUS (не знаю их MSSQL аналогов, поэтому пишу так, как в Oracle), а JOIN совершенно не соответствует классическим операциям над множествами.
Мы ведь говорим не о "классических операциях над множествами", а об реляционной алгебре, в которую кроме UNION, INTERSECT, MINUS и декартова произведения входят, как минимум, специальные реляционные операции, введеные еще Коддом: выборка, проекция, соединение и деление. Не говоря уж о том, что ставить равенство между ANSI SQL и абстрактной теорией множеств наверное не стоит, по этому поводу лучше к авторитетам типа Дейта. Если Вы хотите обсудить эту тему, то лучше, пожалуй, в "Проектировании БД", там возможно найдется больше желающих обсудить ее, ибо здесь она офтоп для офтопа по исходной теме :)
23 ноя 05, 00:49    [2097216]     Ответить | Цитировать Сообщить модератору
 Re: Почему ораклисты так не любят MS SQL?  [new]
pkarklin
Member

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

Я не представляю уровень новичка, которому нужно было бы объяснять про прямое, левое и правое объединение более, чем их определение!!! Или этому новичку надо чем-нибудь другим заниматься. А вот "объяснение" с искажением сути происходящего, то есть с искажением того, что он увидит в плане выполнения запроса считаю в корне не правильным.


А если после "a join b join c" в плане выполнения стоит порядок связки "a-c-b"? Вот тут-то новички (у меня на курсе сейчас как раз такие сидят) и "приплывают". Им абсолютно непонятно, почему при, казалось бы, заданном явно порядке связок сервер работает совсем по-другому...


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

AI
В этом смысле связки в where более отражают суть происходящего на сервере. Кстати, в случае star optimization oracle делает из кучи таблиц-справочников декартово соединение, накладывает на него where и только потом полученный результат связывает с оставшейся таблицей фактов. Я уж не говорю о системе query rewrite или star transformation, которые вообще изменяют исходный запрос на более оптимальный.


Суть происходящего на сервер может отражать только план выполнения запроса, а не расположение выражений в исходном тексте запроса, вне зависимости, где они находятся в WHERE или во FROM. IMHO
23 ноя 05, 08:15    [2097414]     Ответить | Цитировать Сообщить модератору
 Re: Почему ораклисты так не любят MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
softwarer
-- Мой вариант
SELECT * FROM a, (SELECT * FROM b, c WHERE c.b_id = b.b_id) d
WHERE a.a_id = d.a_id (+)

Согласен, так нормально. Текста чуть больше, смысл на уровне плана запроса тот же.

softwarer
Кстати, пришел в голову такой вот вопрос: а как мне быть, если мне хочется записать JOIN-ы в некотором удобном мне порядке (соответствующем логической структуре запроса итп), но это мягко подталкивает оптимизатор в сторону неправильного выбора плана? С хинтом я по крайней мере свободен не писать его...

Для ASA раньше 8-ки, где не было хинтов и оптимизатор действительно мог "подталкиваться" в зависимости от использования различных методов соединения в запросах, то пришлось бы "писать" правильно. В 9-ке же помимо хинтов (которые правда мне пока ни разу не пригодились, конечно не считая хинтов на уровени изоляции), оптимизатор здорово поумнел и особо задумываться о правильном и красивом написании сложного запроса не приходится - все равно оптимизатор его перекроит, как ему удобно. Однажды я помню минут 20 потратил, чтобы написать один очень хитрый и большой запрос, с кучей подзапросов, аггрегаций и использованием OLAP-функций. Причем хотелось написать более менее правильно и красиво, однако это сделать не сильно удалось, запрос все равно казался громоздким и внушительным. Самое забавное, что когда я прогнал его через Rewrite (спец функция ASA, перестраивающая запрос так, как его бы хотел видеть оптимизатор, т.е. с оптимизацией булевых выражений, соединений таблиц и прочего), чтобы посмотреть, как бы его переписала ASA, то как раз увидел то самое, что пытался сам написать. С тех пор помня об этом случае, я стараюсь не думать за оптимизатор и не подгонять ему правильные запросы, пускай сам думает и пытаюсь оптимизировать запрос, только когда он реально тормозит и строится неправильный план (за последний время правда не помню такого).
23 ноя 05, 08:53    [2097501]     Ответить | Цитировать Сообщить модератору
 Re: Почему ораклисты так не любят MS SQL?  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
softwarer
pkarklin
Эээ... Не вижу недостатка ни в использовании inline view


Не кажется ли Вам, что Ваша формулировка решительно не соответствует сказанному мной и в свете этого может быть квалифицирована как игра слов, создающая превратную картину?


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

Витеевато, получатеся, неправдали?! Ваша "школа"! :)

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


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

softwarer
Судя по дальнейшему тону, Вы вошли в агрессивный режим,


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

softwarer
Представьте себе, гипотетически, что Oracle поддерживает join-синтаксис только для inner join-ов. Представьте себе, что на основании этого я говорю что-нибудь типа "не представляю себе, как в этом синтаксисе написать outer join".

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


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

softwarer

/*1*/ a.id (+) = 1 and
/*2*/ a.id (+) = b.id

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


И это подверждает вышесказанное мной. Я понимаю, что приведенные Вами выражения объединения в "старом" стиле с точки зрения здравой логики ничем не отличаются. Но то, что детали реализации MS SQL не позволяют выполнить второе в "старом" стиле, а Oracle может, я, опять же повторюсь, не могу отнести к недостаткам реализации. Я бы назвал это как отличия в деталях реализации. То, что, практику Oracle это кажется неудобным и странным, совсем не означает, что MS SQL в этом смысле "нелогичен" и это его "недостаток". С таким же успехом можно считать различия в деталях реализации ООП в Pascal и C++, как недостатки Pascal. Но это не более чем детали реализации, т.е. by design. И приписывать мне идолопоклонстов к MS SQL по крайней мере некорректно. По крайне мере я стараюсь не преподносить отличия в деталях реализации MS SQL от других СУБД, как недостатки последних.

Надеюсь, Вы не сочтете мои высказывание на этот раз как "игру слов"?!

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


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

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

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


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

softwarer
Тогда удивительно, что Вы вообще не набрасываетесь на идею преподавания. Зачем что-то объяснять, когда талантливый и сам разберется, а прочих - в дворники?


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

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


Как Вам будет угодно. С уважением, pkarklin.
23 ноя 05, 09:12    [2097541]     Ответить | Цитировать Сообщить модератору
 Re: Почему ораклисты так не любят MS SQL?  [new]
aZm
Member

Откуда:
Сообщений: 2357
mal_ora
С ORACLE работаю недолго, самоучка. Поправьте если что не так.

1. Почему в моей практике если оракл в плане запроса есть hash join то он почти всегда тормозит (на MSSQL hash join работает также быстро, как loop join по проиндексированной таблице). Спасает хинт USE_NL чтоб заставить его делать nested loops. Или хинт DYNAMIC_SAMPLING. После привода статистики 90 процентах случаев оракл начинает делать nested loops без подсказок, но все же бывают случай когда в плане запроса попадается hash join и сразу запрос очень тормозит.
Предположение: может что-то с настройками сервера в плане hash join не так, у кого такое встечалось?

2. Хинт DYNAMIC_SAMPLING вроде не когда в моей практике не замедлял запрос, запрос ставал работать быстее или так-же. Может его использовать как панацею? У кого-то DYNAMIC_SAMPLING влиял на скорость в худшую сторону?


вам и правда разобраться нужно или цель - показать, как фигово работает оракл :)?

если хотите разобраться - читайте про CBO. CBO, вообще говоря, ориентируется по статистике. и если статистика, собранная для базы, не актуальна - у CBO "поедет крыша".

зы:
вообще говоря, такие вопросы луше бы задавать на форуме по ораклу
зыы2.
вообще говоря - nested loops не панацея :) зависит от многих моментов, хотя бы от того, сколько записей в связываемых табличках.
23 ноя 05, 09:30    [2097605]     Ответить | Цитировать Сообщить модератору
 Re: Почему ораклисты так не любят MS SQL?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
mal_ora
Предположение: может что-то с настройками сервера в плане hash join не так, у кого такое встечалось?

Если поработать телепатом, можно предположить, что не используется параметр PGA_AGGREGATE_TARGET, а параметр HASH_AREA_SIZE задвинут ниже плинтуса. Но если хотите решить проблему, с этим действительно в документацию и соответствующий форум.

mal_ora
2. Хинт DYNAMIC_SAMPLING вроде не когда в моей практике не замедлял запрос, запрос ставал работать быстее или так-же. Может его использовать как панацею? У кого-то DYNAMIC_SAMPLING влиял на скорость в худшую сторону?

Этот хинт является панацеей в случае плохо собираемой статистики. При идеально собранной статистике я бы счел его фактором торможения.
23 ноя 05, 11:29    [2098264]     Ответить | Цитировать Сообщить модератору
 Re: Почему ораклисты так не любят MS SQL?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
ChA
Да нет тут никакого отхода, речь ведь и идет о реляционной алгебре.

Предлагаю зафиксировать здесь расхождение на уровне интуитивного, неформализуемого понимания "отхода-неотхода".

softwarer
Если мы рассмотрим выражение a+b+c, его можно вычислить как ....
ChA
C практической точки зрения, наверное, но с точки зрения ANSI, увы. В примере Вы рассматриваете тривиальный случай, когда используется только один вид операций,

Исключительно чтобы не усложнять пример. Но если настаиваете - выражение a*b+c*d может быть вычислено как

ab*cd*+
cd*ab*+
....

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

ChA
На данный момент - дело вкуса, кто как привык, тот так и пишет.

Собственно, этой формулировки я и хотел достичь.

ChA
В будущем, хотим мы этого или не хотим, но плюсики будут считаться анахронизмом. Вы же не думаете, что Oracle ввел JOIN только чтобы угодить комитету ANSI и на этом все закончится ? Возможно они еще долго будут для backward compatibility, но будущее их, IMHO, печально.

Я не знаю, для чего Oracle ввел join-ы (для чего на самом деле, а не "официально"). Я так подозреваю, что разработка стандарта - дело, безусловно, нужное - является большой политикой, в рамках которой идет торговля типа "ну, введем мы джойны, тогда вы не обращайте внимания на погрешности нашего serializable, тогда мы не будем фокусировать внимание на вашем неправильном unique, если конечно вы согласитесь с нашими строками...."

Вводя join-ы, Oracle вольно или невольно сделал некоторые глупости, например реализовал замечательную в своем идиотизме конструкцию NATURAL JOIN. Это, согласитесь, совершенно не повод пользоваться ей.

Говорить о столь далеком будущем, в котором может быть не будет плюсиков я большого смысла не вижу. Даже если так будет - это не повод отказываться от хорошего инструмента уже сейчас. Может быть, к тому времени join-ы станут настолько хороши, что плюсики отомрут естественным образом, говоря же про "сейчас" - если не ошибаюсь, объективной разницы мы пока не нашли, вопрос синтаксического удобства.
23 ноя 05, 11:56    [2098484]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 10 11 12 13 14 15 16 [17] 18 19   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить