Comments 58
Господи, какой бред.
Что именно? Развиваться и изучать новое?
Речь в статье была совершенно про другое.
Так а что бред то? Изучать SQL? Хотелось бы понять мысль. Я встречаю проблему, что люди учат языки программирования, но не изучают работу с БД. Поэтому и появилась эта статья, если объясните что показалось бредом то мне это поможет
В первую очередь нужно понимать, что и как должен делать код, а не где и как хранить данные... Не спорю, это тоже важно, как и другие вопросы касающиеся разработки...
Вы же пытаетесь показать, что умение строить грамотные SQL запросы - это вообще краеугольный камень программирования и без этого там нечего делать...
Хотя по факту это нужно далеко не всегда и не всем...
В целом складывается впечатление, что публикация написана с целью рекламирования курсов или телеграмм канала.
Понял! Спасибо за ответ, жаль что сложилось такое мнение. Запомню для следующего поста
> Вы же пытаетесь показать, что умение строить грамотные SQL запросы - это вообще краеугольный камень программирования и без этого там нечего делать...
Хотя по факту это нужно далеко не всегда и не всем...
Да, квантор всеобщности в статье явно лишний.
> Почему нужно сначала изучить SQL;
Да-да. Обязательно!
Расскажите геофизикам, которые хранят гигабайтные данные в собственных специфических базах, или сейсмологам, ориентированным на Mseed,что их жизнь пуста и бессмысленна без знания SQL. И почему в их программах (где действительно используются очень нетривиальные алгоритмы, сильно выходящие за пределы обычных курсов) этот самый SQL является тем краеугольным камнем, без которого нет смысла даже и начинать. Да половина из тех, кто всю жизнь успешно и эффективно работает с этими данными, и пишет для этого не только собственные программы, но зачастую и алгоритмы (которые нормальному фронтэндеру в страшном сне не приснятся), даже такого слова не слышали ;-)
Надеюсь, тут не нужно намекать, почему?
;-)
Бред - это советовать СНАЧАЛА изучать SQL, а ПОТОМ уже продуктовый ЯП. Во-первых ничего не мешает делать это параллельно (SQL + ЯП), закрепляя на реальном проекте, пусть и личном. Во-вторых, SQL многим нужен на уровне базового CRUD. В-третьих, SQL уже давно не догма для хранения данных. Тем более что я сам уже несколько лет не пишу на SQL в продуктах, а юзаю ORM. Чистый SQL мне нужен только для запросов непосредственно в базу, например, для поиска ошибок.
На небольших проектах серьёзная оптимизация запросов не нужна, а на крупном проекте оптимизацией SQL занимается специалист по SQL, которому ваши советы точно не нужны.
Спасибо, теперь понятно! Учитывая ваш пример с использованием ORM нужно тоже понимать базовый SQL. С этого я и советую начинать, а затем изучать ЯП или изучать дальше БД если это интересно человеку. Но я понял, что сейчас возникает другое ощущение от статьи, спасибо за разъяснения!
А я пишу и простые запросы с помощью ОРМ, чтобы было понятно и читаемо и сложные запросы руками чтобы было быстро там, где надо, чтобы было быстро и всем советую учить SQL, а не надеется, что кто-то другой решит проблему.
Купи мои курсы.
Для такого хранения с 1970-х годов используются реляционные базы данных.
Фронтендеры и системные программисты набегают через три...
В целом согласен
Императивное программирование - зло.
SQL довольно простой способ окунуться в декларативное программирование
Удивляюсь токсичным комментам... Прекрасная статья для дискуссии.
Автор курсов по программированию, Senior Backend разработчик. До IT открывал кофейни, обучал людей в ресторанах и занимался дизайном.
Очень сомневаюсь, что Senior Backend разработчики занимаются написанием статей такого сорта. А вот то, что тс является автором курсов и что целевая аудитория публикации --- вкатыши (как, полагаю, и сам тс), очень хорошо ощущается)
Наглядное сравнение декларативной и императивной парадигм, думаю, новичкам действительно полезно, весь остальной материал выглядит... сомнительно.
Большинство программ пишутся без использования баз данных. Не говоря уже о том, что с базами данных можно работать через посредника.
Любой язык или инструмент нужно изучать тогда, когда это необходимо для решения задачи. Рано или поздно, почти все сталкиваются в необходимости знания SQL, хотя бы на базовом уровне, но это не означает, что его нужно учить в самую первую очередь.
програмист-сопровождения обязан знать sql
Меня очень триггерят такие категоричные высказывания.
Вы же понимаете что программирование не ограничивается бэкендом? Ну т.е. есть много других областей где sql вообще не нужен, например мобильная разработка, системное программирование, программирование микроконтроллеров или gamedev.
Если программисту-сопровождения необходим SQL он его будет знать (должен знать). Это никак не противоречит моим словам.
И SQL не является языком программирования, это язык описания запросов. Специализированный язык. Он никак не поможет в изучении программирования как такового (возможно только для декларативных языков в какой-то степени). Так что нет, SQL не лучший первый язык.
Для справки, PL/SQL - это не SQL.
/* У меня всё равно полно минусов... */
Сначала, не с начала... знание sql и представление, как выполнить декомпозицию данных и последующий синтез объектов из этих данных - весьма полезно. К сожалению, (не только сейчас - постоянно за ~25 лет работы встречал) довольно часто встречаешь кодеров, которые не понимают виды и методы композиции обьектов, и почему-то прямо-таки шарахаются конкретно от SQL, что грустно. Высококлассные в своей области специалисты спотыкается об самые простые из реляционных СУБД, и даже не рассматривают их как вариант для решения своих задач.
Даже Мартин Фаулер называл требование "знать SQL" недостатком РСУБД... 🫠
...ой, надо всё же было сперва статью прочесть, а не коммент писать. Прочёл: статья - дикий бессистемный винегрет. Извинения.
Два года учил людей в кафе и ресторанах, теперь стал учить на Хабре. КГАМ, тема сисег не раскрыта.
Почему надо обязательно учить sql, когда есть nosql базы данных и много софта вообще не использует никакие субд? Прежде чем учиться варить борщ, вам надо научиться правильно варить яйца. Почему? Ну, потому что я так хочу. Если у вас есть сомнения на сей счет, приходите на мой телеграм или записывайтесь на курсы в ресторане.
Никогда не учил SQL, а запросы делал в любом конструкторе. Потом просто проверил - работает так как надо, значит все в порядке. И никаких проблем не было...
не учил SQL - не погромист
Не ну достойный перл в копилку замечательных обрядов инициации
не служил не мужик
не сидел не мужик
хочешь играть на электрогитаре - сначала играй на классике
хочешь ездить на нормальной машине - сначала намудохайся с ТАЗиком
Обряды инциации известны как минимум с палеолита. Автор просто стоит за традиционные ценности.
Senior банановой республики...
Для начала немного дополню мысль автора. Когда мы учим SQL мы учим не только запросы, мы учим такие вещи как нормализация данных и тд.
Если продолжать пример про магазин, то изучая SQL мы учимся так же удобному расположению товаров на полках.
Самое интересное, что SQL достаточно прост, но при этом любители объектно-ориентированной парадигмы его просто ненавидят. Им проще вместо одного запроса, написать 10 классов, которые потом превратятся в 100 объектов, которые в свою очередь будут уже между собой разбираться. Но, как говорилось:
Любую проблему можно решить путём введения дополнительного уровня абстракции, кроме проблемы слишком большого количества уровней абстракций.
Что касается большого количества минусов, то это из-за того, что большая часть комментаторов, плохо относится к SQL и просто отстаивает свою позицию. Опять же Никита привык к другой форме контакта с аудиторией, в кафе ты имеешь непосредственный контакт, и можешь подкорректировать подачу информации, или вообще отказаться от разговора, если понимаешь, что человеку не интересно твое мнение. Далее на аваторке, слишком уж молодой человек, это то же чревато.
Но вообще, статья мне понравилась, пусть мне за это минусов наставят. Удачи автору, не бросать писать.
PS: есть в SQL такая интересная вещь как рекурсивный запрос, хотелось бы почитать, что Никита про это думает)))
Прям как типичный видео-гайд от мамкиного блогера. Сначала заставка 2 минуты, потом предисловие на 20 минут и только в самом конце 10-секундный ответ.
У автора есть доля правды. Представим себе, что вы хотите заготавливать сено в дождливое лето. Что раньше нужно учиться косить или как сушить сено? В данном случае нужно научиться правильно сушить сено вначале, а иначе все сено сгниет.
Вот только есть один нюанс: сена-то влажного нет, а то что есть - все сухое или еще не скошено. И на чем учиться?)))
Не утруждайте себя выдумыванием аформизмов и аналогиий, за Вас уже давно народ придумал, наиболее подходящее звучит вот как:"Хороша ложка к обеду".
Итак, алгоритм: узнали как косить -> скосили по технологии -> узнали как сушить -> засушили -> WTF?? PROFIT
По сути топика: автор сделал гигантское обобщение, исключив из уравнения сразу массу ситуаций, когда "сушить" вообще ничего не надо: надо только косить, за что и поймал в ответ весьма резонное непонимание в комментах. Не будьте как автор.
Учите латынь, в аду с вами никто по английски разговаривать не будет.
какие токсичные комментарии)
да, у автора дискуссионная точка зрения, и да, изложил несколько сумбурно и может быть не так, как привыкла аудитория. но зачем же так хейтить?
в целом поддерживаю идею, что sql надо знать, если работаешь с реляционной бд. каждый раз, когда приходит новый разраб в команду, у которого sql на уровне crud, случается боль - либо у куратора новичка, либо у самого новичка. чаще у обоих.
почему-то многим проще написать цикл, в каждой итерации которого будет dml над одной строкой, чем написать один dml над массивом строк. и в голову не приходит, что так можно и так сильно быстрее. у бд обычно очень много собственных возможностей, которые игнорируются адептами япву
Ну полно вам писать гневные комментарии. Человек попытался предложить нечто оригинальное, высказал своё мнение
Такой подход в изучении ЯП довольно спорный. Всё же в паре с sql следовало бы изучать скриптовый язык, например, python. Тогда проще воспринимать, где и когда изученнве запросы можно применить. А для этого, естественно, нужно знать базу языка
Я пробовал себя в роли "преподавателя", и со 2-3 занятия понял, что я не тяну это от соова совсем. Я не мог ответить на простой вопрос: "зачем?". Зачем мы выводим Hello, world? Зачем мы делаем вывод ста последовательных чисел в цикле? Ради примера? А где мы дальше будем такое применять? После попыток объяснить, что пока не могу дать реальный пример использования этих конструкций, мои ученики просто теряли интерес. Я понял, что для изучения языка нужны живые примеры, которые можно "пощупать" и "прочувствовать". В случае с изучением sql в самом начале будет очень трудно объяснить человеку, зачем мы храним данные в "коробочке под названием БД" на каком-то сервере и потом делаем сложные непонятные запросы, чтобы их оттуда достать.
Так что точку зрения автора я не могу разделить. Если человек начинает изучение с абсолютного нуля - нужно изучать что-то проще и нагляднее, а потом углубляться в дебри (я сам вообще начинал с php, и это было наглядно настолько, что в свои 11 лет я прекрасно понимал суть)
Мне всегда казалось, что выбор языка диктуется задачами, которые хочется/требуется решать...
На самом деле SQL это не для новичков. По работе я имею дело с базами данных как программист, архитектор систем и dba. Это все настолько требует огромного кругозора и знаний, что новичку не подсилу. Изучить select insert и update несложно, но это лишь начальный уровень. Вся мощь SQL проявляется в сложных проектах. До этого еще надо дорасти. Ну а ORM это как костыли для разработчика. Одну из своих разработок я описал в статье (ссылка в моем профиле). Можно оценить сложность этого проекта.
Тезис очень спорный, но подборка ресурсов неплохая, спасибо.
Что-то со мной видимо не так.
Я тоже уверен что базовое знание sql необходимо всем, и далеко не только айтишникам.
Автор, не в обиду вам, но вы не с той стороны зашли. Человеку хотящему начать свой путь в программирование до БД как до луны пешком.
Вам хорошо ответил fire64 (https://habr.com/en/articles/881896/#comment_27914102)
Приведу небольшой пример: В свое время изучал PHP. На первых порах начинаются разбор HTTP заголовков. Я хоть и имел опыт в программировании, но для меня это было крайне сложно понять (как это будет на практике.). Так я еще не пересекался в web областью.
Во-вторых, а если человек желает разрабатывать игры, чем ваш подход может ему помочь?
Статья действительно сыровата. Но есть интересные мысли которыми автор очень спешил поделиться. Мне идея зашла и хочется сделать небольшой разбор.
Заголовок цепляет аудиторию далекую от знаний ЯП, но в начале читателя засыпают сложными техническими терминами с делениями языков на уровни с поверхностными пояснениями сложности и ответственности работы с ними.
Для целевой аудитории можно было ограничится высокоуровневыми ЯП учитывая что с БД работают именно они.
Скриптовые языки предназначены для автоматизации задач, управления программами и обработки данных. Обычно они интерпретируемые — это означает, что код выполняется напрямую без предварительной компиляции. Из‑за отсутствия компиляции такие языки могут содержать больше ошибок и выполняться медленнее, чем системные. Ответственность разработчика уже не в контроле ресурсов, а в качестве написанного кода. Может показаться, что порог входа в такие языки ниже, чем в системные. Однако, большое количество абстракций в языке требует большего времени на его изучение.
Как итог целевая аудитория вероятно закрыла статью от сложностей описаных в начале.
Остались те, кто от столь громкого заголовка и захода со стороны низкоуровневых языков начали ждать соответствующего финала.
Финала по моему мнению не состоялось. Так как толком даже не была установлена связь между программированием и работой с данными и тем более сложно структурированными данными (необязательно полученными средствами SQL).
Так вот, стоило, пожалуй, рассказать о том, что многие (не все) разработчики сталкиваются с необходимостью взаимодействовать с большими объемами данных и их обработкой. О том, что данный за частую имеют между собой сложные связи. И вот тут одна из причин, почему работать с данными может быть отдельным (первым) шагом на пути к программированию.
Вот теперь можно говорить о том такие данные приходится как‑то держать в постоянной памяти и дать объяснение когда для этого используют БД и что отличает реляционные от не реляционных. И тогда читатель возможно сможет понять что такое SQL (расшифровку тоже не мешало добавить) и для чего используют.
Далее нужны примеры с данными которые могли бы увлечь не посвященных людей.
Например кусок БД с комментариями к этому посту:
можно выбрать только пользователей
можно взять комментарии упорядочить по оценке
А можно сделать сложную структуру с привязкой рейтинга пользователя, но тут возможно стоит упомянуть о транзакциях и непостоянности данных в процессах работы с данными.
Вот после этого я бы поверил, что SQL это язык и хорошее знание его принципов взаимодействия с данными даст жирный плюс в работе с данными в любом другом ЯП
Идея понравилась, но в целевую аудиторию явно не попала!
Данная дискуссия очень интересна тем, что при обсуждении альтернативных предложений многие не могут сдерживать эмоции, возникающие при не согласии с автором, у них не получается грамотно писать и без оскорблений.
Статья от вкатыша для вкатышей с типичным когнитивным искажением ситуации "ошибка выжившего", трактуемая как "секрет успеха".
Войтишная чушь . Причем не про sql.
Нормальные sqlщики получаются из программистов которые хотя бы поверхностно понимают как СУБД работает внутри, структуры данных, память, диски. Те кто не могут сами написать например merge join двух коллекций на диске не выжрав всю память. В SQL на реальных данных такую говнокодную дичь творят, что до разработки лучше не допускать.
Прежде чем выбирать язык программирования, необходимо изучить SQL