(с) "Очевидное-невероятное"...

шЮтка, конечно А.С.Пушкин.:-)

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

> Имелось в виду, что нашел, что у таблиц могут быть алиасы. Хорошая фича.
кто ж знал, что ты не знаешь про псевдонимы, про которые пишут на 15-20 й странице любого учебника по sql. и проблему ты видишь только в этом...
я вот вижу у тебя проблему в нежелании работать со списками, непонимании логики баз. а вовсе не в алиасах.

кстати, у твоего подхода есть минус, кроме того что там полей не напасешься, ну вот представь, что после будет например 200 человек... 200 полей, и 200 объединений таблицы самой с собой, вместо одно... это хороший способ поставить "на колени" любой sql сервер. даже четыре могут тормозить при определенных условиях. (размер таблиц/отсутствие или невозможность использование индексов)
вот запиши объединение в явном виде, с помощью join-ов сразу поймешь что имеется в виду. (join-ы это тоже хорошая фича, про которую ты наверное не знаешь, и рекомендуемая к использованию т.к. она ближе к тому как работает sql сервер, больше способствует пониманию, чем неявные объединения)

> (join-ы это тоже хорошая фича, про которую ты наверное не
> знаешь, и рекомендуемая к использованию т.к. она ближе к
> тому как работает sql сервер, больше способствует пониманию,
>  чем неявные объединения)

Зато с ними тяжелее оптимизить запросы.

> И это всё, что ты увидел в ответе, хотя об этом в нём не
> говорилось.


Я собственно это и говорил - что алисов не увидел - сам нашел.


> кто ж знал, что ты не знаешь про псевдонимы, про которые
> пишут на 15-20 й странице любого учебника по sql.


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

Посмотрел по планам/использованию индексов/анализу производительности. Вроде бы никакой крамолы нет. Индексы по ключам используются. Натуральных планов нет. Из таблиц количество чтений минимально достаточное для того, что бы отдать данные.

Вроде бы никакой крамолы. Во всяком случае, пока...

200, как и 1000 человек, думаю, никак не повлияют на скорость. 200 джобов, думаю, там не будет никогда. Далее, в случае необходимости, будем оптимизировать базу. Пока ограничимся имеющимся запросом.

Всем спасибо за ответы.

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

> Вроде бы никакой крамолы нет.
4 объединения в любом случае, даже самом оптимистичном, в 4 раз медленнее чем одно. при том же результате, только в непривычном для тебя виде.

> Далее, в случае необходимости, будем оптимизировать базу.
не получится. далее тебе ее придется переделывать с 0.

> Пока ограничимся имеющимся запросом.
вольному воля.

Сникника пора судить за растрату бисерного фонда :)

Сниксника пора судить за стрельбу из пушек по воробьям. Не каждая задача требует абсолютной оптимизации.

Особенно когда эта оптимизация утяжеляет решение в разы...

Не давая никакого практического выигрыша.

> [28] OtherSie   (25.04.09 16:44)

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

Удалено модератором

Удалено модератором

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

явными хорошо, если ты уже знаешь оптимальный план.

А вот если ты его подбираешь, то частенько вылезает необходимость поменять порядок обхода таблиц. С явными джойнами надо запрос посильнее править.
Да и букав писать больше.
У явных джойнов мне нравятся 2 вещи :
1) Больше вариантов объединения (правда "лишние" варианты весьма экзотические и фулл оутер я всего раз в жизни применял на практике).
2) Труднее забыть про связки и нарваться на картезиан.

> С явными джойнами надо запрос посильнее править.
> Да и букав писать больше.
скопипастить 40 символов намного труднее чем 10?

> 1) Больше вариантов объединения
?
вообще то от синтаксиса конкретного sql сервера зависит, например когда то в первисиве не было синтаксиса явных объединений, но никаких ограничений на их варианты не было, лефт джойн делался += , райт =+ , полное объединение * (или *= с любой стороны, не помню).

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

> sniknik  (27.04.2009 10:25:35)  [35]

Что там первисив, в Оракле не было.

А я до сих пор в оракле (+) пишу - оно как-то понятнее и серверу и мне и моим коллегам

> А я до сих пор в оракле (+) пишу - оно как-то понятнее и
> серверу и мне и моим коллегам

Вот и я о том же.


> скопипастить 40 символов намного труднее чем 10?

Если у меня хинт ordered и я начинаю играть порядком обхода, то при неявном объединении мне надо будет только поменять местами таблицы во фроме (вырезать+вставить). А при явном - переделывать текст запроса.

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

>Игорь Шевченко ©   (27.04.09 12:02) [37]
>А я до сих пор в оракле (+) пишу - оно как-то понятнее и серверу и мне и моим коллегам
так, вообще говоря, (+) не эквивалентен left/right outer join
да и (+)-синтаксис при необходимости full outer join не слишком спасает)