Pull to refresh

Comments 35

Следующие две части будут посвящены подзапросам, Join'ам и специальным операторам.

  1. У вас секция с объединениями в первую часть скопировалась.
  2. Ну и если у вас в тегах указано SQLite, то неплохо бы сказать, что он не все виды объединений, определённых в стандарте, поддерживает, см. «SQL Features That SQLite Does Not Implement», а также что в этом случае делать.
1. Да, действительно, выбрал тактику и стоило ее придерживаться) Здесь решил в итоге добавить короткую секцию, чтобы совсем новичкам было, с чем играться, пока ожидаю модерации и пишу вторую часть статьи
2. Это правда, в следующей части постараюсь осветить это)

Не совсем в тему, но моего хорошего знакомого, который давно и успешно рулит всякими oracle bd, тоже зовут Александр Соколов. А я, хоть и не Александр, но тоже sql-программист и тоже Соколов… Скажите, а как вас затянуло на эту тернистую дорожку из бизнес-анализа?

Александр Соколов очень распространенная комбинация имя-фамилия, полных тезок за жизнь встречал дважды, если не считать просто Александров Соколовых)

Я пользуюсь sql исключительно для выгрузок и витрин. Самой простой пример из последнего: формирования витрины данных жалоб с сайта для формирования дашборда по динамике NPS, количеству жалоб и пр.
Дорожка действительно тернистая, особенно когда вынужден использовать одновременно PL/SQL, MySQL
Если бы вы оба были Мухаммеды Соколовы, то это было бы странно.
Соколов — очень распространённая фамилия, а Александр — имя. Меня вот тоже Александром зовут. Но я Орлов.

Все просто только пока дело не доходит до запросов с переподвыподвертом
А уж когда нужно чтобы это ещё и работало быстро…
Это я к чему собственно
Учебников по элементарному sql в интернете навалом. Ещё один ничего не изменит.
Лучше напишите о интересных и сложных случаях применения, может кому-нибудь пригодится.

Спасибо за замечание!
гайдов много, но я не встречал таких, которые а) короткие, б) содержат много примеров, в) сразу предлагают практику
Интересные примеры обязательно включу)

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

Про having правда)) В начале статьи я кратко описал общую структуру запроса, подумаю, как можно акцентировать внимание читателя на последовательности запроса
Самое интересное видимо будет, когда до лягушки дойдёте.
Пока начальная подготовка.
JOINs это НЕ пересечения множеств. Диаграммы Венна только все запутывают.
Сколько строк вернет следующий запрос?
with
  a as (
	select 1 x from dual
	union all
	select 1 x from dual
        )
, b as (
	select 1 x from dual
	union all
	select 1 x from dual
        )
select a.*, b.*
  from a inner join b on a.x = b.x

Can we stop with the SQL JOINs venn diagrams insanity?
Зачем эта статья? Чем она отличается от любой справки по SQL?
30-ти летней давности, заметим. Потому что на таком уровне изложения язык не отличается от того, каким он был в SQL/DS, к п
римеру
Моя ЦА: новички, студенты
Таргет: быстро, просто, с достаточным количеством примеров и практикой

Те справки, которые я встречал, не отвечали одновременно всем критериям, поэтому родилась эта статья)
Есть прекрасный учебник на SQL EX
www.sql-tutorial.ru/ru/book_simple_select_statement/page1.html
Быстро, просто, с примерами и практикой.

Немного старый, но отлично объясняющий основы учебник на SQL.ru
www.sql.ru/docs/sql/u_sql/ch3.shtml
Быстро, просто, с примерами и практикой.

Есть неплохой учебник на SQL Academy
sql-academy.ru/guide/syntax-sql-select
Быстро, просто, с примерами и практикой.

Я замечу, что всё это буквально на первой странице поисковой выдачи.

А теперь вы анонсировали ещё и «продолжение».

Почему, мистер Андерсон, почему? Во имя чего? Что вы делаете? Зачем продолжаете копипастить?

за мистера Андерсона не скажу, а за себя скажу)
вышеперечисленными учебниками я действительно пользовался, но они не отвечали моему критерию по затраченному времени и не всегда нравилась последовательность материала.
Я не просто так поставил тег «студентам» и, как уже писал выше, один из таргетов: скорость
но в любом случае спасибо! тем, кто захочет углубиться самостоятельно и имеет хороший запас времени, ресурсы будут действительно очень полезны)

Да ладно… А что-то типа Кодда не пробовали? Я не очень верю, что за более чем 30 лет не написан базовый учебник хорошего уровня. Не базовый — верю, хотя бы по причине различий в диалектах, но по той же причине в качестве основы сойдет учебник, описывающий любую СУБД — потому что отличия все равно потом придется изучать по справочнику.
Да, это это действительно опишу дальше
Для новичка и пользователя с доступом «чтение» написанное в статье — самое важное
Создание/удаление/добавление — чуть повыше уровнем, но в любом случае, это опишу
sokolov_alexr
Спасибо за пост!

У меня вопрос-предложение – будет ли в аналогичной подаче пост о работе с самой базой данных? На примере используемой вами системы (или системы, которая наиболее распространена для подобной работы): как подключиться к базе, как создать таблицу(-ы) / добавить или удалить столбцы и записи, связать таблицы между собой (один-ко-многим и т.д.). Такой средний (часто встречающийся) набор стандартных операций над базой помимо синтаксиса SQL. Крайне желательно, конечно, чтобы был интерактив – как в данном посте.

Жду обещанного продолжения.
Да, определенно!
Либо включу в одну из следующий частей, либо сделаю отдельный пост с разбором)

Спасибо за отзыв)
Есть ли ide для SQL кода с завершением? Чтобы писать начало команды а программа дополняла? Что бы форматировала код? И какие еще инструменты для ускорения и упрощения работы есть?
UFO just landed and posted this here
dbForge хороший и бесплатный
Спасибо! Помочь новичкам и было моей основной целью)
Мне, как начинающему, этот материал оказался полезен.

Эээ… Это попытка пересказать "Понимание SQL" М.Грабера???

Это пересказ собственных знаний в сжатом (и немного урезанном) виде для новичков)
Про типы запросов уже сказано. Из «ещё» — не нравится описание JOIN, во-первых, потому, что он не там, где надо (а должен он быть подразделом FROM), во-вторых, потому, что, мягко говоря, привирает — то, что названо ключом, запросто может ссылаться на третьи таблицы и/или скалярные данные. HAVING (в тегах указано MySQL) порой используется и без агрегирования. Про CTE (совсем до) и оконные функции (совсем после) даже не говорю.

Но главным недостатком считаю следующее. Да, для того, кто вообще никогда и ни в чём не программил, сойдёт — вот только такой товарищ ничего не поймёт, текст предполагает наличие минимальных навыков программистского мышления. А для того, кто уже программировал, упущена очень важная необходимость «сломать мышление». В программировании надо думать итерациями (выбираем по одному то, что подходит), а в SQL надо наоборот, думать множествами (сваливаем всё в кучу, а потом выбрасываем то, что не подходит). Если этого не сделать — мозг начинает порождать сонмы сто лет ненужных коррелированных подзапросов, в которых чёрт ногу сломит.
Спасибо за развернутый фидбек!
СТЕ и оконные функции здесь намеренно не рассматривал, чтобы не запутать вливающегося новичка, об этом имхо лучше говорить, когда есть база в голове.
Насчет «ничего не поймет» не соглашусь, перед написанием статьи я давал этот материал кусочно в личных сообщениях и вживую людям, которые была далеки от программирования в принципе и получал положительную обратную связь, что, собственно, и подтолкнуло к тому, чтобы написать статью.
Насчет HAVING хорошее замечание, вы правы, внесу правку, спасибо!
Спасибо большое! Бальзам на душу от таких отзывов))
Sign up to leave a comment.

Articles