powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
19 сообщений из 19, страница 1 из 1
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
    #39775039
Игорь-PicoMed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Прекрасно работающий запрос в 2.1 - 2.5:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
with hst as (
  select hh.code srv, hh.Amount, hh.dat, hh.contract
  from history hh
    left join services srv on hh.code <> 0 and srv.id = hh.code
  where hh.id = 123
),
rules as (
 select first 1 h.*
 from hst h
  left join DAYS_OFF df on df.DAT = h.dat
)
select first 1 h.Amount, h.srv
 from rules h
  left join contract_cache cn 
    left join contract_detail cd on 
       (h.srv <> 0 and cd.contract = cn.contract and cd.service = h.srv and cd.type >= 0)  
  on h.contract <> 0 and cn.id = h.contract
отказывается работать в 3.0.4 с ошибкой в выделенной строке - "Column unknown H.SRV at line 16 column 66"
если не использовать алиас - hh.code srv, а обращаться по имени колонки "code" ошибка также сохраниться
если написать
Код: plaintext
 select first 1 h.srv
или
Код: plaintext
 select first 1 h.code
вместо
Код: plaintext
 select first 1 h.*
ошибка также сохраняется.

По поводу "странности" запроса камни не бросайте - всю математику я из него выбросил, чтобы понять в чем косяк - вложенность необходима (также как и вложенный left join)
...
Рейтинг: 0 / 0
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
    #39775046
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У тебя два алиаса h. Очевидно, подцепляется неправильный.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
    #39775050
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Игорь-PicoMed,

в условии джойна cn и cd не может быть полей из других таблиц.
...
Рейтинг: 0 / 0
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
    #39775083
Игорь-PicoMed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
hvladИгорь-PicoMed,

в условии джойна cn и cd не может быть полей из других таблиц.

Почему ???
По стандарту SQL это возможно
...
Рейтинг: 0 / 0
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
    #39775087
Игорь-PicoMed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry SibiryakovУ тебя два алиаса h. Очевидно, подцепляется неправильный.

замена второго алиаса на H1 не помогает, тем более что по полям второй алиас включает в себя поля первого

Главный момент - в FB 2.** работает
...
Рейтинг: 0 / 0
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
    #39775091
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Игорь-PicoMedПо стандарту SQL это возможно
подтвердить можешь?

Игорь-PicoMedГлавный момент - в FB 2.** работает
там много какой херни типа работает :-)

Собственно, это побочный эффект от CORE-2812. Вроде бы кто-то (камрад Коваленко?) уже писал про неработающие вложенные джойны-этажерки с подобными ссылками. Вот только не помню, нашел ли я доказательства в стандарте или просто забил...
...
Рейтинг: 0 / 0
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
    #39775093
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
К слову, если переписать по-человечески:

Код: sql
1.
2.
3.
4.
5.
6.
select first 1 h.Amount, h.srv
 from rules h
  left join contract_cache cn 
    on h.contract <> 0 and cn.id = h.contract
  left join contract_detail cd on 
    (h.srv <> 0 and cd.contract = cn.contract and cd.service = h.srv and cd.type >= 0) 



так работает или нет?
...
Рейтинг: 0 / 0
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
    #39775100
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Игорь-PicoMed,

по стандарту on должен быть сразу после join table, а не через один уровень.
И кстати в RN 3.0 про это говорится
...
Рейтинг: 0 / 0
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
    #39775108
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Дениспо стандарту on должен быть сразу после join table, а не через один уровень
тут ты не прав, стандарт такое тоже позволяет

Все дело в том, что если правильно раскрыть синтаксис JOIN ... ON, то

Код: sql
1.
2.
3.
4.
5.
from rules h
  left join contract_cache cn 
    left join contract_detail cd
      on (h.srv <> 0 and cd.contract = cn.contract and cd.service = h.srv and cd.type >= 0) 
  on h.contract <> 0 and cn.id = h.contract



превращается в

Код: sql
1.
2.
3.
4.
5.
6.
7.
from rules h
  left join (
    contract_cache cn 
    left join contract_detail cd
      on (h.srv <> 0 and cd.contract = cn.contract and cd.service = h.srv and cd.type >= 0) 
    )
    on h.contract <> 0 and cn.id = h.contract



где
Код: sql
1.
contract_cache cn left join contract_detail cd

по сути неявная derived table, в которой само собой (по стандарту) запрещены ссылки наружу подзапроса, т.е. на h в данном случае
...
Рейтинг: 0 / 0
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
    #39775116
Игорь-PicoMed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
dimitrИгорь-PicoMedПо стандарту SQL это возможно
подтвердить можешь?
Спецификация SQL-92:
Код: plaintext
1.
2.
3.
4.
7.5  <joined table>
***
            a) Each <column reference> directly contained in the <search
              condition> shall unambiguously reference a column of T1 or T2
              or be an  outer reference .


dimitrИгорь-PicoMedГлавный момент - в FB 2.** работает
там много какой херни типа работает :-)

В данном случае эта "хрень" также работает в Оракле и postgresql

dimitrВот только не помню, нашел ли я доказательства в стандарте или просто забил...
Симонов Денис по стандарту on должен быть сразу после join table, а не через один уровень.
И кстати в RN 3.0 про это говорится

На прямую в стандарте действительно так написано:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
7.5  <joined table>
***
         <qualified join> ::=
              <table reference> [ NATURAL ] [ <join type> ] JOIN
                <table reference> [ <join specification> ]

         <join specification> ::=
                <join condition>
              | <named columns join>

         <join condition> ::= ON <search condition>
***

однако в той же спецификации
см:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
  21.2.9  COLUMNS view 
***
              FROM DEFINITION_SCHEMA.COLUMNS AS C
                  LEFT JOIN
                    DEFINITION_SCHEMA.DATA_TYPE_DESCRIPTOR AS D1
                      LEFT JOIN
                        DEFINITION_SCHEMA.COLLATIONS AS C1
                        ON
                        ( ( C1.COLLATION_CATALOG, C1.COLLATION_SCHEMA, C1.COLLATION_NAME )
                        = ( D1.COLLATION_CATALOG, D1.COLLATION_SCHEMA, D1.COLLATION_NAME ) )
                  ON
                    ( ( C.TABLE_CATALOG, C.TABLE_SCHEMA, C.TABLE_NAME, C.COLUMN_NAME )
                    = ( D1.TABLE_OR_DOMAIN_CATALOG, D1.TABLE_OR_DOMAIN_SCHEMA,
                          D1.TABLE_OR_DOMAIN_NAME, D1.COLUMN_NAME ) )
                  LEFT JOIN
                    DEFINITION_SCHEMA.DATA_TYPE_DESCRIPTOR AS D2
                      LEFT JOIN
                        DEFINITION_SCHEMA.COLLATIONS AS C2
                        ON
                        ( ( C2.COLLATION_CATALOG, C2.COLLATION_SCHEMA, C2.COLLATION_NAME )
                        = ( D2.COLLATION_CATALOG, D2.COLLATION_SCHEMA, D2.COLLATION_NAME ) )
                  ON*** и т.д. 
...
Рейтинг: 0 / 0
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
    #39775117
Игорь-PicoMed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
dimitrК слову, если переписать по-человечески:

Код: sql
1.
2.
3.
4.
5.
6.
select first 1 h.Amount, h.srv
 from rules h
  left join contract_cache cn 
    on h.contract <> 0 and cn.id = h.contract
  left join contract_detail cd on 
    (h.srv <> 0 and cd.contract = cn.contract and cd.service = h.srv and cd.type >= 0) 



так работает или нет?

в таком варианте работает, но будет ли это корректно с точки зрения оптимизатора?

dimitrпо сути неявная derived table, в которой само собой (по стандарту) запрещены ссылки наружу подзапроса, т.е. на h в данном случае
Так оно по сути и должно быть с точки зрения логики построения запроса - в данном случае перемножение h*cd гораздо больше чем cn*cd, и см. письмо выше, стандарт разрешает внешние ссылкы в данных запросах
...
Рейтинг: 0 / 0
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
    #39775123
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Игорь-PicoMed,

может оно и позволяется стандартом, но лично меня от таких запросов коробит и начинает дёргаться глаз ибо запрос становится не читаемым и трудно понимаемым.
Привык в on видеть ясные и понятные условия того что соединяется, а не вообще любые.
А то что вы написали практически превращает JOIN в LATERAL JOIN, которые всё равно пока не работают.

Да и левые джойны пока что не дают оптимизатору никакого пространства, нету выполнения разными алгоритмами (только NESTED LOOP разве что с индексами поиграться), порядок соединения всё равно задан жёстко.
...
Рейтинг: 0 / 0
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
    #39775126
Игорь-PicoMed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Симонов ДенисИгорь-PicoMed,
может оно и позволяется стандартом, но лично меня от таких запросов коробит и начинает дёргаться глаз ибо запрос становится не читаемым и трудно понимаемым.
Если бы вы видели запрос целиком, то не только бы глаз начал дергаться - меня он и бесит и коробит, но альтернатива - использование GTT и selectable процедур, что не есть гуд, так как заведомо не совместимо с другими SQL базами, да и работает медленнее.
Симонов ДенисА то что вы написали практически превращает JOIN в LATERAL JOIN, которые всё равно пока не работают.
Да и левые джойны пока что не дают оптимизатору никакого пространства... порядок соединения всё равно задан жёстко.
и тут согласен - приходится самому включать мозг определяя порядок соединения исходя из объемов объединяемых таблиц.
Но какая альтернатива?
...
Рейтинг: 0 / 0
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
    #39775131
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Игорь-PicoMedстандарт разрешает внешние ссылкы в данных запросах

Внешние ссылки требуют внешних соединений. Иначе при рекомбинации таблиц ссылка может
внезапно стать внутренней.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
    #39775203
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денислично меня от таких запросов коробит и начинает дёргаться глаз ибо запрос
а сравнения столбцов с константами в условии объединения таблиц?
h.srv <> 0, cd.type >= 0 ...
Это уже почти глаз на ж. Это же не условия объединения, это "фильтрация", им место в where.
...
Рейтинг: 0 / 0
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
    #39775209
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdv,

да не, как раз с left join это уже условие соединение, вынос в where изменит результат.
...
Рейтинг: 0 / 0
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
    #39775212
Vlad F
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdv,

КМК, у тебя "глаз на ж" уже точно замылился, ведь в случае несимметрижных объединений это будет
кардинально другой запрос.))
...
Рейтинг: 0 / 0
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
    #39775326
WildSery
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvЭто уже почти глаз на ж. Это же не условия объединения, это "фильтрация", им место в where.Симонов Денисда не, как раз с left join это уже условие соединение, вынос в where изменит результат.
Мало того, что полно ситуаций, когда по-другому нельзя, соответственно, утверждать, что вот здесь надо в условие соединения, а вообще обязательно в "где" - это слегка раздвоение.
Даже если внутренним соединением соедините пару десятков таблиц, посмотрю я на ваш глаз, где условия фильтрации для присоединяемых будут во WHERE, а не аккуратно и очевидно в условии соединения.
...
Рейтинг: 0 / 0
Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
    #39784240
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Дошли тут руки покопаться немного.

Игорь-PicoMedВ данном случае эта "хрень" также работает в Оракле и postgresql
оракла под рукой нет, увы. Однако, в PG это не работает:

Код: sql
1.
2.
3.
4.
5.
select *
from part
  join partsupp
    join supplier on p_size = 0 and ps_suppkey = s_suppkey
on p_partkey = ps_partkey



ERROR: столбец "p_size" не существует
HINT: Столбец "p_size" есть в таблице "part", но на него нельзя ссылаться из этой части запроса
...
Рейтинг: 0 / 0
19 сообщений из 19, страница 1 из 1
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Вложенные запросы или почему рабочий запрос с 2.** не работает в 3.**
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]