Comments 63
Таблица Employees. Получить список всех сотрудников у которых длинна имени больше 4 букв
Решение
SELECT *
FROM employees
WHERE first_name LIKE '%____%';
Интересное решение.
Обычно использую прямо в лоб LENGTH(first_name) > 4 (как в другом примере здесь видел)
Какие есть преимущества у такого способа по сравнению с length?
И спасибо за задачки — очень интересно.
Данное решение здесь указано так потому что задача находится в теме «Restricting and Sorting Data», а предпологается что на этом этапе (это начало SQL) студент еще не знает о существовании функции length.
DedZamkad
SELECT *
FROM employees
WHERE first_name LIKE '%____%';
И так тоже не хорошо, т.к. из %% тоже получим сканирование индекса.
Вот так, при некотором везении, получим seek:
WHERE first_name LIKE '[А-Я][-''. А-Я][-''. А-Я][-''. А-Я]%'
Ну, конечно, тут придется еще дополнительно учесть регистр, если коллейшн регистрозависимый, и особенности хранения данных.
Например — грязь в виде лидирующих пробелов (чего быть не должно), пробелов, тире, точек, апострофов внутри составного имени ([-''. А-Я] — как раз учитывает это).
Впрочем, это всё для MSSQLSERVER,
:-)
Более того достаточно условия first_name LIKE '____%'
В Оракле для работы с датой используется функция TO_DATE. YEAR(DATE) — в оракле такого на сколько я знаю нет.
Схему базы можно взять тут
www.jetbrains.com/datagrip/features
пусть будет таблица ID родитель, остальные колонки — дети.
у детей могут быть дети в этой или другой таблице, и т.п.
выбрать всех детей родителя, так называемый субсет.
Интересно как сама БД реагирует на селект. Наивное решение было бы просмотреть все строки и выбрать нужные, но подозреваю там оптимизации в виде неких хешей вроде
значение поля -> все строки где это значение.
Таблица Employees. Получить список сотрудников менеджеры которых устроились на работу в январе месяце любого года и длинна job_title этих сотрудников больше 15ти символов
Не лучше ли требовать со студентов решение с JOIN-ами вместо подзапросов, приучать к хорошему стилю?
В идеале, студенты должны уметь преобразовывать запросы из одной формы в другую и обратно.
Работать ведь со всяким придется. Если научить только хорошему стилю, то при чтения запросов в плохом стиле, будут проблемы.
Такие задачки очень удобно решать в каком-нибудь конструкторе запросов, в MS Access, например. :)
На мой взгляд, тренироваться писать SQL запросы в конструкторе — зло. Это может быть и удобно чтобы порешать задачки, но на практическое применение переносится крайне плохо. Где будет ваш конструктор, когда вам нужно будет забрать данные по jdbc/odbc?
писать SQL запросы в конструкторе — зло
Так и запишем, Microsoft делает злые вещи.
тренироваться писать SQL запросы в конструкторе — зло
Наоборот, очень помогло по-быстрому освоить SQL.
Это может быть и удобно чтобы порешать задачки, но на практическое применение переносится крайне плохо.
В 90-x очень плотно работал с базами данными. Очень сильно помогало по-быстрому строить запросы и отчеты. Конструкторы запросов — это про быструю разработку.
Где будет ваш конструктор, когда вам нужно будет забрать данные по jdbc/odbc?
Рядом будет. В результатах работы конструктора мы имеет также и сам SQL запрос.
Конструкторы запросов — это про быструю разработку.
Когда печатаешь со скоростью речи, то сразу написать запрос получится быстрее, чем накликивать его мышкой в конструкторе.
Рядом будет. В результатах работы конструктора мы имеет также и сам SQL запрос.
Я правильно понимаю, что вы сразу используете тот запрос, который вам сгенерировал конструктор, и никак его не допиливаете?
Какой был самый сложный запрос, который вы писали?
Когда печатаешь со скоростью речи, то сразу написать запрос получится быстрее, чем накликивать его мышкой в конструкторе.
Какие-то простые запросы может и да. Несколько более сложные запросы проще накидать в конструкторе.
Я правильно понимаю, что вы сразу используете тот запрос, который вам сгенерировал конструктор, и никак его не допиливаете?
Нет, конечно-же, случай бывает разный. Иногда приходится экспериментировать.
Какой был самый сложный запрос, который вы писали?
Большой-большой секрет маленькой компании.
В начале освоения SQL конструктор очень хорошо помогал. Сейчас, кончено, и без конструктора могу. Конструктор еще помогал найти решения, о которых я бы даже и не подозревал зная только стандарт SQL. Что помогало строить запросы одной строчкой, без необходимости писать дополнительный код и выполнять несколько запросов, создавая лишнюю работу и лишний трафик между клиентом и сервером БД.
сразу написать запрос получится быстрее, чем накликивать его мышкой в конструкторе.не всегда :). Порой, всё же, быстрее накликать 15 таблиц, чтобы через внешние ключи из 3-х таблиц выбрать несколько столбцов, да ещё и с парой фильтров по связующим таблицам. Но, надо помнить, что конструктор придуман не для разработчиков. И запросы там могут быть не оптимальны.
Спасибо за статью.
Расскажите, вы намеренно собрали запросы с группировкой и с having в один раздел?
Как студенты справлялись с появлением сразу двух новых концепций?
Можете добавить, на каких примерах вы объясняли каждую из тем?
Я преподаю по официальной книге по подготовке к сертификации. И в ней having и group by в одной и теме. Они связаны, их лучше проходить вместе.
--Можете добавить, на каких примерах вы объясняли каждую из тем?
Так вот целью данной статьи и было показать какие задачи мы решаем со студентами по темам. Я разделил задачи по темам.
Ещё интересно, как проверяете решения?
Глазами смотрите в запрос или как-то более надёжно?
Что делаете, если у студента оригинальное решение?
Что если данных много и глазами проверить трудно?
И Rank обошли стороной.
И все статистические оконные функции, и outer/cross apply, да даже банального exists нет (а в главе Using Subqueries to Solve Queries точно есть задачи, которые удобнее и понятнее решать exists). Не увидел union/except/intersect.
Есть запросы, где разный регистр ключевых слов ("Reporting Aggregated Data Using the Group Functions" — первая задача)
В некоторых запросах учит откровенно плохому (мне глаз резануло WHERE TO_CHAR (hire_date, 'YYYY') = '2008')
Дальше просто лень перечислять.
Итого — так себе списочек.
EXISTS — задач нет, но добавлю в список.
union/except/intersect — это тема также идет после subqueries. Ее тоже добавлю.
Конечно задачи для новичков и тех кто учится SQL. Для человека опытного задачи могут показаться не интересными и не нужными. Предложите свой список. Было бы интересно глянуть
Совсем не понятно, почему это названо занимательными задачами.
Получается, что ваши студенты смогут найти решение любой из ваших задач в интернете просто загуглив условие?
Я попробовал на "Таблица Employees. Получить список сотрудников с самым длинным именем." и первая ссылка в выдаче — на эту статью.
--Запись со значением JOB_ID = 'IS_A_CLERK' будет выведена
не будет, так как не удовлетворяет условию
LENGTH (SUBSTR (job_id, INSTR (job_id, '_') + 1)) > 3--и со значением 'AA_BB_CC'
не будет выведена, так как не удовлетворяет обоим условиям
SELECT LENGTH (SUBSTR ('IS_A_CLERK', INSTR ('IS_A_CLERK', '_') + 1)) FROM DUAL;
SELECT LENGTH (SUBSTR ('AA_BB_CC', INSTR ('AA_BB_CC', '_') + 1)) FROM DUAL;По его же мнению значения
SELECT SUBSTR ('IS_A_CLERK', INSTR ('IS_A_CLERK', '_') + 1) FROM DUAL;
SELECT SUBSTR ('AA_BB_CC', INSTR ('AA_BB_CC', '_') + 1) FROM DUAL;Итого — оба значения будут выведены.
Мы предпологаем что в job_id всего один символ "_"Вот только Вы как-то забыли явно указать этот, несомненно важный, момент. А структурой данных, на которую Вы ссылаетесь, подобные ограничения не устанавливаются.
SELECT *
FROM employees
WHERE MOD (SUBSTR (phone_number, -1), 2) != 0
AND INSTR (phone_number,'.',1,3) = 0
AND INSTR (phone_number,'.',1,2) > 0;
SQL. Занимательные задачки