Форум MySQL

что за зверь такой - самообъединение?

ну когда выборку из таблицы по средствам JOIN объединяют с другой выборкой из этой же таблицы
или я загоняюсь уже?
Кстати, приятного аппетита)

Используется такой термин в русскоязычной литературе, как раз как это описывает Valick.

Я могу предположить лишь кривую кальку с английского self-joined table (tbl AS t1 JOIN tbl AS t2), но не представляю как в этом примере такую конструкцию можно применить.

Кривакя калька потому, что применять термин объединение для операции JOIN неправильно.
Неправильно, некорректно, неудобно наконец. Так как термин этот уже нагружен операцией UNION - совсем другой табличной операцией. А для JOIN есть термин соединение.
-

намёк понял
но вот как раз лично я бы назвал UNION соединением
постараюсь в будущем отказаться от этих русскоязычных терминов

но не представляю как в этом примере такую конструкцию можно применить

алиасы дать не самой таблице, а результатам выборки

Ребята, всем спасибо за участие. Как я понимаю, лучшее решение - с использовением БД.

Тепеь думаю о следующем: если сайт предполагает наличиие других "переводных" мест - может таблицу с переводами строк сделать универсальной, для всех случаев (т.е. не только для фоток)?

а что мешает?)

>Кривакя калька потому, что применять термин объединение для операции JOIN
>неправильно.
Тем не менее для JOIN везде последовательно используется термин объединение, если честно даже не нашел книг в своей библиотеке, где бы эта операция по другому бы называлась (первые попавшиеся книги по чистому SQL, PostgreSQL, MS SQL и MySQL говорят именно об объединении таблиц при использовании оператора JOIN, причем книги досточно старые - т.е. такая терминология давно уже прижилась).

Как Вы называете операцию UNION над таблицами ?

И как Вы называете операцию над множествами, результатом которой является множество, содержащее элементы всех своих операндов?

http://www.intuit.ru/department/database/sql/5/2.html
http://www.intuit.ru/department/database/sql/5/3.html

Собственно, мне как-то всё равно, сколько [переводов] книг использовало термин неудачно...
Изначально я интересовался, как автор идеи собирается прикрутить self-joined table к проблеме.
Ясности так и не увидел.

>Как Вы называете операцию UNION над таблицами ?
Объединением, как и авторы (вернее переводчики) других книг, первым делом это посмотрел.

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

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

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

Не жалеете?
Или Вы хотите сказать, что это было требование редактора?

>Не жалеете?
>Или Вы хотите сказать, что это было требование редактора?
Да нет, просто посмотрели как в других книгах принято обозначать операцию и использовали такую же терминологию. Собственно, сожаления никакого нет, как и по поводу того, что PHP получил распространение в РФ, а скажем не Java, Python или Ruby. Ну получил и получил, будем работать с тем, что есть.

union (cуществительное) - союз (объеденение)

join (cуществительное) - соединение с ..., объединение с ...
join (глагол) - присоединяться (присоеденить)

UNION используется для объединения результатов работы нескольких команд SELECT в один набор результатов. (из учебников)

А для JOIN как раз более подходит присоединение, так как тут речь идет о явной зависимости. Хотя это мое мнение, да и в MySQL учебниках просто бардак, и его изучать сложно....

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

>MySQL учебниках просто бардак
Это отпечаток очень мутной ранней документации раннего периода, пока за неё Дюбуа не взялся, в ней черт ногу мог сломать - обрывки сведений в перемешку с внутренней реализацией. Не должны разработчики документацию на интерфейсы составлять - у них голова другим забита (однако в свободном проекте обычно именно так и бывает - по сути ориентироваться в документации без знания другой базы данных было не возможно, в документации PHP ситуация тоже очень похожа).

Вообще-то да, но на мой взгляд в РНР проще, и даже для начинающего будет достаточно маула, если есть у него умение мыслить логически. А вот MySQL, это зачастую хорошие справочники, редко претендующие на звание Учебник.
Если проанализировать этот раздел, то большая часть вопросов как раз по выборке из базы, и казалось бы, все в "учебнике" есть, но вот чтобы научиться строить их так, как на вопросы отвечает, к примеру, Trianon, то эти учебники как раз и не должны страдать "обрывками сведений в перемешку с внутренней реализацией". А это таки и есть.

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

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

я как раз и имел ввиду все возможности одной базы, например MySQL :)

А я о чем? Мне иногда кажется, что Trianon родился уже с книжкой по MySQL в руках, причем с удачным учебником.... Есть у меня вроде бы хороший учебник, но PDF, а его содержимое это картинки, не шибко то хочется читать таковой.... Я о проблеме учебника, а не о часах проведенных за ним. ;-)

>Мне иногда кажется, что Trianon родился уже с книжкой по MySQL в руках
поддерживаю ;) Не раз этот человек выручал меня

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