Comments 16
Из «не совсем» стандартного мне удобная нравится фишка с оператором
IN:select * from tab where (col1, col2) IN ( (1,2), (2,3), (1,3) )
Тоже часто использую такой формат условий для множеств состоящих из пар элементов.
Обычно либо в условиях:
Обычно либо в условиях:
select case when (1,2) in ((1,2),(2,3)) then 1 else 2 end as col1 from dual select * from dual
where (dummy, dummy) in (select dummy col1, dummy col2 from dual)
Зачем в order by clause проводить какие-либо вычисления, почему бы не вынести их в select где им самое место? Это как связывать таблицы через where а не через join — результат один, а человекочитаемость разная.
Как зачем? Чтобы избавиться от дополнительного уровня вложенности.
nicht verstehen, приведи пример
У меня есть такой пример, только он длинный очень.
Действительно, иногда надо, ох, очень специфический пример.
Ну например, есть геообъект, у него в характеристиках прописано, что он начинается на 100 километре, а закачивается на 200, а при этом внутри его точки имеют линейную дистанцию на встречу.
Вот в таких случаях мы используем ORDER BY line_coord*SIGN(KM_START-KM_END)
:)
Действительно, иногда надо, ох, очень специфический пример.
Ну например, есть геообъект, у него в характеристиках прописано, что он начинается на 100 километре, а закачивается на 200, а при этом внутри его точки имеют линейную дистанцию на встречу.
Вот в таких случаях мы используем ORDER BY line_coord*SIGN(KM_START-KM_END)
:)
Бывают разные специфические требования к порядку строк и выдаче данных. Предположим, что мы составляем отчет по клиентам, в отчете должно быть только ФИО и дата начала обслуживания, а отсортировать их нужно по «толщине кошелька», чтоб руководство сразу видело, кто им больше люб. «Толщина кошелька» вычисляется по нескольким полям с помощью формулы.
Тогда вы либо вводите «толщину кошелька» как еще одно поле в select и потом из полученных данных делаете еще одну выборку уже без этого поля (т.е. как писали выше, получаете дополнительный уровень вложенности), либо сразу используете формулу в order by.
На самом деле всяко бывает, например, может сложиться ситуация, когда ФИО целиком лежит в одной колонке и его нужно вывести, а сортировка должна быть по имени. Тогда вы в order by используете substr, не забивая результирующую выборку ненужным полем с именем.
Тогда вы либо вводите «толщину кошелька» как еще одно поле в select и потом из полученных данных делаете еще одну выборку уже без этого поля (т.е. как писали выше, получаете дополнительный уровень вложенности), либо сразу используете формулу в order by.
На самом деле всяко бывает, например, может сложиться ситуация, когда ФИО целиком лежит в одной колонке и его нужно вывести, а сортировка должна быть по имени. Тогда вы в order by используете substr, не забивая результирующую выборку ненужным полем с именем.
Union all не сортирует строки объединяемых множеств (в отличии от union)
Блеать!!!
Садитесь два!
Ни union, ни UNION ALL не сортируют!
Назад в школу, читать теорию множеств!
Proof: Возьмите многопроцессорную тачку с включенным PQ и большими таблицами в запросах, и посмотри, где будет твоя сортировка!
Блеать!!!
Садитесь два!
Ни union, ни UNION ALL не сортируют!
Назад в школу, читать теорию множеств!
Proof: Возьмите многопроцессорную тачку с включенным PQ и большими таблицами в запросах, и посмотри, где будет твоя сортировка!
Особенно вредно писать про UNION и сортировку для новичков, ибо потом эта уверенность сильно бьет по голове.
+1!
еще group by не сортирует — это тоже частое заблуждение.
еще group by не сортирует — это тоже частое заблуждение.
ну и union all не сохраняет порядок объединяемых множеств, на это тоже нельзя закладываться.
Да, действительно, фраза про union написана так, что может быть прочитана двояко. Я имел ввиду механику работы union, когда для построения объединения множеств они вначале сортируются, и не подразумевал, что union может вернуть отсортированный результат и заменить таким образом order by.
Про «union all гарантирует сохранение исходного порядка строк» я имел ввиду, что при объединении множества А с множеством В в результирующей выборке будут идти сначала строки из множества А, потом из множества В. Сам порядок выдачи строк начиная то ли с 10-ки, то ли даже раньше, Оракл не гарантирует (из обычного select), что уж говорить про union all.
Поскольку в примере, к которому относится эта фраза, каждое множество было представлено одной строкой, то union all гарантировал сохранение этого порядка строк :) В общем, тоже весьма двояко написал, впредь постараюсь точнее излагать.
Про «union all гарантирует сохранение исходного порядка строк» я имел ввиду, что при объединении множества А с множеством В в результирующей выборке будут идти сначала строки из множества А, потом из множества В. Сам порядок выдачи строк начиная то ли с 10-ки, то ли даже раньше, Оракл не гарантирует (из обычного select), что уж говорить про union all.
Поскольку в примере, к которому относится эта фраза, каждое множество было представлено одной строкой, то union all гарантировал сохранение этого порядка строк :) В общем, тоже весьма двояко написал, впредь постараюсь точнее излагать.
бить тряпкой за такой код кроме секции демонстрация возможностей
+1 от всего сердца — жаль что уже вечер — такое нужно утром читать =)
Sign up to leave a comment.
Некоторые примеры нестандартных возможностей синтаксиса Oracle SQL