Подцепка или фильтр

[edward_K]

если напишите так
table3.nrec == table4.ctable3
то попадут - правило одинаковые на все уровни

[Den]

Сейчас попинал еще чуток и признаюсь что был не совсем точен.

в других диалектах общеизвестных поведение такое как я и описывал
Т.е. в запросе :

Код: Выделить всё

 select
          podr1.f$name
         ,podr2.f$name
         ,podr3.f$name
         ,podr4.f$name
         ,podr5.f$name
         ,podr6.f$name
         ,podr7.f$name
         ,podr8.f$name
  from t$katpodr podr1 left join t$katpodr podr2 on podr1.f$nrec =podr2.f$cpodr
                                  left join t$katpodr podr3 on podr2.f$nrec =podr3.f$cpodr
                                  left join t$katpodr podr4 on podr3.f$nrec =podr4.f$cpodr
                                  left join t$katpodr podr5 on podr4.f$nrec =podr5.f$cpodr
                                  left join t$katpodr podr6 on podr5.f$nrec =podr6.f$cpodr
                                  left join t$katpodr podr7 on podr6.f$nrec =podr7.f$cpodr
                                  inner join t$katpodr podr8 on podr7.f$nrec =podr8.f$cpodr

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

А вот галактическим sql если делать подобное :

Код: Выделить всё

select
          podr1.name
         ,podr2.name
         ,podr3.name
         ,podr4.name
         ,podr5.name
         ,podr6.name
         ,podr7.name
         ,podr8.name
  from katpodr podr1,katpodr podr2,katpodr podr3,katpodr podr4,katpodr podr5,katpodr podr6,katpodr podr7,katpodr podr8
     where ((
                comp(12345)==podr1.nrec   // посмотрим вниз с определенного корня
               and  podr1.nrec == podr2.cpodr
               and podr2.nrec == podr3.cpodr
               and podr3.nrec == podr4.cpodr
               and podr4.nrec == podr5.cpodr
               and podr5.nrec == podr6.cpodr
               and podr6.nrec == podr7.cpodr
               and podr7.nrec /== podr8.cpodr
             ));

вернется много данных

Но , к примеру, если сделать вот так :

Код: Выделить всё

select
          podr1.name
         ,podr2.name
         ,podr3.name
         ,podr4.name
         ,podr5.name
         ,podr6.name
         ,podr7.name
         ,podr8.name
  from katpodr podr1,katpodr podr2,katpodr podr3,katpodr podr4,katpodr podr5,katpodr podr6,katpodr podr7,katpodr podr8
     where ((
                comp(12345)==podr1.nrec  // посмотрим вниз с определенного корня
               and  podr1.nrec == podr2.cpodr
               and podr2.nrec == podr3.cpodr
               and podr3.nrec == podr4.cpodr
               and podr4.nrec == podr5.cpodr
               and podr5.nrec == podr6.cpodr
               and podr6.nrec /== podr7.cpodr
               and podr7.nrec == podr8.cpodr
             ));

то результат будет несколько иной (чем в случае podr7.nrec /== podr8.cpodr), а именно...в результат не попадут те записи реляционного графа, у которых есть что то на узле 6, но нет ничего на узле 7 . Записи же у которых ничего нет на узле 6 попадают в выборку.
Т.е. все же галактический sql функционирует несколько по другим правилам.

[edward_K]

жесткая подцепка аналогична inner join

[Screw]

Типичная ошибка начинающих (и не только) программистов на vip - считать, что конструкция create view соответствует SQL-запросу в СУБД. Нет! На самом деле, это целый куст отдельных запросов. А ещё точнее - куча инструкций Атлантису о том, какие запросы он должен выполнять для выборки определённых данных. Получив команду о доставке данных для узла (в виде вызова модификатора, например), Атлантис сам построит SQL-запрос и передаст его СУБД с помощью функционала ODBC, OCI и т.п. и т.д. Текст запросов можно отслеживать с помощью протокольных версий драйверов БД или любезно предоставляемых коллегой LaaLaa версий некоторых библиотек Атлантиса с прошитым в них логированием на основе SmartInspect.

Вот почему жёсткие подцепки влияют не на все узлы логической таблицы (ЛТ), а только на узлы, вовлечённые в эту связь.
Единственная конструкция, которая оказывает влияние на ЛТ в целом - это фильтр (condition), наложенный на ЛТ (не путать с узловыми фильтрами). Пользоваться такими фильтрами я лично не рекомендую - не потому, что они не работают (работают будь здоров!), а потому, что предсказать поведение ЛТ под таким фильтром может только очень-очень-очень опытный программист. Так что я сам стал избегать их давным-давно

[LaaLaa]

жесткая подцепка аналогична inner join

Эдвард просите меня за разрыв вашего мозга, но жесткая подцепка это не совсем inner join.
Долгое время тоже так думал но пом убедился что это не совсем так.

"Жестккую подцепку" следует воспринимать как уникальный оператор языка Atlantis-VIP (его части, нашего диалекта языка Atlantis-SQL), не имеющий прямых аналогов в других языках.

Точно также и "мягкая подцепка" - считайте это уникальным оператором диалекта Atlantis-SQL, точных прямых аналогов в других языках нет.

Параллель хочется провести но наше решение работает в другой плоскости.

Какие реально в БД пойдут запросы из какого оператора можно увидеть через протоколы
ftp://ftp.galaktika.ru/pub/support/temp ... Protocols/

[Алексей]

так... получается я был прав? в первоначально указанном мной коде данные table1 должны отображаться?

[Den]

Код: Выделить всё

table1.nrec == table2.ctable1
table2.nrec == table3.ctable2
table3.nrec /== table4.ctable3
table4.nrec /== table5.ctable4

4-я и 5-я таблицы подцеплены жёстко. НО если так сделать, то при цикле по table1 при отсутствии записей в 4-й и 5-й таблицах пропускает запись в table1.

если table3.nrec /== table4.ctable3 убрать жесткую подцепку - то запись с table1 в цикл попадает.

Все зависит от данных Ваших. Но если на уровнe table3 есть хотя бы одна запись по которой есть сооветствие в узле table4 от текущего корня table 1 то запись table1 текущая в результате должна быть по идее.Если такого соответствия ни одного нет , и нет других на узле 2.., то не должна будет выводиться table1.

[Алексей]

скажем так... у меня на 5-м уровне нет данных, жесткая подцепка режет четвёртый. он в свою очередь связан жестко с третьим, потому режется и третий.
НО данные на уровне 1 и 2 ЕСТЬ!!! а атлантис их не выводит!

т.е. я изначально так эту проблему и обозначил, т.к. по моему мнению, данные уровней 1 и 2 должны выводится!

интересно то что если 3 ==4 сделать мягко... то уровни выводятся. потому и ввело в ступор.

[Den]

скажем так... у меня на 5-м уровне нет данных, жесткая подцепка режет четвёртый. он в свою очередь связан жестко с третьим, потому режется и третий.
НО данные на уровне 1 и 2 ЕСТЬ!!! а атлантис их не выводит!

т.е. я изначально так эту проблему и обозначил, т.к. по моему мнению, данные уровней 1 и 2 должны выводится!

интересно то что если 3 ==4 сделать мягко... то уровни выводятся. потому и ввело в ступор.

рискну предположить что у Вас нет ни одной записи table2 НЕ ИМЕЮЩЕЙ предка в table3. (другими словами текущей table1 всегда есть что то на узле table3 ). Если сделать хоть одну терминальную запись в table2 то сразу выведиться один раз table1-table2. Т.к указано между 3 и 4 , и 4 и 5 /== то атлантический sql отсекает все, потому как нема ничего на 5 уровне как Вы сказали.