Выборка из одной таблицы в SQL

[Dana]

Код:

select cl.C_FIRST_NAME, cl.C_SECOND_NAME, cl.C_LAST_NAME, ci.C_CITY, sx.C_SEX, st.C_STREET, cl.C_HOUSE, cl.N_FLAT, cl.N_PHONE   
from client cl, sex sx, street st, city ci
where cl.N_SEX = sx.N_SEX(+)
--and cl.N_CITY = ci.N_CITY (+)
and cl.N_STREET = st.N_STREET(+)
--and cl.C_HOUSE = cl.C_HOUSE(+)
--and cl.N_FLAT = cl.N_FLAT (+)
--and cl.N_PHONE = cl.N_PHONE (+)

Для чего "+" я еще могу догадаться, а вот насчет "--" я не знала. Что это значит?
Анализ:
1.select cl.C_FIRST_NAME, cl.C_SECOND_NAME, cl.C_LAST_NAME, ci.C_CITY, sx.C_SEX, st.C_STREET, cl.C_HOUSE, cl.N_FLAT, cl.N_PHONE - здесь пишем все что хотим увидеть в нашей выводе.
2. from client cl, sex sx, street st, city ci - здесь пишет таблицы откуда брать данные (приводя их в более короткий вид для удобства)
3. where cl.N_SEX = sx.N_SEX(+) - значит в табл. клиент идентификатор пола равен идентификатору пола в таблице sex. (+) обозначает таблицу, дополняемую NULL-значениями до полного соответствия другой. Ну и так далее..

Правильно проанализировала?

[McZim]

Dana, в общем правильно. "--" это символы коментария в sql. Так как я не знаю как называются таблицы для сравнения с таблице client, я их обозначил но не выполняю ничего! Тебе нужно переписать запрос.

Так же тебе нужно определиться как выодить информацию, нужны тебе строки если в них хоть одно значение NULL?

И не нужно догадываться для чего "+", нужно почитать про это и точно знать для чего и как применять!

[Sla]

Про + - читать про реализацию join в оракле

[RXL]

Вместо плюсов лучше на стандартных внешних объединениях рассказывайте. Оракле - не единственная СУБД.
LEFT [OUTER] JOIN
RIGHT [OUTER] JOIN

[McZim]

RXL, Если она работает с Oracle, и препод дал задание под эту БД, давайте будем юзать нотацию оной!

[RXL]

McZim, данная запись с плюсами устаревшая, сохраненная для совместимости. Стандартная запись - JOIN-ами.

[McZim]

RXL, ты ошибаешься, и очень сильно!

[Dimka]

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

[McZim]

Dimka,  а никто и не спорит что по стандарту JOIN. Про выгоду спорно! Я вообще сторонник того, если ты используешь продукт, то используй его фишки, а не стандартные!

Это все флейм ик теме не относится? прошу модератора потереть!

[Sla]

Это все флейм ик теме не относится? прошу модератора потереть!

Ни за что
Это дополнительные знания для ТС и плюс толчок к размышлению.

[Dimka]

Про выгоду спорно! Я вообще сторонник того, если ты используешь продукт, то используй его фишки, а не стандартные!

Ну так озвуч выгоду. Я пока не вижу ничего спорного в том, что (+) и JOIN делают одно и то же. Если так, то нет никаких оправданий уклонениям от стандарта.

[RXL]

Макс, в чем я ошибаюсь? Что утверждаю, что синтаксис с плюсами - устаревшая нотация?

[McZim]

RXL, Да.
Dimka, Про выгоду ты сам написал а не я! И именно про ту выгоду, которую ты не получишь при использовании нотации оракла, я и написал, что это спорно!

[Dimka]

И именно про ту выгоду, которую ты не получишь при использовании нотации оракла, я и написал, что это спорно!

По-моему все тебя поняли однозначно. Я сказал, что выгоды не будет. Ты сказал, что это спорно. Если есть аргументы, если ты знаешь какую-то выгоду и имеешь основания спорить - приводи аргументы. Иначе нет у тебя никаких аргументов, и ничего спорного в моём утверждении тоже нет.

[RXL]

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

1. Нотация Оракла появилась раньше, чем стандартная. Сейчас и уже давно Оракл поддерживает стандартную форму. Эту форму поддерживают практически все СУБД. Нет смысла придерживаться специфического синтаксиса, если тоже самое можно получить с помощью общепринятого.

2. Эта форма не информативна, в отличии от стандартной. Не сложно запутаться, кто к кому подключается, а с JOIN это невозможно.

Код:

-- Два итога в четырех вариантах

  t2.parent_id (+)= t1.id

  t2.parent_id =(+) t1.id

  t1.id (+)= t2.parent_id

  t1.id =(+) t2.parent_id

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

4. Не все, доступное в блоке ON, можно сделать с плюсами. Скажи, сможешь ли ты сделать без помощи JOIN такую оптимизацию (проверял - есть существенная разница при работе с неуникальными ключами)?

Код:

-- Исходный вариант
SELECT ...
FROM t1
   LEFT JOIN t2 ON t2.f1 = t1.f1

-- Оптимизированный вариант
SELECT ...
FROM t1
   LEFT JOIN t2 ON t2.f1 = t1.f1 AND t1.f1 IS NOT NULL

[McZim]

RXL, какраз оракл говорит что JOIN они поддерживают только ради того что бы соответствовать стандарту, а вот свои нотации настоятельно рекомендуют использовать. При этом конечно же можно пользовать JOIN, и это тоже будет верно!

4 пунктя не понял что ты хотел сказать?

Да, и то что нотация соединений появилась у оракла раньше стандарта, это ни о чем не говорит, реализация по стандарту ни чем не лучше и не хуже!

Dimka, все что я говорю это мое мнение. Я незнаю что вы там ВСЕ однозначно поняли, я лишь говорю о том что если тебе нравится писать по стандарту или например не по стандарту, то не нужно это навязывать начинающим! Аргументы таковы.

1. Знать как в оракле, родными средствами сделать соединения, не используя стандарт. Некоторые товарищи любят это спрашивать на собеседованиях, я не считаю это верным, но знать считаю надо!

2. Рома, постом выше сказал что JOIN ему понятнее а в (+)ах можно запутаться, так вот основная выгода для меня это какраз читаемость запросов, мне гораздо проще писать и читать на (+)ах, чем на JOINах.

Парни, мы с вами спорим "ниочем",  каждый из нас прав. На вкус и цвет все фломастеры разные!

[RXL]

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

Что же не понятного? Добавил в ON условия для главной таблицы. Давай напишу иначе:

Код:

SELECT ...
FROM tab_main tm
    LEFT JOIN tab_1 t1 ON t1.parent = tm.id AND tm.filter = 1
    LEFT JOIN tab_2 t2 ON t2.parent = tm.id AND tm.filter = 2
    LEFT JOIN tab_3 t3 ON t3.parent = tm.id AND tm.filter = 3
...

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

Переведи, пожалуйста, ее в родную форму Оракла.

[McZim]

Код:

SELECT ...
FROM tab_main tm, tab_1 t1
WHERE tm.id = t1.parent(+)
AND tm.filter = 3
UNION
SELECT ...
FROM tab_main tm, tab_2 t2
WHERE tm.id = t2.parent(+)
AND tm.filter = 2
UNION
SELECT ...
FROM tab_main tm, tab_3 t3
WHERE tm.id = t3.parent(+)
AND tm.filter = 3

[RXL]

UNION - это очень плохо.
Представь себе запрос на пару кБ SQL-текста с десятком таблиц. Из-за одной нелюбви к JOIN он увеличится в несколько раз и во много раз медленней будет работать.

[McZim]

RXL, ты попросил переписать твой конкретный пример, я не говорю что этот метод я бы применил для решения конкретной задачи. Хотя в полне уверен что он может обогнать и JOIN в ряде случаев, все зависит от задачи, требований и много еще от чего. Кстате UNION - это не плохо, если бы он был так плох его бы не было вовсе!!! По оптимизации можем пообщаться отдельно!

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

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

Конец дискуссии!!!

[RXL]

Макс, не подумай, что я к тебе придираюсь, но решение в посте 86 - не повод строго придерживаться "плюсов".

Код:

SELECT t1.field, t2.field, t3.field, ...
FROM tab_main tm
    LEFT JOIN tab_1 t1 ON t1.parent = tm.id AND tm.filter = 1
    LEFT JOIN tab_2 t2 ON t2.parent = tm.id AND tm.filter = 2
    LEFT JOIN tab_3 t3 ON t3.parent = tm.id AND tm.filter = 3
...

Это через UNION не реализуется. Да, можно UNION убрать в подзапрос, но получается очень громоздко. Встречаются запросы еще сложнее.

[McZim]

RXL, а я и не спорю я видимо как-то криво объясняю, раз меня не поняли.

[Dimka]

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

1. Знать как в оракле, родными средствами сделать соединения, не используя стандарт. Некоторые товарищи любят это спрашивать на собеседованиях, я не считаю это верным, но знать считаю надо!

2. Рома, постом выше сказал что JOIN ему понятнее а в (+)ах можно запутаться, так вот основная выгода для меня это какраз читаемость запросов, мне гораздо проще писать и читать на (+)ах, чем на JOINах.

Парни, мы с вами спорим "ниочем",  каждый из нас прав. На вкус и цвет все фломастеры разные!

А дело не во фломастерах. Дело в наличии стандарта и в культуре инженерных решений. Причём эта культура - тоже не "фломастер", а имеет вполне конкретную экономическую основу. Написанный по стандарту код понятен более широкому кругу разработчиков, проще переносим между платформами, независим от версий тех или иных продуктов - всё это снижает издержки промышленного производства ПО. Любой стандарт, а особенно национального или международного уровня, проходит экспертизу своей полезности: издержки по экономике от его использования ниже суммы издержек отдельных производителей на его исполнение.

И тем более, если речь идёт о начинающих, важно, чтобы они в первую очередь знали стандартные средства.


Теперь о JOIN'ах.

Как правильно заметил RXL, JOIN конструкции позволяют указать порядок связывания таблиц и явным образом прописать связи. При этом мало того, что бывают INNER, LEFT OUTER, RIGHT OUTER, FULL OUTER и CROSS JOIN'ы, выражения:

Код: (SQL)

SELECT *
FROM
  T1
    LEFT JOIN T2 ON T1.T1ID = T2.T1ID
    JOIN T3 ON T2.T2ID = T3.T2ID
    RIGHT JOIN T4 ON T3.T3ID = T4.T3ID

и

Код: (SQL)

SELECT *
FROM
  T1
    LEFT JOIN T2
      JOIN T3 ON T2.T2ID = T3.T2ID
      RIGHT JOIN T4 ON T3.T3ID = T4.T3ID
    ON T1.T1ID = T2.T1ID

Могут различаться как по скорости работы, так и по содержанию.

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

Именно поэтому JOIN'ы и включены в стандарт как результат широкого консенсуса по вопросу о том, как удобнее и лучше осуществлять данные реляционные вычисления.

Некоторые товарищи любят это спрашивать на собеседованиях

Ради такого можно полистать книжку, если достался на сопровождение старый код. Товарищи, упирающие на то, что человек, умеющий писать запросы, хранимки, понимающий схемы, особенности работы с представлениями, транзакциями и т.д., не знающий один лишь (+), у них работать не может, идут лесом - это несерьёзная контора с некомпетентным начальником IT. Человек, знающий (+), и не знающий всего остального, тоже идёт лесом.

[McZim]

А дело не во фломастерах. Дело в наличии стандарта и в культуре инженерных решений. Причём эта культура - тоже не "фломастер", а имеет вполне конкретную экономическую основу. Написанный по стандарту код понятен более широкому кругу разработчиков, проще переносим между платформами, независим от версий тех или иных продуктов - всё это снижает издержки промышленного производства ПО. Любой стандарт, а особенно национального или международного уровня, проходит экспертизу своей полезности: издержки по экономике от его использования ниже суммы издержек отдельных производителей на его исполнение.

И тем более, если речь идёт о начинающих, важно, чтобы они в первую очередь знали стандартные средства.

Есть моменты когда и стандарты не удовлетворяют бизнес требованиям. Что касается переносимости кода, то считаю проще спроектировать все заново, чем например, перенести логику с оракла на sqllite. Это не всегда верное утверждение, прошу не разводить полемику. Что касается прогеров которым не понятна конструкция (+), как ты сам заметил, идут они лесом!

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

Именно поэтому JOIN'ы и включены в стандарт как результат широкого консенсуса по вопросу о том, как удобнее и лучше осуществлять данные реляционные вычисления.

Оптимальнее всего на этапе проектирования создать схему так, что бы не делать плясок с бубном вроде сложных JOIN'ов

Ради такого можно полистать книжку, если достался на сопровождение старый код. Товарищи, упирающие на то, что человек, умеющий писать запросы, хранимки, понимающий схемы, особенности работы с представлениями, транзакциями и т.д., не знающий один лишь (+), у них работать не может, идут лесом - это несерьёзная контора с некомпетентным начальником IT. Человек, знающий (+), и не знающий всего остального, тоже идёт лесом.

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

Позволю себе еще раз сказать. Я не отстаиваю того что всегда и везде нужно применять (+) вместо JOIN. Я привел решение для автора топика используя именно (+) только потому что мне с ними удобнее работать чем с JOIN. На (+)ах и UNION'ах написал запрос только потому что этого попросил RXL.

Естественно, когда речь заходит о производственном коде, то там рассматриваются ВСЕ возможные и не возможные варианты, и там, как вы сами понимаете, дело не ограничивается выбором JOIN'а или (+)'а, и уж тем более не стоит задача написать все по стандарту. Очень часто встречал когда собственные реализации гораздо выгоднее чем те, что предписывает стандарт.

[Dimka]

Есть моменты когда и стандарты не удовлетворяют бизнес требованиям.

Ну уж к (+) это никак не относится

Что касается переносимости кода, то считаю проще спроектировать все заново, чем например, перенести логику с оракла на sqllite.

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

Что касается прогеров которым не понятна конструкция (+), как ты сам заметил, идут они лесом!

Вообще-то я этого не замечал, я сказал наоборот

Оптимальнее всего на этапе проектирования создать схему так, что бы не делать плясок с бубном вроде сложных JOIN'ов

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

Я не отстаиваю того что всегда и везде нужно применять (+) вместо JOIN.

А я отстаиваю мнение о том, что всегда и везде нужно применять JOIN вместо (+) при написании нового кода, если иное не оговорено в стандарте предприятия.

Естественно, когда речь заходит о производственном коде, то там рассматриваются ВСЕ возможные и не возможные варианты, и там, как вы сами понимаете, дело не ограничивается выбором JOIN'а или (+)'а, и уж тем более не стоит задача написать все по стандарту.

Отнюдь неестественно. При промышленном производстве ПО задача писать по стандарту (хотя бы стандарту предприятия, соглашению о кодировании) стоит в первую очередь. Без этого все пишут "кто в лес, кто по дрова", и собранное вместе решение нередко не работает или сильно глючит, а продуктивное время разработчиков тратится на бесконечные совещания и разборки в попытках выяснить, кто что имел в виду, и кто что как понял, и почему так сделал.

Очень часто встречал когда собственные реализации гораздо выгоднее чем те, что предписывает стандарт.

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

[McZim]

Вообще-то я этого не замечал, я сказал наоборот

Это я к тому что нужно знать и то и другое и уметь применять!

А я отстаиваю мнение о том, что всегда и везде нужно применять JOIN вместо (+) при написании нового кода, если иное не оговорено в стандарте предприятия.

Ты хочешь сказать что если я работаю с ораклом и использую (+), если мне этого хватает для покрытия бизнес требований, то я плохой инженер и пишу "говонокод"?

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

Ты знаешь, есть программисты у которых все по стандарту, да только все работает в зависимости от погоды на марсе. Я немного не так выразился, да в больших конторах, которые зарабатывают на жизнь разработкой ПО, эти стандарты должны быть на каждом шагу, как собственные так и общепринятые. Но в тех конторках, которые пишут что то для себя, это совсем не обязательно. Вот например в нашей конторе есть самописная CRM, с точки зрения БД, там очень много недочетов и просчетов. Где то по правилам создана таблица (я имею ввиду НФ), но характер работ с этой таблицей таков что там не нужна нормализация. Вот именно это я и имею ввиду. Я никогда не работал в конторах занимающихся разработкой на должности программиста, возможно поэтому у меня такое суждение, потому как когда ты разрабатываешь ты не знаешь что конкретному заказчику нужно будет привести некоторые таблицы к ненормальной форме, и делаешь все по стандарту! Скажу так, мы купили биллинг и схему БД я переделываю под наши бизнес требования, производительность растет в разы!

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

Оператор UPDATE в Oracle полностью соответствует требованиям начального уровня ANSI SQL. Однако имеются некоторые дополнительные возможности.

1. использование табличных алиасов для ссылок на обновляемую таблицу в подзапросах
2. подзапросы в правой части предложения SET в отличие от только выражений в ANSI SQL
3. список обновляемых колонок в левой части предложения SET, в отличии от одной колонки в ANSI SQL
4. подзапросы в предложении SET или WHERE могут ссылаться на обновляемую таблицу
5. Оператор UPDATE поддерживает обновление подзапросов

[RXL]

Макс, вот тебе пример из жизни. Что можно я в нем обрезал.

Такое поддается переводу в плюсовую запись?

Код:

SELECT ...
FROM db2.ORDERS_HISTORY oh, db2.ORDERS o
    LEFT JOIN db2.ORDER_FLOW_CTRL_HISTORY ofch ON (
        ofch.ORDER_ID = o.ORDER_ID
        AND ofch.HIST_ID = db2.GET_ORDER_FLOW_CTRL_LAST_ID_(o.ORDER_ID, 0, 0)
    )
    LEFT JOIN db2.HISTORY h ON (
        h.HIST_ID = ofch.HIST_ID
    )
    LEFT JOIN db1.JOBCARDS jc ON (
        jc.JOBCARDNR = o.IBS_JOBCARDNR
        AND o.IBS_JOBCARDNR IS NOT NULL
        AND o.IBS_JOBCARDORDER_TYPE = 1
    )
    LEFT JOIN db1.NEWORDHD no ON (
        no.OHORDERNR = o.IBS_JOBCARDNR
        AND o.IBS_JOBCARDNR IS NOT NULL
        AND o.IBS_JOBCARDORDER_TYPE = 2
    )
    LEFT JOIN db2.ADDRESS ad ON (
        ad.BUILD_ID = o.BUILD_ID
        AND o.BUILD_ID != 0
    )
    LEFT JOIN db1.SUBSCRIB s ON (
        s.CUCUSTNR = o.IBS
        AND o.IBS != 0
    )
WHERE o.RASP_ID = :RASP_ID
    AND oh.ORDER_ID = o.ORDER_ID
    AND oh.EVENT_ID = 15;

Да, база ужасна. Их тут две. Много разработчиков-одиночек, много модификаций, много "оставлено для совместимости". Но делать с нуля нельзя - это жуткие трудозатраты.

В данном запросе важно время выполнения.

[Алексей++]

Ром, тег code под катом вообще нечитабельный - две с половиной строчки умещается

И, что странно, в форме ответа (когда снизу предыдущие посты видно) - там тег работает как обычно, показывается много строк

[Dana]

Вот дискуссия то!
Я сделала так:

Код:

select client.*, sex.*, street.*
FROM
client,street,sex
WHERE
client.n_sex = sex.n_sex
and client.n_street = street.n_street

с JOIN вообще не представляю как формировать запрос. Одна из таблиц должна быть главной (для меня они все главные):

Код:

select client.*, sex.*, street.*
FROM
client,street,sex
FULL other JOIN client ON client.n_sex = sex.n_sex
and client.n_street = street.n_street

[McZim]

Я сделала так:

ты собственно и сделала соединение, только внутренее.

Добавлено через 25 минут и 48 секунд:
RXL, скажи, как часто выполняется такой запрос, сколько по времени, что при этом "поедает"? Можешь в кратце описать профиль ресурсов для данного зароса?