Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
ON vs WHERE
|
|||
|---|---|---|---|
|
#18+
Всю жизнь считал, что чем больше условий в join'е - тем лучче Так сказать целевая выборка уменьшается уже на этапе объединения таблиц. Т.е.: если дополнительные условия перенести из ON в WHERE, то объединение будет строиться дольше и получиться, соотвтетственно, больше. Но вот по жизни... Вот кусок SP: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. По идее Код: plaintext 1. 2. 3. 4. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. _________________ "Helo, word!" - 17 errors 56 warnings ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2006, 09:42 |
|
||
|
ON vs WHERE
|
|||
|---|---|---|---|
|
#18+
Да у тебя запросы по результату будут совсем неэквивалентными! Они у тебя вернут совершенно разные наборы данных :) А вообще, когда речь заходит об оптимизации, то для начала хотя бы на планы смотрят, чтобы понять что и как пытается сделать сервер... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2006, 09:55 |
|
||
|
ON vs WHERE
|
|||
|---|---|---|---|
|
#18+
Во внешних соединениях меняется роль предикатов и их область действия, в зависимости от того, где они указаны - в ON-clause или в WHERE-clause. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2006, 09:58 |
|
||
|
ON vs WHERE
|
|||
|---|---|---|---|
|
#18+
Насчет left outer - sorry... Там там действительно выборки будут совершенно разные. Точнее - NULL'ы. Целевая таблица как была так и останеться. Речь шла о просто JOIN'е... _________________ "Helo, word!" - 17 errors 56 warnings ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2006, 10:03 |
|
||
|
ON vs WHERE
|
|||
|---|---|---|---|
|
#18+
Указание предикатов в ON или в WHERE меняет суть самого предиката. В ON - предикат является пре-джойн/джойн предикатом и представляет собой либо пре-фильтр НА ТАБЛИЦУ до объединения, либо условие объединения таблиц. В WHERE - предикат является пост-джойн предикатом, по сути - фильтром на РЕЗУЛЬТАТ соединения. То, как сервер проинтерпретирует и соптимизирует эти предикаты - это уже отдельная тема для разбирательства. ТУт нужно-таки смотреть на план выполнения запроса... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2006, 10:19 |
|
||
|
ON vs WHERE
|
|||
|---|---|---|---|
|
#18+
Бабичев Сергей То, как сервер проинтерпретирует и соптимизирует эти предикаты - это уже отдельная тема для разбирательства. ТУт нужно-таки смотреть на план выполнения запроса... Тут вопрос, так сказать, чисто теоретический, а-ля из области общих знаний Отречемся от оптимизаторов, планов - оставим это на совести разработчиков. SQL2(92) рекомендует для объеденения таблиц юзать join'ы, а не where, педалируя, опять же-таки, на ту же оптимизацию. Мало того, даже изменяя порядок следования join'ов, можно, типа, как раз и управлять этой оптимизацией. Согласен, что это касается объединений, так сказать, естественных. Но нигде же не запрещается вносить дополнительные условия в join, ограничивая выборку. По идее (ессесно, никто так в самом деле не делает, разве шо тока студенты, изучая реляционную алгебру), что в случае с естественными соединениями, что в случае с дополнительными условиями, строиться декартово произведение и потом просто тупо отбрасываются записи невыполняющие условие on. Меня просто поразил сам факт того, что Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. а Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. BTW, select @@version Adaptive Server Enterprise/12.5.1/EBF 11428/P/NT (IX86)/OS 4.0/ase1251/1823/32-bit/OPT/Wed Sep 17 11:10:54 2003 BTW2, нуна проверить на FB - интересно как он себя покажет... Получается, что внесение дополнительных услових, не касающихся объединения, в join - моветон? _________________ "Helo, word!" - 17 errors 56 warnings ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2006, 11:52 |
|
||
|
ON vs WHERE
|
|||
|---|---|---|---|
|
#18+
В догонку Если Бабичев Сергей В ON - предикат является пре-джойн/джойн предикатом и представляет собой либо пре-фильтр НА ТАБЛИЦУ до объединения , либо условие объединения таблиц. то, получается, внесение доп условий должно наоборот все улучшить, а не отправлять в down _________________ "Helo, word!" - 17 errors 56 warnings ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2006, 12:03 |
|
||
|
ON vs WHERE
|
|||
|---|---|---|---|
|
#18+
Ex_Soft Тут вопрос, так сказать, чисто теоретический, а-ля из области общих знаний Отречемся от оптимизаторов, планов - оставим это на совести разработчиков. Вот как раз с точки зрения теории - это всё монопинесуально. В теории всё делается, как ты и писал - строится декартово произведение множеств и лишь затем накладываются условия на результат объединения. На практике же дела обстоят совсем по другому... И если есть реальное желание разобраться с причинами неадекватного изменения времени выполнения запроса при изменении нотации его записи, то обсуждение должно строиться строго в привязке к конкретной среде исполнения запроса, в целом, и к оптимизатору, в частности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2006, 12:12 |
|
||
|
ON vs WHERE
|
|||
|---|---|---|---|
|
#18+
Ex_SoftВ догонку Если Бабичев Сергей В ON - предикат является пре-джойн/джойн предикатом и представляет собой либо пре-фильтр НА ТАБЛИЦУ до объединения , либо условие объединения таблиц. то, получается, внесение доп условий должно наоборот все улучшить, а не отправлять в down _________________ "Helo, word!" - 17 errors 56 warningsНе обязательно. Изменив условия запроса, можно было ввести оптимизатор в "заблуждение", повлекшее за собой построение "кривого" плана. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2006, 12:14 |
|
||
|
ON vs WHERE
|
|||
|---|---|---|---|
|
#18+
авторНа практике же дела обстоят совсем по другому... И если есть реальное желание разобраться с причинами неадекватного изменения времени выполнения запроса при изменении нотации его записи, то обсуждение должно строиться строго в привязке к конкретной среде исполнения запроса, в целом, и к оптимизатору, в частности. К примеру почему оставил в Код: plaintext 1. Какая у этого фильтра селективность? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2006, 14:08 |
|
||
|
ON vs WHERE
|
|||
|---|---|---|---|
|
#18+
Volokola К примеру почему оставил в Код: plaintext 1. 2. ну... потому что вообще запрос в общем виде выглядит так Код: plaintext 1. 2. 3. 4. 5. 6. _________________ "Helo, word!" - 17 errors 56 warnings ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2006, 16:16 |
|
||
|
ON vs WHERE
|
|||
|---|---|---|---|
|
#18+
В большинстве СУБД использование JOIN ... ON <join condition> или WHERE <join condition> отличается главным образом синтаксически. Ни один оптимизатор для варианта where <join condition> наверное не умудрится сначала построить полное декартово произведение таблиц, а потом из него фильтровать лишнее (хотя с логической точки зрения такая запись обозначает именно это). Подчас оптимизаторы даже подзапросы легко конвертируют в более эффективные JOIN'ы, там где это возможно. Основная логика внесения JOIN'ов в стандарты была связана с логическим разделением фильтров и соединений, которые до этого "в кучу" записывались в WHERE. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2006, 01:00 |
|
||
|
|

start [/forum/topic.php?fid=55&msg=34166656&tid=2012387]: |
0ms |
get settings: |
10ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
65ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
61ms |
get tp. blocked users: |
2ms |
| others: | 258ms |
| total: | 439ms |

| 0 / 0 |
