ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Разница между запятой и JOIN
25 сообщений из 88, страница 1 из 4
  1  все
Разница между запятой и JOIN
    #33547238
Арбайтер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Арбайтер
Участник
Объясните мне, в чем разница между запросами:

SELECT table2.name FROM table1, table2
WHERE table1.id=table2.id

и

SELECT table2.name FROM table1
INNER JOIN table2 ON table1.id=table2.id

Результат вернется один и тот же обоими запросами. У обоих, по сути, одно и то же условие.
Зачем нужны JOIN-ы, если можно перечислить таблицы, из которых хочешь сделать выборку и описать условия, по которым сопоставить строки?
...
Рейтинг: 0 / 0
15.02.2006, 17:30
| Ответить | Цитировать | Написать  
Разница между запятой и JOIN
    #33547419
Фотография adv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adv
Участник
1
2
3 и дальше сам.
...
Рейтинг: 0 / 0
15.02.2006, 18:38
| Ответить | Цитировать | Написать  
Разница между запятой и JOIN
    #33547554
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
АрбайтерЗачем нужны JOIN-ы
Низачем.
...
Рейтинг: 0 / 0
15.02.2006, 20:07
| Ответить | Цитировать | Написать  
Разница между запятой и JOIN
    #33547835
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
Арбайтер
Зачем нужны JOIN-ы,

Чтобы
1 отделить условие на соединение от условий на выборку.
2 повысить семантичность
3 более строго управлять порядком соединениями.

4 вообще строгость. Если чел написал CROSS JOIN, то он явно прописал свое намерение. А без этого поди догадайся - мож он ошибся.
У Оракла, например, полно ограничений на внешние соединения. И он рекомендует outer join вмсето (+). Кроме того, есть естественные соединения - вообще без условий.
А раз для этих соединений, то для единого стиля и для всех прочих нужен единообразный синтаксис.
...
Рейтинг: 0 / 0
16.02.2006, 01:44
| Ответить | Цитировать | Написать  
Разница между запятой и JOIN
    #33554049
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Ну давайте начнем очередной виток.

vadiminfo1 отделить условие на соединение от условий на выборку.
Хм. А можете ли Вы рассказать, для запроса с более чем одной таблицей, чем одно концептуально отличается от другого? Дать достаточно формальный алгоритм "логичного" выбора между вариантами

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
select *
from a join b on a.id = b.id
where b.value =  3 

select *
from a join b on (a.id = b.id and b.value =  3 )

with c as (select * from b where value =  3 )
select *
from a join c on a.id = b.id

повысить семантичность
Не понимаю, что имеется в виду, но видимо как-то связано с предыдущим пунктом.

более строго управлять порядком соединениями.
И зачем? Если учесть, что SQL как раз декларативен, и предписывает не алгоритм (в том числе порядок соединений), но описывает результат, который должен получиться.

4 вообще строгость. Если чел написал CROSS JOIN, то он явно прописал свое намерение. А без этого поди догадайся - мож он ошибся.
В чем-то согласен. С другой стороны, CROSS JOIN - вещь весьма и весьма редкая, и только такой плюс никак не искупит все минусы подхода, например двойственный синтаксис.

У Оракла, например, полно ограничений на внешние соединения. И он рекомендует outer join вмсето (+).
Ну, надо смотреть, что лежит под этими рекомендациями, какое основание. Если основание - "подмазать комитет ANSI и за счет этого выторговать что-то другое", то это не то чтобы полноценный аргумент.

Кроме того, есть естественные соединения - вообще без условий.
И? Получается простой и понятный запрос, куда удачнее, нежели с дополнительным уродливым join-ом.

Заодно - мне всегда очень прикольно видеть, как в синтаксис join-ов пытаются впихнуть такую вещь, как условия соединения, затрагивающие несколько таблиц разом. Скажем,

Код: plaintext
1.
select ...
from a join b on (a.id = b.id and a.id2 = b.id2) join c on (c.id = b.id and c.id3 = a.id3)

vadiminfoА раз для этих соединений, то для единого стиля и для всех прочих нужен единообразный синтаксис.
Хм. Лучшее, что можно сделать для единообразного стиля - это придумать второй стиль, причем не способный адекватно заменить первый. Интересная мысль :)
...
Рейтинг: 0 / 0
18.02.2006, 18:38
| Ответить | Цитировать | Написать  
Разница между запятой и JOIN
    #33554129
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
2 softwarer
На внутреннем соединения отличия не так ощутимы. Однако, даже здесь есть все-таки разница. Операция соединения и выборки все же разные в рел алгебре. А WHERE - больше выборка, и при "больших" условиях отличить там условия на соединения от прочих сложнее. Кроме того, кроме условия ON, может быть USING. В некоторых случаях это семантичнее.

softwarer
И зачем? Если учесть, что SQL как раз декларативен, и предписывает не алгоритм (в том числе порядок соединений), но описывает результат, который должен получиться.

Ну как же? Операции в алгебре, к сожалению, не всегда ассоциативны - имеет значение что в первую очередь выполнить, что во вторую. В частности, при внешних соединениях такое может иметь место. Но это не нарушение деклративности - до реального алгоритма еще далеко. Но синтаксис с JOIN позволяет точно и однозначно определить порядок соединений. Например, неясности какие объединения внешние какие внутренние можно легче избежать.

softwarer
Ну, надо смотреть, что лежит под этими рекомендациями, какое основание. Если основание - "подмазать комитет ANSI и за счет этого выторговать что-то другое", то это не то чтобы полноценный аргумент.

Возможно. не полноценный. Но какой ни на есть, а тоже говорит о том, что слишком много разного в WHERE не просто примирить.

softwarer
Заодно - мне всегда очень прикольно видеть, как в синтаксис join-ов пытаются впихнуть такую вещь, как условия соединения, затрагивающие несколько таблиц разом. Скажем,

Но с другой стороны - мысль автора запроса выражена явно. Все-таки более строгая спецификация. Разве нет?

softwarer
Хм. Лучшее, что можно сделать для единообразного стиля - это придумать второй стиль, причем не способный адекватно заменить первый. Интересная мысль :)

Я имел в виду, что польза для внешних соединений или от естественных соединений есть. Ну тада и для внутреннего из двух таблиц тоже лучше JOIN, чтобы не было тут запятые, тут JOIN.
Чтобы тада уже во всех соединениях был JOIN. Так как автор спрашивал на примере внутреннего соединения из двух табл без сложных WHERE, где разница не ощутима.
Конечно, это больше про приложения или там множество отчетов. А итерактивно один маленький запрос - конечно роли не играет.
...
Рейтинг: 0 / 0
18.02.2006, 21:19
| Ответить | Цитировать | Написать  
Разница между запятой и JOIN
    #33555255
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
vadiminfoОперация соединения и выборки все же разные в рел алгебре.
А стоит ли "пользователю SQL" об этом думать? Они связаны достаточно тесно, так, что формальный критерий разделения сформулировать непросто (во всяком случае, я его просил...)

vadiminfoА WHERE - больше выборка, и при "больших" условиях отличить там условия на соединения от прочих сложнее.
Придерживаюсь строго противоположного мнения. В сложных запросах становится важным то, что WHERE дает свободу записи, в то время как JOIN диктует порядок условий, и как следствие FROM становится очень трудночитаемым. Собственно, в одной из предыдущих дискуссий я просил оппонентов подсказать удачное форматирование JOIN, и так и не увидел хорошего варианта.

Давайте посмотрим на пример: несколько таблиц с историей изменения записей. При использовании WHERE-соединений запрос можно записать примерно так:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
select 
  ...
from 
  a, b, c, d
where
  -- основные соединения
  a.a_id = b.a_id and
  b.b_id = c.b_id and
  b.b_id = d.b_id and
  -- выбор нужных версий
  a.date_apply between b.date_from and b.date_to and
  .... еще куча сложных условий, которые как правило
  .... вовсе не нужно читать, чтобы понять запрос

Обратите внимание, здесь нет ни одного фильтра, в чистом виде соединение таблиц. С использованием JOIN это придется писать либо так:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
select  
  ...
from
  a join b on 
      (a.a_id = b.a_id and a.date_apply between b.date_from and b.date_to) 
   join c on
      (b.b_id = c.b_id and ...........) and
  .....

- то есть условия смешены в кучу и плохо воспринимаются, либо использовать "частичный where-синтаксис", то есть половину условий соединения написать в join, а половину - в where.

vadiminfoНу как же? Операции в алгебре, к сожалению, не всегда ассоциативны
Это редко существенно, и в этих редких случаях никто не мешает использовать скобки.

vadiminfoНо синтаксис с JOIN позволяет точно и однозначно определить порядок соединений. Например, неясности какие объединения внешние какие внутренние можно легче избежать.
Безусловно. Аналогичный аргумент называется среди преимуществ польской записи - также однозначное определение порядка операций без скобок. Но почему-то она не стала общепринятым методом выражения мыслей :) Этого недостаточно.

vadiminfoВозможно. не полноценный. Но какой ни на есть, а тоже говорит о том, что слишком много разного в WHERE не просто примирить.
Хм. Уже затронул выше - при свободе выражения мысли в WHERE примирить можно; в прокрустовом синтаксисе JOIN сманеврировать просто нечем.

vadiminfoНо с другой стороны - мысль автора запроса выражена явно.
Мысль выражена явно, но сама мысль получается кривовата. Не думаю что можно назвать хорошим синтаксис, заставляющий думать кривые мысли.

vadiminfoЯ имел в виду, что польза для внешних соединений или от естественных соединений есть. Ну тада и для внутреннего из двух таблиц тоже лучше JOIN, чтобы не было тут запятые, тут JOIN.
Так чем же он лучше, если он не способен адекватно заменить существующий? Это уже получается логика - "главное, использовать join, а аргументы подбираются на ходу".

Давайте предположим, что (как доказываете Вы), join-стиль лучше для сложных не-inner соединений. Давайте предположим, что он (как среди прочего доказываю я) хуже для inner-соединений. В этом случае Ваше "тогда" выглядит так: давайте испортим себе жизнь в 80% случаев ради облегчения ее же в 20% случаев. Выглядит небесспорно :)

vadiminfoКонечно, это больше про приложения или там множество отчетов. А итерактивно один маленький запрос - конечно роли не играет.
Могу сказать так. Не так давно мне потребовалось писать код генерации SQL по метаинформации, примерно как в Discoverer-е. Сначала я предположил, что join-синтаксис окажется в этом случае удобнее, именно из-за более четкого разделения "что с кем и как вяжется". А в итоге - перешел на where-синтаксис , сократив программный код примерно на треть.
...
Рейтинг: 0 / 0
20.02.2006, 11:51
| Ответить | Цитировать | Написать  
Разница между запятой и JOIN
    #33555666
Фотография Denis Popov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Denis Popov
Участник
softwarerС использованием JOIN это придется писать либо так:

...

- то есть условия смешены в кучу и плохо воспринимаются, либо использовать "частичный where-синтаксис", то есть половину условий соединения написать в join, а половину - в where.
При внешних соединениях может возникнуть разница, где какое условие указывать.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
SQL> create table a (a_id int);

Table created.

SQL> insert into a (a_id) values ( 1 );

 1  row created.

SQL> insert into a (a_id) values ( 2 );

 1  row created.

SQL> create table b (a_id int, b_id int);

Table created.

SQL> insert into b (a_id, b_id) values ( 10 ,  1 );

 1  row created.

SQL> select *
   2   from a
   3        left outer join b on a.a_id = b.a_id
   4   where b.b_id =  2 ;

no rows selected

SQL> select *
   2   from a
   3        left outer join b
   4          on  a.a_id = b.a_id
   5          and b.b_id =  2 ;

      A_ID       A_ID       B_ID
---------- ---------- ----------
          1 
          2 

SQL> with b2 as (select a_id, b_id from b where b_id =  2 )
   2   select *
   3   from a
   4        left outer join b2 on a.a_id = b2.a_id;

      A_ID       A_ID       B_ID
---------- ---------- ----------
          1 
          2
...
Рейтинг: 0 / 0
20.02.2006, 13:33
| Ответить | Цитировать | Написать  
Разница между запятой и JOIN
    #33556164
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
softwarer
А стоит ли "пользователю SQL" об этом думать? Они связаны достаточно тесно, так, что формальный критерий разделения сформулировать непросто (во всяком случае, я его просил...)

Пользователю SQL лучше об этом думать - он же работает с реляционной БД. И если не будет об этом думать, то может не увидеть из-за деревьев леса. Это формально разные операции и пока не понимаю почему критерий разделения сформулировать не просто. Он приводится в литературе.

softwarer
Давайте посмотрим на пример: ...

- то есть условия смешены в кучу и плохо воспринимаются, либо использовать "частичный where-синтаксис", то есть половину условий соединения написать в join, а половину - в where.


Т.е. вы говорите, что они смешаны, а потом что полнвина в join половина в where. Т.е. все-тка разделены? А там где все в where получается большая куча.

softwarer
Это редко существенно, и в этих редких случаях никто не мешает использовать скобки.

Но эти редкие случаи могут приводить к ошибкам и большей возне при выяснении почему не правильно работает запрос? И еще более позднему выявлению, что он не правильно работает - при тестировании того плохого случая не нашли.

softwarer
Безусловно. Аналогичный аргумент называется среди преимуществ польской записи - также однозначное определение порядка операций без скобок. Но почему-то она не стала общепринятым методом выражения мыслей :) Этого недостаточно.


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


softwarer
Хм. Уже затронул выше - при свободе выражения мысли в WHERE примирить можно; в прокрустовом синтаксисе JOIN сманеврировать просто нечем

Вот именно что не с чем - не возникает этих проблем смешения всего подряд.


softwarer
Мысль выражена явно, но сама мысль получается кривовата. Не думаю что можно назвать хорошим синтаксис, заставляющий думать кривые мысли.


Так что же Вы предпочтете, читая чужей код - кривоватую мысль явно выраженную, или кривоавтую, но не явно выраженную?

softwarer
Так чем же он лучше, если он не способен адекватно заменить существующий? Это уже получается логика - "главное, использовать join, а аргументы подбираются на ходу".

Насчет того, что не адеватно, особенно внешние соединения, пока не замечал. И в литературе тоже, вроде, нет таких утверждений.
Аргументы не походу - я есче литру читаю, когда пишу. По крайней мере в прошлый раз смротрел.


softwarer

Давайте предположим, что (как доказываете Вы), join-стиль лучше для сложных не-inner соединений. Давайте предположим, что он (как среди прочего доказываю я) хуже для inner-соединений. В этом случае Ваше "тогда" выглядит так: давайте испортим себе жизнь в 80% случаев ради облегчения ее же в 20% случаев. Выглядит небесспорно :)

Я не думаю что в 80% испортим себе жизнь, а вот в 20% улучшим - тут и Вы согласны? Я пользуюсь тока JOIN на 9-ке во всех случаях и мне не кажется ухудшением по сравненю с 8-кой, гда приходилось с запятыми.
Наоборот все строже и потому меньше времени потом на понимание что хотел автор.

softwarer

Могу сказать так. Не так давно мне потребовалось писать код генерации SQL по метаинформации, примерно как в Discoverer-е. Сначала я предположил, что join-синтаксис окажется в этом случае удобнее, именно из-за более четкого разделения "что с кем и как вяжется". А в итоге - перешел на where-синтаксис , сократив программный код примерно на треть.

У меня прямопротивоположный опыт. Я даже иду на то, что расписываю вместо таблов подзпросы ради NATURAL JOIN. Плюс подзапросы для тежелых запросов выношу в WITH. И пока очень рад тому что появились JOIN - ны в 9.
...
Рейтинг: 0 / 0
20.02.2006, 15:50
| Ответить | Цитировать | Написать  
Разница между запятой и JOIN
    #33557247
Алексей_гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей_гость
Гость
Выскажусь как DBA. У нас в компании принято разрабатывать отчеты непосредственно на боевом сервере (насчет консерватории - не ко мне вопрос). Не используя JOIN и пропустив условие во WHERE любой программист может лугко поставить раком всю систему. Так частенько и случалось, пока не приказали использовать только JOIN.
Конечно осталось немало других способов, но эта была достаточно большая проблема.
...
Рейтинг: 0 / 0
21.02.2006, 06:04
| Ответить | Цитировать | Написать  
Разница между запятой и JOIN
    #33557839
Slider_spb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Slider_spb
Участник
Согласен с последним автором. И еще добавлю, что синтаксис с Join более строгий и как раз более легок для визуального восприятия, зато для динамического SQL синтаксис без них действительно более удобен. Так что нечего разводить тут "священные" войны, я использую тот, который удобней мне в конкретной задаче и ситуации.
...
Рейтинг: 0 / 0
21.02.2006, 11:47
| Ответить | Цитировать | Написать  
Разница между запятой и JOIN
    #33558633
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mir
Участник
softwarer
Давайте посмотрим на пример: несколько таблиц с историей изменения записей. При использовании WHERE-соединений запрос можно записать примерно так:
...
Обратите внимание, здесь нет ни одного фильтра, в чистом виде соединение таблиц. С использованием JOIN это придется писать либо так:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
select  
  ...
from
  a join b on 
      (a.a_id = b.a_id and a.date_apply between b.date_from and b.date_to) 
   join c on
      (b.b_id = c.b_id and ...........) and
  .....

- то есть условия смешены в кучу и плохо воспринимаются, либо использовать "частичный where-синтаксис", то есть половину условий соединения написать в join, а половину - в where.Что-то непонятно про "частичный where-синтаксис". По ходу, это вы сами такое понятие сочинили, нет? По определению, в предложении JOIN записываются только условия собственно соединения, то есть равенство или другая тета-операция (<, >, <=, >=, <>) на столбцах двух таблиц. Никакие другие условия вроде "a.date_apply between b.date_from and b.date_to" никак к операции соединения не относятся . По определению. Поэтому они должны быть записаны в предложении where. Все очень четко по теории, никаких неоднозначностей. Фильтру -- фильтрово, джойну -- джойново.
...
Рейтинг: 0 / 0
21.02.2006, 15:24
| Ответить | Цитировать | Написать  
Разница между запятой и JOIN
    #33558978
problemsolver
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
problemsolver
Участник
mirПо определению, в предложении JOIN записываются только условия собственно соединения, то есть равенство или другая тета-операция (<, >, <=, >=, <>) на столбцах двух таблиц. Никакие другие условия вроде "a.date_apply between b.date_from and b.date_to" никак к операции соединения не относятся . По определению. Поэтому они должны быть записаны в предложении where. Все очень четко по теории, никаких неоднозначностей. Фильтру -- фильтрово, джойну -- джойново.

Блин, вот теоретики :-)
Чем тебе between не то же самое, что пара неравенств с AND
...
Рейтинг: 0 / 0
21.02.2006, 16:59
| Ответить | Цитировать | Написать  
Разница между запятой и JOIN
    #33559003
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
mirНикакие другие условия вроде "a.date_apply between b.date_from and b.date_to" никак к операции соединения не относятся .IMHO, несколько погорячимшись, это условие соединения, а не фильтра. Не обращаясь к источникам, опираясь только на IMHO, полагаю, что к условиям соединения относятся все условия, в которых происходит сравнение данных из одной таблицы с данными из другой таблицы. Хуже того, в случае внешних слияний даже сравнение поля с константой, обычно трактуемое как фильтр, вполне легально может перекочевать в условие соединения.
...
Рейтинг: 0 / 0
21.02.2006, 17:06
| Ответить | Цитировать | Написать  
Разница между запятой и JOIN
    #33560238
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mir
Участник
2 problemsolver & ChA

Надеюсь, это не покажется грубым, но пора, пора, ребята, перечитать определение операции тета-соединения.
...
Рейтинг: 0 / 0
22.02.2006, 11:28
| Ответить | Цитировать | Написать  
Разница между запятой и JOIN
    #33562088
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
mirпора, ребята, перечитать определение операции тета-соединения.Хотелось бы узнать, что во фразе ChAк условиям соединения относятся все условия, в которых происходит сравнение данных из одной таблицы с данными из другой таблицыпротиворечит определению тета-соединения ? Следует ли считать, что пример от softwarer
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
select  
  ...
from
  a join b on 
      (a.a_id = b.a_id and a.date_apply between b.date_from and b.date_to) 
   join c on
      (b.b_id = c.b_id and ...........) and
  .....
правильно писать так
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
select  
  ...
from
  a join b on 
      (a.a_id = b.a_id) 
   join c on
      (b.b_id = c.b_id and ...........) and
  .....
WHERE a.date_apply between b.date_from and b.date_to
.....
?
Возможно, не прав, так как не могу считать себя теоретиком, но ни одно из доступных мне определений тета-соединения не противоречит написанию условия a.date_apply between b.date_from and b.date_to в условиях слияния ON пункта FROM. Допускаю, что Вы сделали такое заключение на основании того, что в определении тета-соединения не упоминается оператор сравнения between ? IMHO, по этому поводу было сделано абсолютно справедливое, хотя и несколько грубоватое по форме, замечание problemsolverЧем тебе between не то же самое, что пара неравенств с ANDМожно ли Вас понимать так, что
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
select  
  ...
from
  a join b on 
      (a.a_id = b.a_id and a.date_apply >= b.date_from  and a.date_apply <= b.date_to) 
   join c on
      (b.b_id = c.b_id and ...........) and
  .....
выглядит более кошерно в свете определения тета-соединения, чем
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
select  
  ...
from
  a join b on 
      (a.a_id = b.a_id and a.date_apply between b.date_from and b.date_to) 
   join c on
      (b.b_id = c.b_id and ...........) and
  .....
?
Или мое непонимание сути проблемы гораздо глубже ?

P.S. Уважаемый mir, будьте любезны, в следующий раз использовать аргументы несколько более содержательные, чем пора, ребята, перечитать .
P.P.S. Напомните также, если несложно, какие условия правильно писать в ON, а какие в WHERE в случае внешних объединений, которые, если правильно понимаю, не относятся к тета-соединениям. В крайнем случае, укажите какой-либо доступный источник, в котором есть более весомые утверждения, чем mirФильтру -- фильтрово, джойну -- джойново.
...
Рейтинг: 0 / 0
23.02.2006, 02:32
| Ответить | Цитировать | Написать  
Разница между запятой и JOIN
    #33563317
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mir
Участник
Готов признать, что по поводу тета-соединени я поторопился и был более категоричен, чем следует. Дело тут в чем. Оказывается, в литературе, как я обнаружил, есть разные определения Θ-соединения.

Я ориентировался на определение, данное Дейтом в книге "Введение в системы баз данных". Если коротко, оно заключается в том, что условие соединения имеет вид (a Θ b), где a и b - имена атрибутов соединяемых отношений A и B, а Θ - операция сравнения (=, <, <=, <>, >, >=).

Аналогичное определение дает C. Кузнецов . (Естественно, если соединение идет по нескольким атрибутам, то используется умножение нескольких условий, по числу пар атрибутов).

В то же время в книге Гарсиа-Молина/Ульман/Уидом "Системы баз данных. Полный курс" дается несколько иное определение, при котором условие Θ-соединения не обязательно имеет вид (a Θ b), а может быть любым выражением. (Непонятно, правда, при чем здесь тогда тета).

Таким образом, если принять за истину первый вариант, я прав. Если второй -- нет. Теперь -- мир?
...
Рейтинг: 0 / 0
24.02.2006, 08:01
| Ответить | Цитировать | Написать  
Разница между запятой и JOIN
    #33563422
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Я безусловно уважаю С. Кузнецова, у которого учился и которого считаю отличным преподавателем, и в том числе поэтому хотел бы подчеркнуть, что его определение ничуть не ограничивает сказанное мной в данном случае. Если, как Вы сами говорите, возможно соединение по нескольким парам атрибутов, никто не мешает (в определении нет такого запрета) соединить по парам (a, a) - (b1, b2).

Я бы сказал, в процитированном определении дается попытка как раз дать такой формальный критерий отличия операции соединения от операции ограничения - соединение есть логическая операция над атрибутами разных отношений, ограничение есть логическая операция над атрибутом и константой (ну и - не помню, упомянуто там или нет - над атрибутами одного отношения).

Вот с такой постановкой вопроса я уже не соглашусь (безусловно признавая, что она существует, я бы просто поспорил с полезностью такой теории). Я полагаю, что суть важнее формы; в частности, я не вижу разницы (в том числе с точки зрения реализации хорошей БД) между запросами, например

Код: plaintext
1.
2.
select * from a where a.id =  5 

select * from a join (select  5  id from dual) b on (a.id = b.id)

или

Код: plaintext
1.
2.
select * from a join b on (a.id = b.id and b.type =  5 )

select * from a join (select * from b where type =  5 ) b on (a.id = b.id)
...
Рейтинг: 0 / 0
24.02.2006, 10:25
| Ответить | Цитировать | Написать  
Разница между запятой и JOIN
    #33563475
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
vadiminfoПользователю SQL лучше об этом думать - он же работает с реляционной БД. И если не будет об этом думать, то может не увидеть из-за деревьев леса.
Объясните, пожалуйста, какого именно леса (нуждающегося во внимании) не увидит пользователь. "Формально разные операции" - пользователю согласитесь, пользователю интересно не более, нежели формальная разница между целочисленным и вещественным сложением.

Мало того, сама формальная разница - сомнительна. Вольно пересказывая того же Кузнецова - операция соединения не относится к базовым, реализуема через базовые и упоминается лишь потому, что является практически очень важным частным случаем.

vadiminfoТ.е. вы говорите, что они смешаны, а потом что полнвина в join половина в where.
Я этого не говорю. Я говорю, что в данном примере придется либо свалить все в невоспринимаемую кучу в join, либо таки использовать where для записи части условий соединения.

vadiminfo softwarer
Это редко существенно, и в этих редких случаях никто не мешает использовать скобки.

Но эти редкие случаи могут приводить к ошибкам и большей возне при выяснении почему не правильно работает запрос?
Не более чем в join-синтаксисе. Например, лично я не отношу к "интуитивно понятным" тот факт, что в запросе

Код: plaintext
1.
2.
select *
from a left join b on (a.id = b.id)
where b.type =  5

в результате запросто окажутся записи с b.type, отличным от 5.

vadiminfoИ еще более позднему выявлению, что он не правильно работает - при тестировании того плохого случая не нашли.
Лучше скажите, что не всегда проводится тестирование. Тестера, который это пропустил, нужно немедленно увольнять по профнекомпетентности; такие ошибки находятся просто взглядом на текст select-а, и бросить этот взгляд - прямая обязанность тестера (предлагаю не обсуждать подход черного ящика).

Да, программист может сделать ошибку, в том числе и здесь. Особой опасности ошибки именно здесь я не вижу; цену, которую Вы предлагаете заплатить, считаю несоразмерной.

vadiminfo softwarer
Хм. Уже затронул выше - при свободе выражения мысли в WHERE примирить можно; в прокрустовом синтаксисе JOIN сманеврировать просто нечем

Вот именно что не с чем - не возникает этих проблем смешения всего подряд.
Насколько я вижу, Вы просто проигнорировали приведенный мной пример, как впрочем и другие.

Я бы предпочел, чтобы Вы явно сказали "меня это не убеждает, потому что <контрпример>". Впрочем, спорить с точкой зрения я не собираюсь; игнорируете - так игнорируйте.

vadiminfoТак что же Вы предпочтете, читая чужей код - кривоватую мысль явно выраженную, или кривоавтую, но не явно выраженную?
Я предпочитаю прямую и удобно выраженную. Я пока что не встречал случая, где этого не удавалось достичь в where-синтаксисе. Я встречал случаи, где [мне] не удавалось этого достичь в join-синтаксисе. Далее?

vadiminfoЯ не думаю что в 80% испортим себе жизнь,
OK. Собственно, что я сказал чуть выше. Но давайте все же четко зафиксируем: то ли Вы "не думаете", то ли Вы приводите какие-либо аргументы. Ссылка "смотрел в литературу" без упоминания сути увиденного, честно говоря, для меня аргументом не является.

vadiminfoа вот в 20% улучшим - тут и Вы согласны?
Нет, не согласен, и нигде такого не говорил - я сказал "Вы доказываете, что" и предложил допустить истинность этого в рамках одного локального рассуждения. Если Вы не согласны со вторым постулатом, на котором основано это рассуждение, оно становится недействительным и я не вижу никаких причин соглашаться с этим выделенным утверждением и со следующими из него выводами.

vadiminfoЯ даже иду на то, что расписываю вместо таблов подзпросы ради NATURAL JOIN.
Думаю, это точка, на которой можно остановиться. Увидев natural join в боевом коде, лично я испытаю сильное желание выкинуть автора этого кода за дверь.

vadiminfoПлюс подзапросы для тежелых запросов выношу в WITH.
Аналогично. Впрочем, они расписывались и во FROM - но в WITH они в первую очередь делают запрос лучше читаемым (облегчают основной запрос). Ну и само собой, дают весьма полезные дополнительные возможности.
...
Рейтинг: 0 / 0
24.02.2006, 11:07
| Ответить | Цитировать | Написать  
Разница между запятой и JOIN
    #33563809
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
softwarerНе более чем в join-синтаксисе. Например, лично я не отношу к "интуитивно понятным" тот факт, что в запросе

Код: plaintext
1.
2.
select *
from a left join b on (a.id = b.id)
where b.type =  5

в результате запросто окажутся записи с b.type, отличным от 5.
Опа - как это у нас получится ? Данный запрос в итоге с учетом наложение на внешнее соединение фильтра будет эквивалентен прямому соединению и к примеру в ASA так и будет стоять INNER JOIN в плане запросов (что есть логично и правильно).
...
Рейтинг: 0 / 0
24.02.2006, 14:41
| Ответить | Цитировать | Написать  
Разница между запятой и JOIN
    #33563817
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Кстати еще интересно, как написать через WHERE аналог такого джойна:
авторSELECT *
FROM a
LEFT JOIN (b INNER JOIN c ON c.b_id = b.id) ON b.a_id = a.id
Особенно когда хочется, чтобы в плане запросов "b" и "c" шли прямым соединением, а "b" и "a" внешним, что бывает актуально при соединении таблиц с большим числом записей в сложных запросах.
...
Рейтинг: 0 / 0
24.02.2006, 14:45
| Ответить | Цитировать | Написать  
Разница между запятой и JOIN
    #33563845
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
ASCRUSОпа - как это у нас получится ?
Хм. И в самом деле любопытно. Утром у меня получилось :) Давайте пока примем в качестве рабочей гипотезы, что я был очень непроснувшимся, а я попробую повторить тот эксперимент, который дал такой результат. Утром он меня тоже удивил, но я решил, что это фича :)

OK, тогда скажу то, что собственно говоря собирался сказать до этого эксперимента - я не вижу разницы в легкости внести ошибку между вариантами

Код: plaintext
1.
2.
3.
4.
5.
6.
select *
from a, b
where a.id = b.id (+) and  5  = b.type 

select *
from a left join b on a.id = b.id
where b.type =  5

А насчет "интересно" - если мне не изменяет память, я показал это еще в прошлом обсуждении, где Вы задали такой же вопрос.
...
Рейтинг: 0 / 0
24.02.2006, 14:59
| Ответить | Цитировать | Написать  
Разница между запятой и JOIN
    #33564095
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
mirТаким образом, если принять за истину первый вариант, я прав. Если второй -- нет.Мне по-прежнему хотелось бы получить от Вас четкий критерий, когда условия помещаются в ON, а когда в WHERE, и не только в случае тета-соединения. Мой вариант был изложен ранее , теперь хотелось бы увидеть Ваш. Уверен, что он будет теоретически более строг и однозначен, в отличие от моего.
P.S. По поводу различия определений тета-соединения. IMHO, главное и общее во всех них то, что условие Θ-соединения представляет собой некую функцию над столбцами участвующих отношений, которая должна возвращать TRUE для соответствующих пар кортежей, а не применимость between в этом контексте в сравнении с = , > , < , и т.д.
...
Рейтинг: 0 / 0
24.02.2006, 17:57
| Ответить | Цитировать | Написать  
Разница между запятой и JOIN
    #33564100
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
softwarer
Объясните, пожалуйста, какого именно леса (нуждающегося во внимании) не увидит пользователь. "Формально разные операции" - пользователю согласитесь, пользователю интересно не более, нежели формальная разница между целочисленным и вещественным сложением.

Не увидит концептуальной последовательности операций в сложном запросе, погрязнет в деталях. Алгебра есть алгебра. Вам не приходится разъяснять парням, почему сумма значений просто в табле меньше, чем таже у сумма после того как они соединили много таблов с данной таблой (дубли соединения) на бумаге? Вот от того, что им не «интересно» было. Иногда они часами мучаются, не могут объяснить результатов того, что написали. Хорошо, если увидят вообще, что там что-то не то. А мне приходится периодически.

softwarer
Мало того, сама формальная разница - сомнительна. Вольно пересказывая того же Кузнецова - операция соединения не относится к базовым, реализуема через базовые и упоминается лишь потому, что является практически очень важным частным случаем.

Кузнецова не читал. Но читал, например, Мейера «Теория реляционных БД» и др.. Там про реализацию через «базовые» не припомню. Если «базовые» операции - это выборки (WHERE), то они - унарные, а соединение – бинарная операция. Или Вы к базовым относите Декартово произведение? Все-таки оно в рел алгебре лучше смотрится как частный случай соединения. Причем как Вы сказали, соединения очень важная операция. Достойная рассмотрения как отдельной, даже если ее вывели из "базовых". В частности, она может приводить к потере информации (дублям, которых не ждали), если не принимать особых мер. Внешние соединения еще хуже воспринимаются как порожденные от «базовых».
softwarer
Я говорю, что в данном примере придется либо свалить все в невоспринимаемую кучу в join, либо таки использовать where для записи части условий соединения.

Почему Вы считаете, что куча в where лучше кучи в join, тем более что в where есть еще что-то – она как бы больше в данном примере.
softwarer

Например, лично я не отношу к "интуитивно понятным" тот факт, что в запросе …
в результате запросто окажутся записи с b.type, отличным от 5.


В этом примере очень наглядно прописано внешнее соединение left. Поэтому «интуитивное» здесь уже лишнее – все и так очевидно. А вот (+) в Оракле или (*) в Скуле, которые, насколько я помню, совершенно по разному действуют в плане левого и правого и находятся в WHERE, а не рядом с JOIN значительно менее семантичны, да и неожиданны – надо запоминать как они работают. Тут нет, нет да и без интуиции иной раз и не обойтись

softwarer

Лучше скажите, что не всегда проводится тестирование. Тестера, который это пропустил, нужно немедленно увольнять по профнекомпетентности; такие ошибки находятся просто взглядом на текст select-а, и бросить этот взгляд - прямая обязанность тестера (предлагаю не обсуждать подход черного ящика).

Конечно, я могу сказать легко, что не всегда проводится тестирование. Что тестеров увольнять не получится – их и так нет. Во взгляды на select в сложных случаях не верю – нужно подставлять таблы заполненные по разному. Но ведь речь шла о том, чтобы упростить тестирование, сопровождение, да и разработку.

softwarer

Да, программист может сделать ошибку, в том числе и здесь. Особой опасности ошибки именно здесь я не вижу; цену, которую Вы предлагаете заплатить, считаю несоразмерной.

Во-первых, не тока я предлагаю. Как бы еще кое-кто, включая Оракла, про Скуль молчу – там еще раньше Джойны появились. Про стандарты тем более – там просто нет другого синтаксиса для внешних соединений. Во-вторых, насчет несарозмерности – не очевидно. Мне все еще кажется (+) не очень сарозмерным в принципе. А для внутренних соединений Джойны строже, но это – дело стиля. Все-таки – явно паписть «Соеденить таблы», чем перечислить их через запятую побольше смысл операции виден будет.


softwarer
Насколько я вижу, Вы просто проигнорировали приведенный мной пример, как впрочем и другие.

Да нет. Просто я на нем только лишний раз убедился в большей строгости синтаксиса с join. Соединяются таблы а и b и все правила соединения прописаны в одном месте, где и ожидаются: в условиях на соединения. Потому и не стал ничего говорить: Вы можете сказать – это субъективно.
softwarer
Я бы предпочел, чтобы Вы явно сказали "меня это не убеждает, потому что <контрпример>". Впрочем, спорить с точкой зрения я не собираюсь; игнорируете - так игнорируйте.


Я уверен, что Вы очень хорошо знаете предмет, чтобы мне приводить примеры. Меня это не убеждает, потому что пока Ваши примеры мне очень нравятся в поддержку синтаксиса JOIN.
softwarer
Я предпочитаю прямую и удобно выраженную.

Но что это значит? «Прямая», «удобно выраженная»? Что там прямого и удобного? Да там более упрощенный синтаксис. Но не за счет ли строгости? То бишь прямоты? А удобно написать (проще), не всегда удобно прочитать – не ясно что хотел, мож просто ошибся, а мож так и надо.
softwarer
Я пока что не встречал случая, где этого не удавалось достичь в where-синтаксисе. Я встречал случаи, где [мне] не удавалось этого достичь в join-синтаксисе.

Я не сомневаюсь, что Вам удавалось. И мне трудно представить, чтобы Вам не удалось. Или Вы имеете в виду те примеры? Мне кажется, Вам удалось и очень хорошо все выразить прямо и удобно, по крайней мере для меня.
softwarer
OK. Собственно, что я сказал чуть выше. Но давайте все же четко зафиксируем: то ли Вы "не думаете", то ли Вы приводите какие-либо аргументы. Ссылка "смотрел в литературу" без упоминания сути увиденного, честно говоря, для меня аргументом не является.

Согласен. Но Вы тоже сказали просто, что в 80% ухудшим себе жизнь. А я так же сказал, что особо не испортим, а может еще и улучшим. Кто будит считать все случаи на практике за нашей спиной и считать их испорченными или нет? Тут аргументированность по любому слабая с обоих сторон.

softwarer
Нет, не согласен, и нигде такого не говорил

Значит я не так понял фразу – про ради 20% испортить жизнь в 80 %.

softwarer
Думаю, это точка, на которой можно остановиться. Увидев natural join в боевом коде, лично я испытаю сильное желание выкинуть автора этого кода за дверь.


Выкидывать кого-то за дверь – мне не известные желания. Если natural join написан без проекций в подзапросах, исключающих «неожиданные» условия соединения, которые могут появиться позже – добавили новые поля с одинаковыми именами, то да я против такого. И не рекомендую использовать это начинающим в боевом коде, пока они не представляют себе всех последствий. В противном случае исключение вообще условий на соединения, особенно тех, что Вы называете основными – значительно улучшает чтение запроса. Т.е. пропадает вообще вопрос от том что куда переносить. О чем мы говорили выше. Поди плохо?
...
Рейтинг: 0 / 0
24.02.2006, 18:00
| Ответить | Цитировать | Написать  
Разница между запятой и JOIN
    #33564118
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
softwarerне вижу разницы в легкости внести ошибку между вариантами
Оригинальный подход к сравнению синтаксиса. Хотя из этого может следовать отсутствие различия даже между разными языками. Мощно, стоит запатентовать.
...
Рейтинг: 0 / 0
24.02.2006, 18:10
| Ответить | Цитировать | Написать  
25 сообщений из 88, страница 1 из 4
  1  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Разница между запятой и JOIN
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=33557247&tid=1541836]:
 0ms
get settings:
 10ms
get forum list:
 20ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 48ms
get topic data:
 8ms
get forum data:
 2ms
get page messages:
 73ms
get tp. blocked users:
 2ms
others: 244ms
total:  415ms
созд. / загр.: 415ms
x
x
Закрыть


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