Потребовалось воткнуть еще один джоин в и без того насыщенную списками таблицу (результ то бишь) и воткнул по схеме на атрибуте = атрибут потому что еще условие надо было добавить. Компилятор завопил про двусмысленность одного из атрибутов, я ничего сперва не понял. Выше есть using(), ниже есть по атрибутам с тем же самым атрибутом - одним джоином больше, какая разница. Оказалось есть. Юсинги видимо должны быть в одной стае, а по-атрибутно - в другой, вероятно ниже, а может и пофигу.

Ну так вот, тут я подумал а нельзя ли присобачить к using() еще и условие, типа using(common_id) and common_id = some_value... Проверил на практике - нельзя. Пошел искать может какой-то хитрый синтаксис требуется и напоролся на попсовую статью про джойны и юзинг в частности.

Автор начинает со сравнения синтаксиса соединения в стиле Фиты (я не знал что оно - Theta-стайл), переходит на АНЗИ-стайл и с него на юзинги. И в конце самая мякотка. Я сперва подумал это конкретно про using(), типа именно юзинг так оптимизируется и полез скрипеть своей консолью. Повторил пассы и увидел абсолютно такую же оптимизацию для обычного по-атрибутного соединения, то есть через on f.id = f1.id Вернулся к статье и дочитал что оно _вообще_ для джоинов именно так.

Тогда спрашивается на какой козе баян - столько спорили какой синтаксис правильный и самый-самый оптимизированный, если наколка из той же буквы - Фита?

http://code.openark.org/blog/mysql/mysql-joins-on-vs-using-vs-theta-style

bochkovЧто ты хочешь, уважаемый, я ничего не понял,
игры разума?

Не поняли - пройдите мимо. Или задайте вопрос по существу. Смысл в том что запрос вида

select * from t1 join t2 on t1.id = t2.id

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

select * from t1, t2 where t1.id = t2.id

То есть из анзи в оракл, в т.н. фита-стайл, который усердно обсерали.

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

Arhat109У меня ваще, давно уже есть один метод у каждого класса сущности БД: getBy(array) "найди по списку условий". И чего он там "подключает" интересно только один раз при написании метода этого класса getSQL(array) -- отдай свой кусок запроса согласно условиям.

Звездешь. SQL это не ковыряние jquery в dom'е. Нет в SQL "условий" таких, как их программисты понимают. Кстати все эти популярные объяснения взаимодействия отношений с рисунками типа вот inner это значит intersection двух кругов, а вот left join ... и нарисованы круги закрашенные по-разному.

Потому что бд не массив. И не дом. Бд это туева хуча кортежей которые состоят из туевой хучи атрибутов. Ваши "условия" формируют лишь более-менее высокую степень вероятности извлечения из этой туевой хучи хуч чего-то такого, что вы ожидали получить. Чем хуча туевее, тем труднее определять неопределенность которой по умолчанию является реляционная бд. В отличии от массива точек о каждой из которых заранее все известно.

Технически никуда от cartesian product не деться. Код СУБД будет брать все указанные отношения и оцеживать их своими foreach'ами по забитым в стек аргументам в if then.