|
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
|
|||
---|---|---|---|
#18+
Прекрасно работающий запрос в 2.1 - 2.5: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.
если не использовать алиас - hh.code srv, а обращаться по имени колонки "code" ошибка также сохраниться если написать Код: plaintext
Код: plaintext
Код: plaintext
По поводу "странности" запроса камни не бросайте - всю математику я из него выбросил, чтобы понять в чем косяк - вложенность необходима (также как и вложенный left join) ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2019, 00:41 |
|
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
|
|||
---|---|---|---|
#18+
У тебя два алиаса h. Очевидно, подцепляется неправильный. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2019, 01:36 |
|
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
|
|||
---|---|---|---|
#18+
Игорь-PicoMed, в условии джойна cn и cd не может быть полей из других таблиц. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2019, 02:07 |
|
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
|
|||
---|---|---|---|
#18+
hvladИгорь-PicoMed, в условии джойна cn и cd не может быть полей из других таблиц. Почему ??? По стандарту SQL это возможно ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2019, 11:48 |
|
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovУ тебя два алиаса h. Очевидно, подцепляется неправильный. замена второго алиаса на H1 не помогает, тем более что по полям второй алиас включает в себя поля первого Главный момент - в FB 2.** работает ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2019, 11:53 |
|
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
|
|||
---|---|---|---|
#18+
Игорь-PicoMedПо стандарту SQL это возможно подтвердить можешь? Игорь-PicoMedГлавный момент - в FB 2.** работает там много какой херни типа работает :-) Собственно, это побочный эффект от CORE-2812. Вроде бы кто-то (камрад Коваленко?) уже писал про неработающие вложенные джойны-этажерки с подобными ссылками. Вот только не помню, нашел ли я доказательства в стандарте или просто забил... ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2019, 12:07 |
|
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
|
|||
---|---|---|---|
#18+
К слову, если переписать по-человечески: Код: sql 1. 2. 3. 4. 5. 6.
так работает или нет? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2019, 12:11 |
|
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
|
|||
---|---|---|---|
#18+
Игорь-PicoMed, по стандарту on должен быть сразу после join table, а не через один уровень. И кстати в RN 3.0 про это говорится ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2019, 12:23 |
|
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
|
|||
---|---|---|---|
#18+
Симонов Дениспо стандарту on должен быть сразу после join table, а не через один уровень тут ты не прав, стандарт такое тоже позволяет Все дело в том, что если правильно раскрыть синтаксис JOIN ... ON, то Код: sql 1. 2. 3. 4. 5.
превращается в Код: sql 1. 2. 3. 4. 5. 6. 7.
где Код: sql 1.
по сути неявная derived table, в которой само собой (по стандарту) запрещены ссылки наружу подзапроса, т.е. на h в данном случае ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2019, 12:47 |
|
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
|
|||
---|---|---|---|
#18+
dimitrИгорь-PicoMedПо стандарту SQL это возможно подтвердить можешь? Спецификация SQL-92: Код: plaintext 1. 2. 3. 4.
dimitrИгорь-PicoMedГлавный момент - в FB 2.** работает там много какой херни типа работает :-) В данном случае эта "хрень" также работает в Оракле и postgresql dimitrВот только не помню, нашел ли я доказательства в стандарте или просто забил... Симонов Денис по стандарту on должен быть сразу после join table, а не через один уровень. И кстати в RN 3.0 про это говорится На прямую в стандарте действительно так написано: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
однако в той же спецификации см: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.
... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2019, 13:17 |
|
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
|
|||
---|---|---|---|
#18+
dimitrК слову, если переписать по-человечески: Код: sql 1. 2. 3. 4. 5. 6.
так работает или нет? в таком варианте работает, но будет ли это корректно с точки зрения оптимизатора? dimitrпо сути неявная derived table, в которой само собой (по стандарту) запрещены ссылки наружу подзапроса, т.е. на h в данном случае Так оно по сути и должно быть с точки зрения логики построения запроса - в данном случае перемножение h*cd гораздо больше чем cn*cd, и см. письмо выше, стандарт разрешает внешние ссылкы в данных запросах ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2019, 13:23 |
|
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
|
|||
---|---|---|---|
#18+
Игорь-PicoMed, может оно и позволяется стандартом, но лично меня от таких запросов коробит и начинает дёргаться глаз ибо запрос становится не читаемым и трудно понимаемым. Привык в on видеть ясные и понятные условия того что соединяется, а не вообще любые. А то что вы написали практически превращает JOIN в LATERAL JOIN, которые всё равно пока не работают. Да и левые джойны пока что не дают оптимизатору никакого пространства, нету выполнения разными алгоритмами (только NESTED LOOP разве что с индексами поиграться), порядок соединения всё равно задан жёстко. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2019, 13:47 |
|
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
|
|||
---|---|---|---|
#18+
Симонов ДенисИгорь-PicoMed, может оно и позволяется стандартом, но лично меня от таких запросов коробит и начинает дёргаться глаз ибо запрос становится не читаемым и трудно понимаемым. Если бы вы видели запрос целиком, то не только бы глаз начал дергаться - меня он и бесит и коробит, но альтернатива - использование GTT и selectable процедур, что не есть гуд, так как заведомо не совместимо с другими SQL базами, да и работает медленнее. Симонов ДенисА то что вы написали практически превращает JOIN в LATERAL JOIN, которые всё равно пока не работают. Да и левые джойны пока что не дают оптимизатору никакого пространства... порядок соединения всё равно задан жёстко. и тут согласен - приходится самому включать мозг определяя порядок соединения исходя из объемов объединяемых таблиц. Но какая альтернатива? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2019, 13:54 |
|
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
|
|||
---|---|---|---|
#18+
Игорь-PicoMedстандарт разрешает внешние ссылкы в данных запросах Внешние ссылки требуют внешних соединений. Иначе при рекомбинации таблиц ссылка может внезапно стать внутренней. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2019, 14:05 |
|
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
|
|||
---|---|---|---|
#18+
Симонов Денислично меня от таких запросов коробит и начинает дёргаться глаз ибо запрос а сравнения столбцов с константами в условии объединения таблиц? h.srv <> 0, cd.type >= 0 ... Это уже почти глаз на ж. Это же не условия объединения, это "фильтрация", им место в where. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2019, 19:48 |
|
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
|
|||
---|---|---|---|
#18+
kdv, да не, как раз с left join это уже условие соединение, вынос в where изменит результат. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2019, 20:04 |
|
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
|
|||
---|---|---|---|
#18+
kdv, КМК, у тебя "глаз на ж" уже точно замылился, ведь в случае несимметрижных объединений это будет кардинально другой запрос.)) ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2019, 20:07 |
|
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
|
|||
---|---|---|---|
#18+
kdvЭто уже почти глаз на ж. Это же не условия объединения, это "фильтрация", им место в where.Симонов Денисда не, как раз с left join это уже условие соединение, вынос в where изменит результат. Мало того, что полно ситуаций, когда по-другому нельзя, соответственно, утверждать, что вот здесь надо в условие соединения, а вообще обязательно в "где" - это слегка раздвоение. Даже если внутренним соединением соедините пару десятков таблиц, посмотрю я на ваш глаз, где условия фильтрации для присоединяемых будут во WHERE, а не аккуратно и очевидно в условии соединения. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.02.2019, 09:09 |
|
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
|
|||
---|---|---|---|
#18+
Дошли тут руки покопаться немного. Игорь-PicoMedВ данном случае эта "хрень" также работает в Оракле и postgresql оракла под рукой нет, увы. Однако, в PG это не работает: Код: sql 1. 2. 3. 4. 5.
ERROR: столбец "p_size" не существует HINT: Столбец "p_size" есть в таблице "part", но на него нельзя ссылаться из этой части запроса ... |
|||
:
Нравится:
Не нравится:
|
|||
10.03.2019, 11:21 |
|
|
start [/forum/topic.php?fid=40&msg=39775209&tid=1560785]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
102ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
2ms |
others: | 311ms |
total: | 508ms |
0 / 0 |