Comments 57
Сегодня SQL является одним из наиболее распространенных языков для работы с реляционными базами данных
Кстати, AWS DynamoDB, которая, по сути является хранилищем пар ключ-значение, тоже поддерживает SQL (PartyQL)
Собеседую тестировщиков: никто не знает sql, изредка рассказывают, что в pgadmin есть возможность показать данные. Печально.
еще бы про access спрашивал
Собеседуй аналитиков)))
так это вопрос не к тестировщикам, а к доступам, которые им дают, и задачам. Есть доступ к БД - будет и прокачка. Нет доступов, теория ненужная всегда забывается
У меня лично в период работы тестером sql никак не использовался, а вот в саппорте до этого и сейчас в аналитике - да.
было ровно таким же тестировщиком - ничего не знал про php, js и sql
п.с: как только узнал минимум, достаточный для самоуверенности - ушёл в веб-раработку)
Неделя 3: Создание и изменение таблиц
Изучение команды CREATE TABLE для создания новых таблиц
Неделя 5: Основы баз данных
Изучение концепций баз данных, таких как первичные и внешние ключи
Изучение команды CREATE DATABASE для создания новой базы данных
Как-то у вас телега впереди лошади стоит...
На самом деле - вполне нормально. Сначала показывается основная суть - т.е. для чего собственно всё это нужно, а потом уже разбирается - как оно устроено.
Иначе, если начать с самого-самого начала, то половина материала будет просто проходить мимо, т.к. непонятно к чему всё это.
Как минимум, понятие "первичный ключ" должно изучаться там же, где и CREATE TABLE. А понятие "внешний ключ" — там же, где JOIN'ы. А слово из трёх букв (я про USE) вообще не заслуживает отдельного топика.
а индексы изучать сразу вместе с where..
На самом деле, абстрактный sql имеет право на существование без индексов, ключей и прочих ограничений.
Индексы, ключи и прочие планы исполнения это нюансы реализации и приятное дополнение для ускорения, оптимизации и минимизации ошибок.
Какая-нить карманная база данных на две с половиной таблицы может всего этого не иметь, но запросы sql с join и where, при этом - выполнять.
Если уж на то пошло, надо в таком порядке изучать (а то как делать select, если у нас ничего еще нет):
CREATE DATABASE
CREATE TABLE
INSERT
SELECT
Всё остальное
В свое время весьма понравилась книга В. Волк "Базы данных". В первую очередь понравилась тем, что не растянута на тысячи страниц, а необходимый минимум при этом описан коротко, понятно и с примерами.
Чтобы плавать нужно плавать, а не планировать плавание. Хорошенько поплавать можно на старом добром sql-ex. Гуглите сами, не реклама. В свое время мне пару недель sql-ex понадобилось, чтобы уверенно пройти собес.
sql-ex это бомба для новичка в SQL !
Задачи, которые нельзя решить с наскока, в неидеальных базах... Снимаю шляпу перед создателем этого ресурса! Получение сертификата хотя бы первого уровня оставит в голове железобетонные знания SQL и DML. Так что я бы перечеркнул весь приведённый план и оставил в нём одну строчку: sql-ex, больше ничего и не нужно.
Замечательный сайт для понимания SQL. Но вряд ли для новичка. К нему нужно прийти уже имея знания. Это наверное, как олимпиадные задачи для школьников. Когда есть основы, то очень интересно и полезно. А про неидеальные базы - мягко сказано.
Я пришёл на sql-ex полным нулём в SQL, более 10 лет назад. Получил сертификат. В будущем, этот сертификат неплохо помогал на собеседованиях, когда речь заходила про SQL.
Это наверное, как олимпиадные задачи для школьников
В том-то и дело, что нет. Олимпиадные задачи ровно как и всяческий литкод - это всегда оторванность от реальности и фокус на академических скиллах. SQL EX учит буквально тому, что обычный разработчик делает каждый день.
Хмм. Спасибо за рекомендацию и пинок под жопку!
За последние пару лет почти большая часть моего взаимодействия с БД строится через ОРМ. Понимание как устроены те или иные вещи осталось, а вот ручки забыли какие конкретно кнопки нажимать. Побродил по сайту, зарегистрировался. Стало больно 🥲
Однозначно Потыкаю еще.
К сожалению не всем доступен
SQL позволяет выполнять операции на создание, изменение и удаление таблиц и данных в них
Вы не правы. SQL не выполняет ничего из перечисленного.
Вы пишите про план изучения SQL, при этом зачем-то включаете в него DML (Insert/update/delete), DDL (create/alter/drop).
Тогда было было логично добавить ещё DCL(grant/revoke) и TCL (begin/commit/rollback/save).
Два месяца на всё это - это уже слишком оптимистично.
Согласно Wikipedia, это все SQL:
SQL consists of many types of statements,[6] which may be informally classed as sublanguages, commonly: a data query language (DQL),[a] a data definition language (DDL),[b] a data control language (DCL), and a data manipulation language (DML)
Вы имеете в виду тот самый Ямато — один из последних представителей класса военных кораблей, резко устаревшего с появлением авианосцев — бесславно погибший в столкновении с последними? :)
Статья, к сожалению, очень сырая. Совершенно классическая публикация вида "Я пишу плохо, потому что для новичков." Почему-то очевидная нелогичность этого утверждения всегда ускользает от wannabe писателей.
- Видно, что пункты в разделе Roadmap подбирались от балды, просто чтобы место заполнить. Неделя 5 — это какой-то винегрет: почему-то внешние ключи попали в "основы", и отдельно доставляет вдумчивое изучение команды USE. Видимо, меньше трех дней на неё отводить никак нельзя. Внешние ключи учим в одной неделе, а ограничения в другой. Хотя одно без другого смысла практически не имеет. В целом очень неровное и нелогичное распределение. Материал некоторых пунктов можно освоить за 5 минут, а некоторым и недели мало.
- Опять же, типичная проблема всех писателей-обучателей тому, что они сами знают очень поверхностно: список из 100500 пунктов, надерганных из интернета. Вместо того, чтобы приводить список из 15 ресурсов, и оставлять читателя в полном неведении — на какой, собственно, пойти учиться-то? — стоило привести 2-3, причем с оценкой из собственного опыта. Как правильно отметили выше, sql-ex почему-то на 11 месте, а наверху какой-то мусор, типа w3fools.
- Очень много трескучих фраз ни о чем. Здесь не партсобрание, никого агитировать не нужно. Если человек открыл эту статью, значит он уже интересуется изучением SQL.
Чтобы сделать из этого хорошую статью, надо переработать разделы Roadmap, Где учить и Книги, а также убрать агитацию.
В чем-то вы действительно оказались правы, спасибо, я приму вашу критику и изменю свое видение для будущих статей. Но вот насчет источников для изучения - я лишь представил большое количество ресурсов, а насчет sql-ex я думаю уже многие слышали. Даже плохая практика помогает улучшиться. С большинством того, что вы сказали в критику, я соглашусь, спасибо
Даже плохая практика помогает улучшиться.
Это какое-то странное утверждение. Да, помогает, если других вариантов нету, и человек учится на своих ошибках. Но здесь вы предлагаете "плохой" вариант как свою собственную рекомендацию, и это я понять не могу.
я лишь представил большое количество ресурсов
Понимаете какое дело, пользоваться гуглем на уровне запроса "изучение SQL онлайн" сейчас умеют даже дошкольники. И писать специальную статью на Хабр, чтобы скопировать в нее результат этого запроса, совсем не обязательно.
Я бы еще добавил книгу на русском языке: Проектирование реляционных баз данных (Джен Л. Харрингтон, 2006), издательство "Лори" - очень доступная книга для начинающих...
Изучение базовых концепций SQL, таких как таблицы, столбцы, строки и типы данных
эти концепции относятся скорее к теории БД, а не SQL. Вместе с остальными понятиями реляционных баз данных.
Вам, конечно виднее, но я бы не стал перескакивать на инструменты управления данными без понимания того (пусть и в общих чертах), почему и как эти данные организованны.
Да вот тоже, всегда считал что SQL и теория реляционных баз данных от Эдгара Кодда является первоосновой столбцов, таблиц, внешних ключей и прочего.. как-то в статье пропущено, но .. может уже так и надо?
Зашел в комментарии найти этот. Спасибо.
Вообще, странно учиться создавать базы данных при этом игнорируя в обучении хотя бы понятие нормализации. В долгосрочном плане научить человека создавать базы и таблицы в них, но не рассказать ему про нормальные формы, — так и получаются те ужасные монстры из баек про легаси.
А еще один момент, который на мой взгляд заслуживает внимание при обучении — подбор адекватных названий таблиц и столбцов. Хотя бы просто сообщить, что это важно.
А что за строки и почему они отдельно от типов данных?
Это круто
весьма ультимативный гайд на 2 месяца, конечно, не идеально - но для первой стати автора на хабре пойдет на твердую четвёрку
Хорошая подборка. В своё время я помогал другу "войтивайти", мы учили SQL по документации к Postgtress. Просто открываешь и идёшь все главы по порядку - хорошо написано, всё именно в том порядке что надо новичку и понятно. Даже ничего объяснять не пришлось - человек всё сам понимал. Нужно только добавить упражнения и практику.
На мой взгляд как-то странно на всё перечисленное отводить недели, когда это рассказывается и понимается за минуты, и потом постепенно впитывается по мере практики, за дни...
Есть ещё очень хороший бесплатный курс по sql на stepik
"Интерактивный тренажер по SQL"
Это по сути тренажёр, то есть обучение через практику написания sql запросов в редакторе, но теория там тоже есть, вообще очень удобно - прочитал теорию и сразу закрепил на практике. Плюс там сертификат можно получить.
Честно говоря никогда не понимал вот такого изучения по списку таких вещей как SQL, самое простое на мой взгляд попытаться сделать любое приложение (beckend, mobile) на любом языке, использующее базу данных, и учить именно то, что нужно для создания приоложения.
А уже потом можно смотреть более сложные вещи.
Вообще большинство идей SQL для знающего любой язык программирования — очень просты. Базовые Create table/ select/ update/ insert можно изучить за час, банально открыв какой-нибудь SQL developer и посмотреть как он генерит эти запросы.
Лучшая книга по SQL что я читал, это Ицик Бен-Ган, Основы T-SQL. Книга дает понимание как в принципе работают SQL запросы.
А нормальные формы теперь не изучают?
Sarcasm mode:
А кому они нужны? Все всё хранят в b/json виде.
Ровно до тех пор, пока не возникает задача не только хранить/отобразить, но ещё и посчитать в разрезе какой-то аналитики.
столько в универе убили времени на нормальные формы и предикаты ..... Нихрена не пригодиолось для практики на разных SQL ....
Ровно до тех пор, пока не возникает задача не только хранить/отобразить, но ещё и посчитать в разрезе какой-то аналитики.
А какие проблемы с подсчётом какой-то аналитики в Postgres по jsonb данным?
Если вам надо линейно обработать один и тот же датасет, то в принципе никаких. Аналитика, это когда в простейшем случае надо вывести список подразделений, которые выполнили план продаж, по jsonb данным, когда у вас есть jsonы с заказами, есть json'ы с входящими платежами, и есть с месячными планами.
То есть проблема в join jsonb и нормализованных данных?
Я просто не настоящий аналитик и даже не администратор базы данных. Получается, надо всё хранить в jsonb, там индексы есть, или они плохо на join работают? Тогда надо всё в одном документе хранить :)
Получается, надо всё хранить в jsonb, там индексы есть, или они плохо на join работают?
Плохо, как только требуется что-то сложное. Представьте, что у вас миллионы заказов в базе данных и вам бизнес неожиданно просит найти распределение возрастов всех пользователей, которые покупали цветы в Германии с 7 по 10 марта любого года.
Заранее индексов таких, разумеется, нет. Получается, только прямой перебор, который займет кучу времени, а данные нужно вот прямо сейчас.
Тогда надо всё в одном документе хранить :)
Вы придумали no-sql вроде mongoDB или key-value storage, они хорошо работают если у вас точно известны все сценарии сохранения и получения данных и совсем нет хитрых агрегаций, что бывает не так часто.
Ну и избыточность у вас будет огромная — условно если у вас соц. сеть, то вам придется хранить в одном документе не только все данные пользователя, все его посты, но и все комментарии, все комментарии к его постам, всех его друзей/подписчиков и (желательно) всех и комменатрии и т.д. В результате, если пользователь напишет крошечный комментарий придется обновлять сотни записей разных пользователей огромного размера. То же при получении данных — простое чтение одного комментария потребует поднять много МБ данных и распарсить их из json.
Получается, надо всё хранить в jsonb, там индексы есть, или они плохо на join работают?
jsonb "под ковром", по сути, это большая денормализованная плоская таблица, в которую автоматически раскидываются данные из json'а, который вы кладёте в соответствующее поле. Со всеми преимуществами и недостатками сего подхода. В преимуществах то, что это всё-таки таблица, её поля можно индексировать, и благодаря этому, по ней можно делать выборки намного эффективнее, чем просто по json-документу в базе. В принципе, это аналогично обычным NoSQL. В недостатках лютая денормализация, соответственно, с лютым же оверхедом на хранение данных, и не слишком лютым, но тоже оверхедом на выборки. А самое неприятное, что в плоской таблице можно более-менее эффективно работать только с данными, которые умещаются в плоскую таблицу. Если у вас там сколь-нибудь сложная структура в модели данных, вы в плоскую таблицу её не положите.
А тут вообще нет ничего из проектирования БД.Чисто практика без теории.Так что да, можно не изучать
Простите, а под
"SQL для чайников" от Алана Бьюли
понимается "Learning SQL. Generate, Manipulate, and Retrieve Data"?
У тебя получается не полный road map, я понимаю что каждая карта для каждого человека будет своя, ну раз уж ты затронул индексы и ключи, то точно нужно затронуть тему нормализации и денормализации и как следствие различия oltp и olap архитектуры. Таблица истинности, для темы фильтрации строк, без неё не обойтись, особенно когда нужно будет строить условия операторов ветвления, ну и как следствие приоритет предикатов выполнения оптимизатором, )) ну и как следствие как команды оптимизатор будет выполнять в первую очередь.
Как изучать SQL в 2023 году