|
Кто как ответил бы на данный вопрос и почему ?
|
|||
---|---|---|---|
#18+
Какой из приведенных вариантов ответов является по вашему мнению верным для следующего вопроса : What is true about non-equijoin statement performance ? A) The BETWEEN condition always performs less well than using the >= and <= conditions. B) The join syntax used makes no difference to performance. C) Table aliases can improve performance. D) The BETWEEN condition always performs better than using the >= and <= conditions. E) The Oracle join syntax performs better than the SQL:1999 compliant ANSI join syntax. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.02.2020, 07:44 |
|
Кто как ответил бы на данный вопрос и почему ?
|
|||
---|---|---|---|
#18+
adm2706, Ни одного верного. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.02.2020, 08:57 |
|
Кто как ответил бы на данный вопрос и почему ?
|
|||
---|---|---|---|
#18+
Тем не менее, один из этих ответов считается верным в корпорации Oracle. Интересно, какой из них это может быть ? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.02.2020, 11:03 |
|
Кто как ответил бы на данный вопрос и почему ?
|
|||
---|---|---|---|
#18+
adm2706 Тем не менее, один из этих ответов считается верным в корпорации Oracle. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.02.2020, 11:43 |
|
Кто как ответил бы на данный вопрос и почему ?
|
|||
---|---|---|---|
#18+
adm2706 Тем не менее, один из этих ответов считается верным в корпорации Oracle. Интересно, какой из них это может быть ? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.02.2020, 12:45 |
|
Кто как ответил бы на данный вопрос и почему ?
|
|||
---|---|---|---|
#18+
А что не так с ответом B ? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.02.2020, 13:17 |
|
Кто как ответил бы на данный вопрос и почему ?
|
|||
---|---|---|---|
#18+
The join syntax used makes no difference to performance. а использование джоин синтаксиса разве даёт какие-то преимущества? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.02.2020, 14:20 |
|
Кто как ответил бы на данный вопрос и почему ?
|
|||
---|---|---|---|
#18+
feagor, Речь о различных вариантах записи одного и того же условия non-equijoin, в общем случае ответ B верен. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.02.2020, 14:47 |
|
Кто как ответил бы на данный вопрос и почему ?
|
|||
---|---|---|---|
#18+
miksoft А что не так с ответом B ? модальность высказывания. Если не знаешь, что там под капотом, в такого рода случаях выбирай по модальности. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.02.2020, 14:47 |
|
Кто как ответил бы на данный вопрос и почему ?
|
|||
---|---|---|---|
#18+
feagor The join syntax used makes no difference to performance. а использование джоин синтаксиса разве даёт какие-то преимущества? точный перевод: Использование JOIN-ов не влияет на производительность. А он влияет. Особенно LEFT/RIGHT JOIN. Но и JOIN конечно тоже повлияет, искать то надо. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.02.2020, 16:32 |
|
Кто как ответил бы на данный вопрос и почему ?
|
|||
---|---|---|---|
#18+
полудух точный перевод: Использование JOIN-ов не влияет на производительность. перевод неверный. feagor а использование джоин синтаксиса разве даёт какие-то преимущества? в теории ANSI join и Oracle join (вероятно, речь идет о них) должны давать одинаковые результаты и производительность. на практике бывает по-разному, но в контексте теоретического вопроса это не должно иметь значения. я бы выбрал "B". ... |
|||
:
Нравится:
Не нравится:
|
|||
09.02.2020, 16:56 |
|
Кто как ответил бы на данный вопрос и почему ?
|
|||
---|---|---|---|
#18+
кит северных морей перевод неверный. сказал А, говори и Б. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.02.2020, 17:15 |
|
Кто как ответил бы на данный вопрос и почему ?
|
|||
---|---|---|---|
#18+
полудух кит северных морей перевод неверный. сказал А, говори и Б. The join syntax used makes no difference to performance. "Используемый синтаксис join не влияет на производительность" join syntax - это oracle join vs ansi join. inner/left/right/full - это join type. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.02.2020, 17:21 |
|
Кто как ответил бы на данный вопрос и почему ?
|
|||
---|---|---|---|
#18+
а, ещё одна особенность оракла спасибо ... |
|||
:
Нравится:
Не нравится:
|
|||
09.02.2020, 18:43 |
|
Кто как ответил бы на данный вопрос и почему ?
|
|||
---|---|---|---|
#18+
полудух точный перевод: Использование JOIN-ов не влияет на производительность. А он влияет. Особенно LEFT/RIGHT JOIN. Но и JOIN конечно тоже повлияет, искать то надо. Нет, речь идет о non-equijoin . кит северных морей в теории ANSI join и Oracle join (вероятно, речь идет о них) должны давать одинаковые результаты и производительность. на практике бывает по-разному, но в контексте теоретического вопроса это не должно иметь значения. Нет, non-equijoin - соединение при котором условие соединения представляет собой неравенство, в вопросах не случайно фигурирует between и то на что его можно заменить, смысл вопроса в том, что если условия эквивалентны между собой, то нет разницы в плане производительности посредством каких операторов ты опишешь условие. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.02.2020, 18:52 |
|
Кто как ответил бы на данный вопрос и почему ?
|
|||
---|---|---|---|
#18+
Автор допроса хотел спросить про трансформацию, так и нужно было спрашивать про план, не "производительность". Преобразование between и ansi-join кое-что, да стоит. Кстати, на восьмерке запрос с ansi-join завершался быстрее. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.02.2020, 22:04 |
|
Кто как ответил бы на данный вопрос и почему ?
|
|||
---|---|---|---|
#18+
Синтаксис на производительность никак непосредственно не влияет, влияет план выполнения, который может оказаться другим, в том числе и из-за синтаксиса. Если план двух эквивалентных запросов, написанных с использованием различного синтаксиса, отличается, и влечёт изменение производительности, то это следует рассматривать как дефект. Таким образом в этом случае производительность зависит от дефекта, а не от синтаксиса как такового. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.02.2020, 23:45 |
|
Кто как ответил бы на данный вопрос и почему ?
|
|||
---|---|---|---|
#18+
_Nikotin Синтаксис на производительность никак непосредственно не влияет, влияет план выполнения, который может оказаться другим, в том числе и из-за синтаксиса. Если план двух эквивалентных запросов, написанных с использованием различного синтаксиса, отличается, и влечёт изменение производительности, то это следует рассматривать как дефект. Таким образом в этом случае производительность зависит от дефекта, а не от синтаксиса как такового. ANSI позволяет не заморачиваться с использованием inline views и лепить всё в кляузу from. Но в результате может быть создан ряд lateral views под капотом. Которые подразуевают NL соединение а не HJ. Oracle native же принуждает создавать inline views особенно на древних версиях чтоб обойти "a table may be outer joined to at most one other" и прочие ограничения. Это исключает создание lateral views под капотом и оставляет больше возможностей для методов соединения. Можно ли было реализовать преобразование ANSI -> native, чтоб не создавались lateral views? Пожалуй да. Руками то всегда можно переписать без оных. Но что-то помешало это сделать. Соответственно запросо-писатель выбирает: либо он всё контролирует по максимуму либо использует синтаксиеский сахарок и не парится. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.02.2020, 00:58 |
|
Кто как ответил бы на данный вопрос и почему ?
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
11.02.2020, 01:37 |
|
Кто как ответил бы на данный вопрос и почему ?
|
|||
---|---|---|---|
#18+
Кобанчег скорее oracle native это просто чуть более "низкоуровневый" синтаксис. Вот если если есть пример плана, котоый легко получается через native, но при этом существует эквивалентный ansi запрос, где не удаётся получить подобный план, я бы создал тикет и посмотрел что ответят, заодно бы сослася на документацию. Либо в ней баг, либо в оптимизаторе. У меня бы подобный опыт с google поддержкой, где документация расходилась с практикой, в итоге сперва поддержка отрапортовала про баг в документации, а потом через неделю разработчики отрапортовали что баг исправлен. В этом плане Оракл впереди планеты по качеству и логичности документации. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.02.2020, 20:34 |
|
Кто как ответил бы на данный вопрос и почему ?
|
|||
---|---|---|---|
#18+
_Nikotin Вот если если есть пример плана, котоый легко получается через native, но при этом существует эквивалентный ansi запрос, где не удаётся получить подобный план, я бы создал тикет и посмотрел что ответят, заодно бы сослася на документацию. Либо в ней баг, либо в оптимизаторе. 1. Как уже было сказано ANSI может создавать кучу [латеральных] вьюх под капотом в результате чего треяется контроль над планом по причине того, что query block уже не тот. 13757575 2. В нативном больше требований к предикатам, и если предикат для ансишного привести а нативную форму, то трансформированный запрос чудесным образом меняется. Код: plsql 1. 2. 3.
Код: plsql 1. 2. 3. 4.
Преобразуется в Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Если переписать влоб для native, то получим Код: plsql 1. 2. 3. 4. 5. 6. 7. 8.
Это можно обойти если завернуть условие соединения с t3 в case, например. Код: plsql 1. 2. 3. 4.
Но теперь если мы так же перепишем ANSI запрос Код: plsql 1. 2. 3. 4. 5.
То после преобразования латеральная inline view не появится. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
Соединение с t3 можно было бы изобразить и в виде Код: plsql 1.
Подобная форма для ANSI тоже бы позволила избежать создания inline view. Но кто будет для ANSI применять case/decode трюки, если можно просто указать Код: plsql 1.
Соответственно при использовании предиката неприменимого в native (при внешнем соединении) мы не можем добиться плана как в native из-за создания lateral view. Это баг? Я планы специально не приводил, думаю мысль и так ясна. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2020, 17:55 |
|
Кто как ответил бы на данный вопрос и почему ?
|
|||
---|---|---|---|
#18+
iOracleDev Нет, non-equijoin - соединение при котором условие соединения представляет собой неравенство... non-equijoin - это соединение, при котором условие соединения не является равенством или non-equijoin - это соединение, которое выполняется не по условию равенства ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2020, 20:13 |
|
Кто как ответил бы на данный вопрос и почему ?
|
|||
---|---|---|---|
#18+
Кобанчег Я бы не рассматривал это как дефект, скорее oracle native это просто чуть более "низкоуровневый" синтаксис. Ну он более "низкоуровневый" лишь по историческим причинам: 1. Oracle native синтаксис банально старее ANSI 2. Очевидно, что старый клиентский код надо было поддерживать, и полностью переписывать парсеры на ANSI синтаксис - выходит опасно и дорого. //но я несколько раз от разных людей слышал, что самих разработчиков оракл бесит эта устаревшая необходимость и они, с удовольствием бы перешли только на ANSI Но ANSI синтаксис развивался/вается быстрее, например, в оракловом синтаксисе FULL OUTER JOIN и PARTITION JOIN не появились, а были добавлены так как они есть в ANSI. И благодаря тому, что в ANSI появились LATERAL, CROSS APPLY, и тд, наконец-то и нам разрешили древний lateral(). В итоге, имеем помесь бульдога с носорогом. Т.е фактически оракловый синтаксис это лишь исторические "костыли" и проблемы трансформации одного к другому - это именно ошибки. Кобанчег lateral views под капотом. Которые подразуевают NL соединение а не HJ. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2020, 21:04 |
|
Кто как ответил бы на данный вопрос и почему ?
|
|||
---|---|---|---|
#18+
SQL*Plus Нет. non-equijoin - это соединение, при котором условие соединения не является равенством или non-equijoin - это соединение, которое выполняется не по условию равенства Хотелось бы увидеть примеры условий соединений которые Oracle относит к non-equijoin и не приводимых Oracle к обычным неравенствам. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.02.2020, 15:42 |
|
Кто как ответил бы на данный вопрос и почему ?
|
|||
---|---|---|---|
#18+
xtender Я совсем недавно как раз жаловался что lateral c rownum декоррелируется когда совсем не надо и приводит к неправильным результатам, в ответ на что от оракла получил что rownum not deterministic Что там было? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.02.2020, 16:54 |
|
|
start [/forum/topic.php?fid=52&msg=39926446&tid=1881546]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
43ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
70ms |
get tp. blocked users: |
1ms |
others: | 17ms |
total: | 176ms |
0 / 0 |