Comments 114
Тех, кто знает, что латенси L1 кэша это ~4 цикла и что кэш лайны лучше не сбивать без необходимости, становится меньше в процентном отношении к общему размеру популяции. Однако волноваться о трудоустройстве им не стоит, кто-то же в конце концов должен писать низкоуровневые вещи, где это по прежнему нужно.
А их точно не становится просто меньше, а не только в процентном отношении, если раньше это была необходимость и теперь трудоустраиваются специалисты которым это было нужно, не будет ли сейчас ситуации, что просто мало кому нужно этому учиться и работодателю дешевле будет кэш ускорить/увеличить на порядок?
Я не знаю, что такое ORM, но какие скилы нужны начинающему web backend девелоперу в итоге? SQL самый важный навык?
ORM — Object-Relational Mapping, в современных фреймворках предоставляет программисту способ обращаться к стораджу (базе данных) используя синтаксис языка и реляционные связи между объектами, абстрагируя конкретную базу данных. Т.е. ORМ за программиста сгенерирует и исполнит запрос к БД, предоставляя программисту интерфейс к эдакой виртуальной объектной БД.
Таком образом, без SQL можно вполне обойтись. Но я считаю, что эти знания определенно нужны, потому что использовать ORM без понимания того, какие запросы он сгенерирует и как они будут исполняться, это примерно как стрелять из ружья не зная, какой стороной к тебе оно повернуто.
А их точно не становится просто меньше, а не только в процентном отношении, если раньше это была необходимость и теперь трудоустраиваются специалисты которым это было нужно, не будет ли сейчас ситуации, что просто мало кому нужно этому учиться и работодателю дешевле будет кэш ускорить/увеличить на порядок?
Из источников, которые удалось найти, этого однозначно не видно. Я сам скорее склоняюсь к мнению, что нет, в абсолютных числах меньше не становится, периодически встречаю людей с опытом в 2-3 года, но хорошо ориентирующихся в этой области, и их вроде бы достаточно.
Таком образом, без SQL можно вполне обойтись.
Я что-то сомневаюсь что получится. Можно попробовать собрать личную статистику использования ORM участниками. Я, например, знаю с десяток серьезных проектов использующих Hibernate. Практически везде дело дошло до custom queries. По разным причинам, но в основном чтобы улучшить производительность.
Практически везде дело дошло до custom queries. По разным причинам, но в основном чтобы улучшить производительность.
В моей практике всегда происходило так же.
Работаю с sequelize (node.js) Проактически все проекты содержат если не полностью raw запросы то по крайней мере литералы(фича sequelize для встраивания raw фрагментов в запрос) в условиях where.
Настколько я просматривал проекты на symfoby/doctrine — там практически все запросы, кроме самых простых идут на dql, который является зераклом sql, только с очень слодным для чтения синтаксисом.
Практически везде дело дошло до custom queries.
Для «web backend» 99.9% работы с базой — это CRUD-ы. Что там заменять на сustom queries?
Если у вас более-менее сложные структуры данных и их надо в таком виде "тащить", то у вас очень быстро простейшее чтение из DB превращается в кучу джойнов. Или например апдейт идёт "логически"на несколько таблиц за раз.
И иногда ORM не справляются в том плане что создают совсем не оптимальные запросы.
П.С. И я например думаю что большинство из тех кто работал с тем же NHibernate хотя бы раз, но натыкался на "Select n+1 проблему" :)
Если у вас более-менее сложные структуры данных и их надо в таком виде «тащить», то у вас очень быстро простейшее чтение из DB превращается в кучу джойнов.
А в sql написаном руками эта куча join как-то магически не появится?
И иногда ORM не справляются в том плане что создают совсем не оптимальные запросы.
А иногда наоборот, генерируют sql гораздо более оптимальный чем написаный руками.
натыкался на «Select n+1 проблему»
Ну это очень детская ошибка. Всё, о чём она говорит, это то, что ORM не полностью избавляет от необходимости думать что делаешь.
А в sql написаном руками эта куча join как-то магически не появится?
А иногда наоборот, генерируют sql гораздо более оптимальный чем написаный руками.
С этим я и не спорю. Речь о том что иногда ORM генерирует не особо оптимальные запросы и тогда нужна кастомизация в том или ином виде. Иногда и в виде SQL написанного вручную.
Ну и иногда бывают какие-то хитрые "хотелки" и/или какие-то не зависящие от тебя ограничения и приходится просто проперти вручную мэппить через кастомный SQL.
И это всё конечно редкости, но более-менее крупные проекты с ORM и без "кастома" я пока ещё тоже не встречал.
нужна кастомизация в том или ином виде. Иногда и в виде SQL написанного вручную.
Да, разумеется и с этим никто не спорит. Иногда это требуется и иногда в «более-менее крупных» проектах можно позвать матёрого базовика с бородой и в растянутом свитре который сделает какую-то хитрую агрегацию, завернёт её в хранимку и всё полетит.
А рядовой гребец «начинающий веб бекэнд» этот pure sql и в глаза не увидит. О чём, собственно, и шла речь.
А что помешает описать промежуточные расчёты на языке ORM, чтобы дальше библиотека их в SQL транслировала?
Вот у меня тоже этот вопрос возник. Тот же NHibernate вполне себе умеет создавать динамические запросы, которые из LINQ генерируют нужный SQL в тот самый момент, когда нужны данные.
П.С. А учитывая что он ещё сам всё может более менее грамотно кэшить, то и число запросов к БД заметно уменьшается.
Можно. Но для этого уже нужна определённая экспертиза в SQL и базах данных в целом. А она есть далеко не у каждого джуниора/миддла. Да и у сениоров наверное тоже не у всех.
А так вам нужно парочку экспертов по вашей ORM, которые её настроят для всех и будут время от времени мониторить производительность и проблемы. А все остальные могут ей просто пользоваться.
Естественно у ORM есть свои границы. Но в 99% "обычных" бизнес-логик их хватает за глаза и за уши.
И я бы сказал что ваш пример тот же NHibernate вполне осилит. То есть выполнить он его точно выполнит и вопрос только в том насколько оптимально. Может быть простого LINQ уже не хватит и надо будет немного "поковыряться".
Ну и в крайнем случае ORM обычно имеют возможность добавлять свои плагины/расширения или даже просто использовать кастомные запросы в "чистом" SQL.
Скорость скорости рознь. Например в symfony/doctrine (которую я по многим параметрам считаю наиболее совершенной ORM не только внутри экосистемы PHP) в течение одного запроса несколько запросов на изменения данных собираются в единый пакет и одним запросом только по реально измененным полям отправляются на сервер. То есть если разрабатывать нечто аналогичное на уровне приложения это будет очень громоздко. А если вделать несколько запросов пусть даже и RAW SQL — тут еще неизвестно какой из вариантов будет производительнее.
Или необходимое условие для вас, чтобы знал оба?
Кароч, какие алгоритмы/структуры/множества надо ботать тем, кто хочет сменить специализацию?
знает язык, но не знает sql?
То, что я перечислил, это простой способ выяснить, насколько человек легко будет способен разобраться в БД, даже если прямо сейчас он не знаком ни с одной.
На мой взгляд если ты хоть немного понимаешь что такое SQL и релациональные БД в целом, то это видно даже если ты вообще забыл синтаксис SQL.
Более того если человек нормально соображает, то это тоже обычно видно. То есть от сениора/миддла естественно требуется больше, а для джуниора/практиканта во многих фирмах может и этого хватить.
или на бумажке же найти декартово произведение:
Отсюда уже недалеко до джоинов в терминах SQL или до модели данных какой-нибудь простой задачи в реляционной БД.
Формулировки и определения нужны для экономии время при разговоре, но можно обойтись и без них, если видно, что человек просто волнуется.
Таком образом, без SQL можно вполне обойтись.
Я считаю, что лучше обойтись без ORM.
Потому что ORM в каждом языке свой, и часто не один. И часто опыт с одного на другой переносить нельзя.
А SQL везде один и тот же, различия в диалектах незначительны.
работодателю дешевле будет кэш ускорить/увеличить на порядок?
Этот кэш работодателю просто так не ускорить, потому что тут речь о физическом кэше процессора.
А обзорщики потом замеряют на какой модели приложение секунду запускается, а на каком полторы на многоядерном процессоре…
нужны ли начинающему web backend девелоперу знания SQL
Без алфавита сложно научиться писать, хотя можно научиться говорить. И всё же базовые знания SQL обязательно нужны. Не только для общего кругозора, но и для понимания основных принципов работы и устройства. Это как алгоритмы, паттерны проектирования, и рабочая терминология. Это может пригодиться и на практике. Например, в Tarantool есть возможность использовать как SQL, так и NoSQL. И даже можно комбинировать. Кроме того при проектировании разработчик может выбирать технологии в зависимости от задач. Или даже комбинировать технологии в разработке. Например, сервис может часть данных хранить в Redis, а часть в MySQL. И это может быть очень даже оправдано.
Железобетонного ответа на вопрос, нужен ли сегодня начинающему web backend девелоперу SQL
Во что выливается незнание SQL
1) Забывают определять индексы в результате через некоторое время приложение останавливается и не могут найти почему.
2) Не могут на практике применять нормализацию данных. Когда "мыслят объектами/сущностями" возникают из-за ошибок нормализации химерные результирубющие структуры таблиц.
По перечни языков программирования интересно было бы узнать статистику по СНГ. В частности по ВУЗам. Если взять усредненный технический ВУЗ, то создается такое впечатление что там преподают как и 30 лет назад Паскаль плавно переходящий в Делфи.
Во что выливается незнание SQL
1) Забывают определять индексы в результате через некоторое время приложение останавливается и не могут найти почему.
2) Не могут на практике применять нормализацию данных. Когда «мыслят объектами/сущностями» возникают из-за ошибок нормализации химерные результирубющие структуры таблиц.
С индексами ситуация очень частая, но быстроустранимая знающим человеком. Неправильно спроектированная база аукается гораздо сильнее.
Поэтому решая не требовать знания БД/SQL у разработчиков, нужно очень четко знать, кто именно будет эти вещи контролировать и исправлять. Видел один раз процесс в большой компании, когда после исполнения задачи разработчик передавал ее на ревью DBA, который должен был в случае чего кричать «Ты не пройдешь!» аки Гэндальф Барлогу. Мой внутренний эстет от такого бьется в истерике, но я понимаю, что люди выкручиваются как могут в сложившихся условиях.
4) Забивают на конкарренси
Ну кроме семестра про асм и машины Тьюринга))
Забывают определять индексы в результате через некоторое время приложение останавливается и не могут найти почему.
А почему тут виновато незнание именно языка SQL, а не незнание основ баз данных?
На SQL что, нельзя забыть создать индекс?
Не могут на практике применять нормализацию данных. Когда "мыслят объектами/сущностями" возникают из-за ошибок нормализации химерные результирубющие структуры таблиц.
А где тут связь?
Спасибо за уточнение. Действительно выражение CREATE INDEX не входит в стандарт SQL (я об этом никогда не задумывался). Это не меняет того момента, что это выражение входит в конкретные реализации большинства SQL серверов баз данных и разработчики ORM хотя и знают что можно определять свойства у объектов связанные с индексацией очень часто этого не делают.
Связь между незнанием теоретических основ нормализации данных и отсутствием практики в их применения такая, что результирующие отношение получаются не нормализованными. Хотя с точки зрения объектного анализа все может выглядеть достаточно правдоподобно.
Привожу реальный пример. Разработчик связал объект "банкомат" с объектом "улица". Однако перепутал hasOne c belongsTo в результате получилась дикая структура, в которой улица принадлежит банкомату, а не банкомат улице. И все это работало без вопросов пока не нужно было переместить банкомат или переименовать улицу.
Ну, "перепутали" — не аргумент. Можно и на SQL много чего перепутать.
результирующие отношения получаются не нормализованными. Хотя с точки зрения объектного анализа все может выглядеть достаточно правдоподобно.
перепутал hasOne c belongsTo
Это не проблема объектного анализа, это проблема непонятных названий в ORM. Связи между объектами всегда должны быть те же самые, что и связи соответствующих таблиц по ключам, потому что первичный ключ это и есть ссылка на состояние объекта, так же как и указатель в оперативной памяти программы.
Да нет, именно эти названия-то как раз предельно понятные. Для того кто знает английский и знает о существовании обоих понятий.
Речь скорее об их назначении, о том, что они делают внутри фреймворка. Когда есть один hasOne и указываются конкретные поля, все просто и понятно. А когда их 2 с похожим смыслом, то уже не очень. belongsTo это тоже своего рода hasOne, да и по названию я бы предположил, что Street belongsTo ATM означает, что ATM главная сущность, и у него будет поле street_id.
Один hasOne невозможен, ведь обратное отношение не может быть тоже hasOne.
да и по названию я бы предположил, что Street belongsTo ATM означает, что ATM главная сущность, и у него будет поле street_id
Но почему? Street belongs to ATM переводится как "улица принадлежит банкомату". Но в таком случае у неё должен быть atm_id.
ведь обратное отношение не может быть тоже hasOne
hasOne и hasMany достаточно для моделирования всех видов связей. Для связи один-к-одному оба будут hasOne.
// atm.street_id <=> street.id
ATM hasOne(Street::class, ['id' => 'street_id'])
Street hasMany(ATM::class, ['street_id' => 'id'])А вот так было сделано в обсуждаемом примере
// atm.id => street.atm_id
ATM hasOne(Street::class, ['atm_id' => 'id'])
Street hasOne(ATM::class, ['id' => 'atm_id'])Сразу видно, что поля как-то не так расположены, и что где-то должен быть hasMany.
Но почему? Street belongs to ATM переводится как "улица принадлежит банкомату".
Улица принадлежит банкомату, значит банкомат имеет улицу, так же как имеет ширину и высоту, значит и street_id должен быть в списке атрибутов банкомата.
Для связи один-к-одному оба будут hasOne.
has — это отношение владения. Владение не может быть циклическим, кто-то обязан быть главнее.
Улица принадлежит банкомату, значит банкомат имеет улицу, так же как имеет ширину и высоту
Нет, это значит что банкомат имеет улицу как дочерний объект.
has — это "имеет". ATM имеет одну улицу. Мы же связь описываем, она принадлежит в равной степени обоим частям.
Когда у банкомата есть street_id, street это тоже дочерний объект.
Представим, что мы удаляем банкомат. Что произойдёт с улицей? Да ничего.
Представим, что мы удаляем улицу. Что произойдёт с банкоматом? Его тоже придётся удалить (ну, или отменить удаление улицы).
Вот и получается, что улица has банкомат, а банкомат belongsTo улица.
А вы в своих рассуждениях путаете саму улицу и её идентификатор.
Техническую сторону я знаю) Я говорю, что has это слишком общее слово, оно подходит для обоих концов связи, поэтому может кого-нибудь запутать (меня например). Если бы там было ownsOne и belongsTo, тогда было бы понятнее, а лучше has с явным указанием полей. В тех же терминах, в каких связи называются (one и many).
Идентификатор и предназначен для представления улицы, в высокоуровневых языках указатели на другие сущности вообще скрываются от разработчика и заменяются понятием "ссылочный тип". По крайней мере я привык представлять их как одно и то же, если речь не о деталях реализации.
— У нас ORM! Оно само всё сделает, а для скорости включим кэш. SQL не нужен!
В итоге:
1. При старте приложения ORM начинает кешировать объекты и их свойства. Пара млн объектов + 10 свойств на объект + связи объектов ( тоже со свойствами), всё это в кеше = OOM на слабом железе (win x32) и тормоза при загрузке. «А нам не говорили, что там будет несколько миллионов объектов, на паре тысяч всё ок было!»
2. Изменение 1 свойства и сохранение приводит к чему? Правильно, весь кеш выливается обратно на сервер. Да, ORM заботливо льёт обратно пару миллионов * 10 свойств объектов в БД, БД заботливо обновляет, перестраивая индексы таблиц, снаружи это выглядит как 2минутная медитация у компьютера. омм… омм… ООМ…
Поэтому пусть лучше знают и SQL, и зачем нужны оптимизаторы, и как работает GC — не то, чтоб это было нужно с первых минут работы, но сэкономить неделю размышлений «а чойто оно такое делает и почему не делает что нужно?» вполне может.
Так и не поняла, что это было. Даже жалею, что не позвала на собеседование — так и осталась эта структура бд для меня загадкой.
Примерно такую структуру использовал в своём первом проекте, для каждого пользователя создавал отдельную табличку, то был отпечаток гайда по написанию текстовой игры с бд на файлах (и там это звучало правдеподобно — даёшь отдельный файл каждому игроку), мне тогда кто-то сказал что файлы это сакс, ну я и переложил лучшие практики из гайда на мускул. Благо пользователей моего сервиса было всего два — я и я, ну и было мне тогда 14 лет.
Это была база данных в текстовых файлах. Такое в качестве примера дается в книжках «PHP за 24 часа» в разделе «операции с файлами».
Везде многочисленные курсы, школы, как стать программистом за 2 месяца. И видимо у них есть клиенты.
Один раз разговаривал с 39-летней женщиной, дак она тоже пошла учиться на программиста в универ. Можете представить мое удивление.
В принципе тут нет ничего плохого. Если зарплаты IT превышают зарплаты в других отраслях, это логично.
Но лично для меня это не очень. Т.к. одно дело, когда ты программист, а другое дело, когда ты «еще один программист».
Круто когда ты умеешь делать что-то, что не умеют другие. А если теперь все будут программисты, — скукота.
ну так это большая часть мира — пост советские страны, восточная европа, индия, китай и т.п.
Индия — да, но исторически они гораздо раньше пост советских стран начали развивать и экспортировать IT услуги, у них «войти в IT» уже устаканилось и сбалансировалось. Где-то мне еще попадалась информация о том, что тамошние крупные IT компании объединились в картель с целью не допустить роста зарплат разработчикам, особенно начинающим.
Мне не нравиться тенденция, что все ломятся в IT.
Ломятся, потому что людей не хватает и порог вхождения ниже чем во многих других специальностях. И программирование оно разное бывает и на мой взгляд для любого уровня понимания/умения можно найти свои задачи и свои зарплаты.
Круто когда ты умеешь делать что-то, что не умеют другие. А если теперь все будут программисты, — скукота.
Это вопрос терминологии и во многих странах/языках уже сейчас есть более-менее устоявшиеся наименования для разных уровней/типов программирования. И думаю что это ещё дальше будет идти в этом направлении.
П.С. А на тему статьи: пока более-менее активно используются релациональные БД, бэкендеру надо хоть немного понимать SQL. Потому что во первых очень велика вероятность что рано или поздно, но ты с SQL в своей профессиональной жизни столкнёшься в том или ином виде. А во вторых, понимая как работают БД, и хороший/оптимальный бэкенд писать проще.
А вообще нормальные люди просто получают больше вайтишников и будут получать еще больше со временем. Ибо бизнесу нужны работающие решения, а не чтото, что работает только на тестовой базе и ложит mysql уже через неделю продакшена, причем переписать быстро — нельзя.
Если вы возьмёте какую-нибудь Западную Европу, то тут давно уже зарплаты у айтишников устаканились примерно на уровне инженера или даже просто человека с высшим "техническим" образованием. Ну может быть в среднем они чуть выше, но не на много.
И всё равно куча людей идёт в ИТ потому что как минимум сейчас работу можно найти вообще без проблем и похоже в ближайшее время это не изменится.
Но потребности в хороших специалистах (экономисты, менеджеры, юристы) меньше не стало.
В принципе в Индии это прошли в начале 0-х.
Когда «бодишопы» брали «в ИТ» кого попало с улицы.
Но это не помешало буму «в ИТ» в восточной Европе. :-)
Очень часто без сложных запросов с подзапросами просто не обойтись и тут ORM не спасёт.
По фреймворкам наибольшим спросом пользуются AngularJS, Node.js...
Современные студенты предпочитают учиться по YouTubeНе понимаю, как можно учиться по такому медленному источнику, да ещё с последовательным доступом.
Пропустить абзац воды в тексте или наоборот, перечитать какую-то сложную формулировку гораздо проще, когда весь текст перед глазами. А если текст есть в электронном виде, я могу моментально найти все места в книге, где упоминается какое-то понятие, не переслушивая весь курс.
НО! Книга, тем более электронная — это как SQL база со связанными списками. Ты можешь быстро сделать выборку по названию в оглавлении, Перейти на связанную таблицу (тему) и т.д. А Ютуб как стэк — чтобы добраться до чего-то, придется разгребать то, что сверху.
Лучше один раз увидеть…
Мы же говорим о программировании вроде. Но насчёт узла вы правы.
Если более развернуто, то бэкендеру в крупной продуктовой команде надо знать свою часть, за базу отвечают разработчики БД. Если компания небольшая, и выделенных разработчиков базы нет, то нужно знать, причем на достаточно неплохом уровне, т.к. с базовыми вещами справится и ORM, а вот когда начнутся просадки по производительности, то нужно будет переписывать узкие места на качественно написанном SQL, и тут базовых знаний не хватит. Ну или нанять разработчика БД, который будет этим заниматься.
Но это не отменяет возможности так называемого «T-shape» развития, когда, для понимания и нахождения общего языка с коллегами мы изучаем все понемногу.
Я лично, как разработчик БД, знаю понемногу и бэк и фронт, и это бывает в некоторых ситуациях полезно.
Тогда и ORM не нужен, базой занимаются профессионалы и бекедщики чуть больше сосредоточены на бизнес логике
Писал я все это на БК 010-01, там был вильнюсский бейсик, он же BASIC-86 и фокал. Эх.Рад встрече, коллега!
Возник вопрос может быть кто-нибудь подскажет.
Сейчас многие ORM польуются для определения связей между объектами/таблицами такими определениями как belongsTo, hasOne, hasMany, manyToMany — но я недавно нашел первоисточник в котором эти слова были впервые определены именно в такой форме. Но сейчас уже не могу найти ссылку. Может быть кто-нибудь подскажет где это впервые было реализовано или описано?
Возможно Entity-relationship model.
Насколько я понял это не языки а фреймворк и
Всё равно странная картинка.
.NET Core — так себе фреймворк, больше почему-то на рантайм похож
Node.js — то же самое
ASP.NET WebForms и ASP.NET MVC куда-то пропали. Вот не верю, что с них уже все на ASP.NET Core свалили, но при этом на ASP всё ещё пишут!
A total of 10,351 student developers completed the 10-minute online survey from October 16 to November 1, 2017.
То есть тут точность серьезно ниже, чем у SlashData.
Ну и у меня есть гипотеза, что когда интервьюируют человека на ASP.NET MVC приложение, спрашивают .NET Core и чем оно отличается от .NET Framework и отдельно про MVC и как оно реализовано в .NET (Core|Framework). Вполне может привести к тому, что все упадет в колонку .NET Core. На интервью PHP-шника будут спрашивать про PHP и меньше уделать внимания конкретному фреймворку. Этим может объясняться перекос в данных.
Мне кажется, что это вопрос исключительно уровня задач.
Если задачи можно решать с помощью конструкторов — пусть решают их с помощью конструкторов. Если нужно залезть глубже — найдут человека, который может залезть глубже.
В Access уже десятки лет встроен конструктор запросов, и офисные сотрудники с ним прекрасно работали, не зная SQL
Вот так я, будучи «уженешкольником» (студетном-первокуром) и активно используя MS Access в универе на лабе, впервые увидел SQL, случайно нажав кнопку «режим SQL».
Поковырявшись чутка, выпросил Интернета у лаборантки, чутка погуглил, охренел от дивного нового мира…
Вот так оно и понеслось с тех пор ))
В моей практике написание sql-запросов занимало в лучшем случае 10% времени от всей работы, и идя собеседоваться лучше порешать задачки на тему, работодатели не прощают ошибок в sql-запросах
идя собеседоваться лучше порешать задачки на тему, работодатели не прощают ошибок в sql-запросах
Возможно, не все работодатели сами могут пообщаться на более глубокие темы работы БД, поэтому придираются к синтаксису? Ладно еще поговорить про семантику where и having, но синтаксис?
Я неявно под знанием SQL имел в виду прежде всего знание теории реляцинных баз данных. Просто знание SQL — это очень просто и как гласит история разрабтывался даже не для сеньоров которые мечтают о погонах dba, а для пользователей. И это даже попало в американский кинематограф как на каком-то доисторическом терминале разведчик забивает некий текст и ему выводится табличка с данными.
«Где та молодая шпана, что сотрет нас с лица земли?»