Спасибо за комментарий) Да, такое тоже встречается — добавлю это в статью. Но тут стоит отметить, что у Junior-специалистов нет особого выбора, какие тестовые задания выполнять, а какие — нет.
Важно не то, что вы пишете и на чём, а какие требования предъявляются к продукту. Как правило, мы не взаимодействуем с системными вызовами напрямую, но понимание того, что происходит под капотом, помогает в разработке и отладке.
Например, добавление строки в конец файла в Python:
with open(path, "a") as file:
file.write(data + "\n")
Ничего особенного на первый взгляд, и в любом проекте это будет работать. Но что, если по какой-то причине данные не записались? Произошёл сбой, релиз или что угодно ещё. При этом у нас крайне высокие требования к недопустимости потери данных.
Возможно, мы знаем, что данные не сразу записываются в файл, а сначала попадают в буфер интерпретатора Python.
Давайте чуть поправим и добавим вызов flush(), который передаст данные в ОС:
with open(path, "a") as file:
file.write(data + "\n")
file.flush()
Сделали — и всё равно данные иногда теряются. Скажем, мы знаем, что, кроме передачи данных в ОС, мы ещё можем сказать ей сбросить буфер на диск через системный вызов fsync:
with open(path, "a") as file:
file.write(data + "\n")
file.flush()
os.fsync(file.fileno())
Всё равно данные иногда теряются и не записываются. Копаем дальше. Возможно, у нас на сервере кэш на уровне жёсткого диска или SSD, и даже если ОС вызвала fsync(), диск может принять команду, но отложить запись.
В общем, чем глубже у вас понимание того, что происходит, тем легче искать причины проблем и тем менее вероятно, что вы создадите новые.
Это пример при работе с файлами, но что-то стреляет и в других вещах, смотря что делает ваша программа.
В целом, я бы сказал: если ваша программа будет выполняться на Linux (даже если это просто CRUD), вам всё равно полезно знать, как она взаимодействует с операционной системой. На небольших проектах это не так очевидно, но если речь идёт о high load или сферах, где критична производительность, — без этих знаний разработка становится работой вслепую.
Если собеседования были, то проблема в подготовке и опыте. За 6 месяцев можно подтянуть теорию и практику и любое собеседование пройти. Большинство не учатся и каждый раз надеятся, что на собеседование им повезет. Люди по 6-8 месяцев готовятся чтобы в Яндекс пройти а 2 года это очень большой срок за который можно было с нуля подготовиться к любым этапам собеседования.
Если слово булочка заменить, например, на производственный станок, то спрос на него будет расти вместе с падением его стоимости до тех пор, пока выгодно производить товар на этом станке.
В случае с программистами — это универсальный станок, на котором можно делать любой IT-продукт. И рынок будет насыщен этими станками только тогда, когда никаких новых IT-проектов не будет появляться. Если создать новый IT-продукт становится дешевле, то, соответственно, самих продуктов будет больше, даже если они убыточные (как большинство стартапов).
Почему в кризис падает спрос на программистов? Потому что стартапов становится меньше. А когда нет финансовых кризисов, инвесторы делают ставки на стартапы, как азартные игроки на рулетку, и в итоге идёт найм программистов в проекты, которые никогда не принесут прибыль.
Можно сказать, что булочками все давно наелись, но всё равно продолжают есть в надежде, что в одной из них спрятан счастливый лотерейный билет.
Так что программистов некорректно сравнивать не только с булочками, но и с многими другими профессиями, такими как бухгалтер, например. Для бизнеса бухгалтер — это расходы на операционное обслуживание, а программисты — источник прибыли и роста. Больше бухгалтеров — это просто больше расходов, а больше программистов — это более быстрый рост продукта и прибыли.
Даже если автоматизировать половину работы программиста, всё равно есть смысл нанимать ещё. А если автоматизировать половину работы бухгалтера, то нет смысла ни нанимать, ни держать тех, кто уже нанят.
Учиться нужно всегда. Зарплата, как правило, не растет сама по себе за счет выслуги лет. Она растет вместе с квалификацией. С 3 годами опыта можно получать как 120к так и 300к. Большинство людей стоят на месте годами. Я бы сказал, что чем ближе вы к уровню Senior, тем отчетливее вы будете понимать, что в ВУЗах преподают нужные вещи, а опыт в маленьком проекте, не тоже самое, что в большом high load.
У меня аналогичная ситуация. Опыт 13 лет. Стоит открыть резюме и пишут столько, что через +-пару недель закрываю этот краник нафиг и общаюсь с теми, кто успел написать и заинтересовал. Последний раз это делал год назад.
А так тоже пишут пару раз в неделю. Я всем говорю, что не ищу работу и часть из них через какое-то время снова пишут не передумал ли я. И я не вижу такого, чтобы предлагать меньше стали. Удаленка US $8-10k в РФ 400-600к (это то, что прилетает каждую неделю).
И это python. Возможно самый перегретый рынок.
При этом я прекрасно вижу что джунов не нанимают вообще (почти) а у мидлов проблемы с поиском из-за выпускников курсов, которые накрутили себе опыт. Но накрученный опыт это не реальный кандидат.
Ну и сам опыт тоже важен. Если вы работаете в маленьком проекте в каком-то ИП или что-то такое, то это одна ситуация, а если в крупном проекте, то другая. Так как с опытом в крупных проектах приглашений на работу всегда было больше.
Каждый живет в своем маленьком мире, и видит то, что происходит вокруг него.
Джуны и мидлы в мире, где нет работы. (хотя смотря какой мидл)
Работодатели в мире, где некого нанимать.
Сеньоры в мире, где живут только пони, и какают бабочками.
Если бы я не обучал людей, то не поверил бы, что работу сложно найти. Просто потому, что не проходил бы через эти трудности вместе со студентами. В какой-то момент я пришел к тому, что всех студентов трудоустраиваю по рекомендации через своих HR, которые меня уже знают. А пару лет назад все устраивались через тестовые задания и собеседования.
Спасибо за комментарий) Большая часть откликов на такие вакансии — это не программисты, а выпускники курсов. Кто-то накрутил себе опыт, а кто-то — нет, но это не отображает реальную картину вещей. С тем же успехом тысяча дворников могут откликнуться на вакансию ТОП-менеджера, потому что на каком-то курсе им сказали, что они теперь ТОП-менеджеры, и надо просто накрутить опыт в резюме, чтобы обойти "глупые" фильтры.
Тут есть две стороны медали.
С одной стороны — работодатели с большим недоверием относятся к кандидатам, и непонятно, кого приглашать на собеседование, из-за чего самих собеседований становится меньше.
С другой стороны — когда реальный программист с хорошим опытом и подготовкой приходит на собеседование, за него хватаются руками и ногами, так как не взять его на работу за любые деньги — означает провести ещё 100+ собеседований, фильтруя выпускников курсов.
Получается, что кандидатов больше, но при этом хороший кандидат имеет больше возможностей торговаться по зарплате, так как искать второго такого — долго и дорого. Сейчас редко бывает ситуация, когда работодатель может выбирать хотя бы даже из 3–5 хороших кандидатов, как было раньше, и отказывать тем, кто хочет хотя бы немного больше денег.
Если сейчас вдруг весь мир накрутит себе опыт программирования в резюме и будет подаваться на все вакансии, то зарплата программиста вырастет ещё больше. Потому что каждый квалифицированный программист превратится в алмаз, который днём с огнём не сыщешь (уже).
Большое количество откликов без сохранения качества этих откликов приводит только к удорожанию найма и, как следствие, росту зарплат. Вот если бы все 1000 были хорошими программистами, да хотя бы даже 10% из них, тогда можно было бы говорить о какой-то конкуренции.
Я думаю человек имел ввиду авторизацию под разными пользователями для приложения и для миграций схемы БД. Чтобы приложение не могло менять схему БД. Это и так само собой всегда должно быть. Если он имел ввиду другое, то так конечно никто не делает. Это сложно и избыточно. Возможно только в каких-то специфичных случаях, но я такого не встречал. Обычно пользователя в БД создают для разграничения прав для приложения или его частей, миграций и т. д.
Много ли разработчиков будут использовать JSON в сырых SQL или писать Merge вместо Insert и Update?
А почему нет? Не вижу ничего, что может быть сложным. ORM это хорошо, но каждый должен понимать как оно работает и не нуждаться в ORM как в инструменте для оптимизации. Тем более что оптимизация в ORM это часные случаи а в общем случае все зависит от того, насколько хорошо разработчик понимает, что он делает.
ORM может сделать для запроса и оптимизацию, которую руками в SQL никогда не напишешь.
Приведите пример когда ORM что-то оптимизирова лучше, чем это может сделать разработчик? Не должно быть такого, что вы не понимаете SQL, который генерирует ORM. Тогда использование ORM действительно вредно и только для учебных проектов прокатит такой подход. Или маленьких MVP, которые потом кто-то будет переписывать.
Разработчик должен отлично владеть SQL и знать внутреннее устройство БД. Иначе с ORM в руках он сделает все очень плохо.
ORM не избавляет вас от необходимости изучать SQL и БД. Все запросы и миграции написанные с ORM всегда нужно проверять.
Могу примерно сказать сколько требуется памяти серверу для обслуживания 20к пользователей: где-то 10-20 мб при нагрузке в 1000-2000 запросов в секунду. Но из этих 10-20 мб, 6мб требуется на старте сервера. Но это цифры по сукти ни о чем не говорят.
Нагрузка маленькая. Экономия около нулевая. Актуально может быть только в специфичных случаях, когда мы строго ограничены в ресурсах.
Была у меня как-то задача оптимизировать ML приложение для работы на обычном ноутбуке, который поедет к заказчику на завод. Вот там нужно было экономить даже на спичках, так как была бизнес причина для этого и ограничение в ресурсах конфигурацией ноутбука. А если нет бизнес причины, то любая оптимизация\работа это оверинженеринг.
Но даже если, у вас есть специфичные причины думать о нескольких мегабайтах, это не означает, что ORM плохой выбор для других проектов. А в случае миграций и админки это вообще не актуально.
Вот этот момент сильно влияет на производительность.
Сильно это как? Есть бенчмарк вашего проекта? На сколько быстрее время ответа? На сколько дешевле сервера? Без конкретики "сильно влияет" это абстрактная информация ни о чем. Такая же абстрактная как и бенчмарки в вакууме из интернета.
Можно не писать запросы на ORM, а использовать Query Builder это хорошее решение, но не отменяет одновременного использования ORM для миграций и админки. Если конечно вы не считаете, что Query Builder тоже "сильно влияет"
Использование SQL Builder, не исключает использование ORM для миграций и LOW-CODE админки. Если конечно в вашем стеке существует ORM с админкой и вы знаете ORM или готовы изучать. Если такая ORM существует, то не использовать ее, это потеря скорости разработки.
У меня как-то был очень активный спор с командой на эту тему. Не хотели внедрять ORM, так как просто никто кроме меня в команде с ними не работал или очень мало и просто не хотели изучать.
Нужна была админка и команда на полном серьезе хотела писать ее самостоятельно и выделить целый квартал времени для фронта и бэка.
В итоге я за выходные ее сделал всю на LOW-CODE решении с ORM. Показал команде и с тех никто на эту тему не спорит, надо изучать ORM или нет. В запросах в приложении ORM не использовали.
В статье не идет речь о том, что надо всегда и везде использовать ORM. В целом нельзя даже объективно рассуждать, что лучше, если не владеете достаточно хорошо хотя бы одной ORM а также SQL и внутренним устройством БД. Нет гарантии что в вас говорит разум, а не психогический блок перед изучением чего-то нового. Как многие говорят птичий язык ORM.
В нашей компании был такой разработчик на Питон. Который только ОРМ умел использовать.
Знать сам SQL и внутренее устройсвтво БД нужно в любом случае. Тут опять же он знал как писать на ORM и просто писал бездумно. Пришел другой разработчик, который знает только как писать на SQL, и потому переписал все на SQL (ему так тоже проще).
В статье я подчеркиваю, что нужно знать SQL и внутренее устройсвтво БД в любом случае. В вашем случае, вам бы все равно пришлось переписывать, то что он написал бы на SQL.
Используют, потому что так проще
Каждому проще делать так, как умеет. Поэтому так много противников ORM и так же много их адептов, ведь это что-то, что тоже нужно уметь использовать. Найти причину не изучать не сложно. Вместо ORM можно подставить SQL в этом утверждении суть не меняется.
Люди хорошо владеющие ORM извекают максимум из его эффективности и отлично знают сам SQL, и используют его там, где ORM не эффективен.
Смысл ругать ORM за то, что ваш разработчик не понимал что делает.
SQL Builder хорошее решение для запросов в приложении, но не повод отказываться от ORM для миграций и админ панели. У нас во многих сервисах используется SQL Builder (не самописный) для запросов и все равно используем ORM для описания моделей, миграций и админки.
Код сложнее? Нет. Менее удобен? Нет. Быстрее отработает, чем пока ОРМ сгенерирует не пойми что? Да.
По поводу произовдительности уже отвечал, что оверхед там не большой. Даже на больших нагруках (у нас 20+ млн пользователей) он не станет узким местом. Позже дополню статью своими ответами в комментариях. А сложнее становится, когда запрос с фильтрами, а какие именно фильтры зависит от логики. И тут начинается склейка строк и т.д. Разработчики хорошо знающие SQL используют ORM не просто так.
Вот и все, инъекции не будет не при каких условиях.
В статье есть об этом и в комментах уже отвечал. Я сам не раз видел на ревью, что человек даже знаная про SQL-инъекции, иногда случайно вставляет переменную через форматирование строки. Человеческий фактор всегда будет стрелять. Чем больше проект и разработчиков, тем чаще. В маленьком проекте на 5 человек за этим следить относительно просто, а когда у вас большой проект особенно монолит над которым работает 100+ программистов уже сложнее. Один раз на ревью не заметят и уже могут быть огромные финансовые и\или репутациаонные потери для проекта.
Вот и все, инъекции не будет не при каких условиях.
В статье есть об этом и в комментах уже отвечал. Я сам не раз видел на ревью, что человек даже знаная про SQL-инъекции, иногда случайно вставляет переменную через форматирование строки. Человеческий фактор всегда будет стрелять. Чем больше проект и разработчиков, тем чаще. В маленьком проекте на 5 человек за этим следить относительно просто, а когда у вас большой проект особенно монолит над которым работает 100+ программистов уже сложнее. Один раз на ревью не заметят и уже могут быть огромные финансовые и\или репутациаонные потери для проекта.
Да, но проблему SQL-инъекций это не решает. Удаление таблицы это просто пример. Любое несанкционированное изменение\извлечение данных большая проблема и мне сложно представить, что все это можно решить на уровне СУБД. Что-то можно, но врядли это будет делаться для предотвращения всех SQL-инъекций скорее по другим причинам.
Спасибо за комментарий) Да, такое тоже встречается — добавлю это в статью. Но тут стоит отметить, что у Junior-специалистов нет особого выбора, какие тестовые задания выполнять, а какие — нет.
Важно не то, что вы пишете и на чём, а какие требования предъявляются к продукту. Как правило, мы не взаимодействуем с системными вызовами напрямую, но понимание того, что происходит под капотом, помогает в разработке и отладке.
Например, добавление строки в конец файла в Python:
Ничего особенного на первый взгляд, и в любом проекте это будет работать. Но что, если по какой-то причине данные не записались? Произошёл сбой, релиз или что угодно ещё. При этом у нас крайне высокие требования к недопустимости потери данных.
Возможно, мы знаем, что данные не сразу записываются в файл, а сначала попадают в буфер интерпретатора Python.
Давайте чуть поправим и добавим вызов flush(), который передаст данные в ОС:
Сделали — и всё равно данные иногда теряются. Скажем, мы знаем, что, кроме передачи данных в ОС, мы ещё можем сказать ей сбросить буфер на диск через системный вызов fsync:
Всё равно данные иногда теряются и не записываются. Копаем дальше. Возможно, у нас на сервере кэш на уровне жёсткого диска или SSD, и даже если ОС вызвала fsync(), диск может принять команду, но отложить запись.
В общем, чем глубже у вас понимание того, что происходит, тем легче искать причины проблем и тем менее вероятно, что вы создадите новые.
Это пример при работе с файлами, но что-то стреляет и в других вещах, смотря что делает ваша программа.
Интересное видео Разработка и эксплуатация ядра Linux в инфраструктуре Яндекса
На больших масштабах, при наличии высоких требований, выстреливает всё. И люди, которые способны что-то с этим сделать, всегда будут высоко цениться.
Большинство разработчиков работают в проектах с низкими требованиями, но не всегда они это осознают, и просто не видят смысла погружаться глубже.
Спасибо за комментарий) На Python пишут не только CRUD.
Например, на Python есть реализация supervisor, где по сути всё работает через системные вызовы.
https://github.com/Supervisor/supervisor
В целом, я бы сказал: если ваша программа будет выполняться на Linux (даже если это просто CRUD), вам всё равно полезно знать, как она взаимодействует с операционной системой. На небольших проектах это не так очевидно, но если речь идёт о high load или сферах, где критична производительность, — без этих знаний разработка становится работой вслепую.
Если собеседования были, то проблема в подготовке и опыте. За 6 месяцев можно подтянуть теорию и практику и любое собеседование пройти. Большинство не учатся и каждый раз надеятся, что на собеседование им повезет. Люди по 6-8 месяцев готовятся чтобы в Яндекс пройти а 2 года это очень большой срок за который можно было с нуля подготовиться к любым этапам собеседования.
Если слово булочка заменить, например, на производственный станок, то спрос на него будет расти вместе с падением его стоимости до тех пор, пока выгодно производить товар на этом станке.
В случае с программистами — это универсальный станок, на котором можно делать любой IT-продукт. И рынок будет насыщен этими станками только тогда, когда никаких новых IT-проектов не будет появляться. Если создать новый IT-продукт становится дешевле, то, соответственно, самих продуктов будет больше, даже если они убыточные (как большинство стартапов).
Почему в кризис падает спрос на программистов? Потому что стартапов становится меньше. А когда нет финансовых кризисов, инвесторы делают ставки на стартапы, как азартные игроки на рулетку, и в итоге идёт найм программистов в проекты, которые никогда не принесут прибыль.
Можно сказать, что булочками все давно наелись, но всё равно продолжают есть в надежде, что в одной из них спрятан счастливый лотерейный билет.
Так что программистов некорректно сравнивать не только с булочками, но и с многими другими профессиями, такими как бухгалтер, например. Для бизнеса бухгалтер — это расходы на операционное обслуживание, а программисты — источник прибыли и роста. Больше бухгалтеров — это просто больше расходов, а больше программистов — это более быстрый рост продукта и прибыли.
Даже если автоматизировать половину работы программиста, всё равно есть смысл нанимать ещё. А если автоматизировать половину работы бухгалтера, то нет смысла ни нанимать, ни держать тех, кто уже нанят.
Учиться нужно всегда. Зарплата, как правило, не растет сама по себе за счет выслуги лет. Она растет вместе с квалификацией. С 3 годами опыта можно получать как 120к так и 300к. Большинство людей стоят на месте годами. Я бы сказал, что чем ближе вы к уровню Senior, тем отчетливее вы будете понимать, что в ВУЗах преподают нужные вещи, а опыт в маленьком проекте, не тоже самое, что в большом high load.
У меня аналогичная ситуация. Опыт 13 лет. Стоит открыть резюме и пишут столько, что через +-пару недель закрываю этот краник нафиг и общаюсь с теми, кто успел написать и заинтересовал. Последний раз это делал год назад.
А так тоже пишут пару раз в неделю. Я всем говорю, что не ищу работу и часть из них через какое-то время снова пишут не передумал ли я. И я не вижу такого, чтобы предлагать меньше стали. Удаленка US $8-10k в РФ 400-600к (это то, что прилетает каждую неделю).
И это python. Возможно самый перегретый рынок.
При этом я прекрасно вижу что джунов не нанимают вообще (почти) а у мидлов проблемы с поиском из-за выпускников курсов, которые накрутили себе опыт. Но накрученный опыт это не реальный кандидат.
Ну и сам опыт тоже важен. Если вы работаете в маленьком проекте в каком-то ИП или что-то такое, то это одна ситуация, а если в крупном проекте, то другая. Так как с опытом в крупных проектах приглашений на работу всегда было больше.
Каждый живет в своем маленьком мире, и видит то, что происходит вокруг него.
Джуны и мидлы в мире, где нет работы. (хотя смотря какой мидл)
Работодатели в мире, где некого нанимать.
Сеньоры в мире, где живут только пони, и какают бабочками.
Если бы я не обучал людей, то не поверил бы, что работу сложно найти. Просто потому, что не проходил бы через эти трудности вместе со студентами. В какой-то момент я пришел к тому, что всех студентов трудоустраиваю по рекомендации через своих HR, которые меня уже знают. А пару лет назад все устраивались через тестовые задания и собеседования.
Спасибо за комментарий) Большая часть откликов на такие вакансии — это не программисты, а выпускники курсов. Кто-то накрутил себе опыт, а кто-то — нет, но это не отображает реальную картину вещей. С тем же успехом тысяча дворников могут откликнуться на вакансию ТОП-менеджера, потому что на каком-то курсе им сказали, что они теперь ТОП-менеджеры, и надо просто накрутить опыт в резюме, чтобы обойти "глупые" фильтры.
Тут есть две стороны медали.
С одной стороны — работодатели с большим недоверием относятся к кандидатам, и непонятно, кого приглашать на собеседование, из-за чего самих собеседований становится меньше.
С другой стороны — когда реальный программист с хорошим опытом и подготовкой приходит на собеседование, за него хватаются руками и ногами, так как не взять его на работу за любые деньги — означает провести ещё 100+ собеседований, фильтруя выпускников курсов.
Получается, что кандидатов больше, но при этом хороший кандидат имеет больше возможностей торговаться по зарплате, так как искать второго такого — долго и дорого. Сейчас редко бывает ситуация, когда работодатель может выбирать хотя бы даже из 3–5 хороших кандидатов, как было раньше, и отказывать тем, кто хочет хотя бы немного больше денег.
Если сейчас вдруг весь мир накрутит себе опыт программирования в резюме и будет подаваться на все вакансии, то зарплата программиста вырастет ещё больше. Потому что каждый квалифицированный программист превратится в алмаз, который днём с огнём не сыщешь (уже).
Большое количество откликов без сохранения качества этих откликов приводит только к удорожанию найма и, как следствие, росту зарплат. Вот если бы все 1000 были хорошими программистами, да хотя бы даже 10% из них, тогда можно было бы говорить о какой-то конкуренции.
Я думаю человек имел ввиду авторизацию под разными пользователями для приложения и для миграций схемы БД. Чтобы приложение не могло менять схему БД. Это и так само собой всегда должно быть. Если он имел ввиду другое, то так конечно никто не делает. Это сложно и избыточно. Возможно только в каких-то специфичных случаях, но я такого не встречал. Обычно пользователя в БД создают для разграничения прав для приложения или его частей, миграций и т. д.
А почему нет? Не вижу ничего, что может быть сложным. ORM это хорошо, но каждый должен понимать как оно работает и не нуждаться в ORM как в инструменте для оптимизации. Тем более что оптимизация в ORM это часные случаи а в общем случае все зависит от того, насколько хорошо разработчик понимает, что он делает.
Приведите пример когда ORM что-то оптимизирова лучше, чем это может сделать разработчик? Не должно быть такого, что вы не понимаете SQL, который генерирует ORM. Тогда использование ORM действительно вредно и только для учебных проектов прокатит такой подход. Или маленьких MVP, которые потом кто-то будет переписывать.
Разработчик должен отлично владеть SQL и знать внутреннее устройство БД. Иначе с ORM в руках он сделает все очень плохо.
ORM не избавляет вас от необходимости изучать SQL и БД. Все запросы и миграции написанные с ORM всегда нужно проверять.
Нагрузка маленькая. Экономия около нулевая. Актуально может быть только в специфичных случаях, когда мы строго ограничены в ресурсах.
Была у меня как-то задача оптимизировать ML приложение для работы на обычном ноутбуке, который поедет к заказчику на завод. Вот там нужно было экономить даже на спичках, так как была бизнес причина для этого и ограничение в ресурсах конфигурацией ноутбука. А если нет бизнес причины, то любая оптимизация\работа это оверинженеринг.
Но даже если, у вас есть специфичные причины думать о нескольких мегабайтах, это не означает, что ORM плохой выбор для других проектов. А в случае миграций и админки это вообще не актуально.
Сильно это как? Есть бенчмарк вашего проекта? На сколько быстрее время ответа? На сколько дешевле сервера? Без конкретики "сильно влияет" это абстрактная информация ни о чем. Такая же абстрактная как и бенчмарки в вакууме из интернета.
Можно не писать запросы на ORM, а использовать Query Builder это хорошее решение, но не отменяет одновременного использования ORM для миграций и админки. Если конечно вы не считаете, что Query Builder тоже "сильно влияет"
Использование SQL Builder, не исключает использование ORM для миграций и LOW-CODE админки. Если конечно в вашем стеке существует ORM с админкой и вы знаете ORM или готовы изучать. Если такая ORM существует, то не использовать ее, это потеря скорости разработки.
У меня как-то был очень активный спор с командой на эту тему. Не хотели внедрять ORM, так как просто никто кроме меня в команде с ними не работал или очень мало и просто не хотели изучать.
Нужна была админка и команда на полном серьезе хотела писать ее самостоятельно и выделить целый квартал времени для фронта и бэка.
В итоге я за выходные ее сделал всю на LOW-CODE решении с ORM. Показал команде и с тех никто на эту тему не спорит, надо изучать ORM или нет. В запросах в приложении ORM не использовали.
В статье не идет речь о том, что надо всегда и везде использовать ORM. В целом нельзя даже объективно рассуждать, что лучше, если не владеете достаточно хорошо хотя бы одной ORM а также SQL и внутренним устройством БД. Нет гарантии что в вас говорит разум, а не психогический блок перед изучением чего-то нового. Как многие говорят птичий язык ORM.
Знать сам SQL и внутренее устройсвтво БД нужно в любом случае. Тут опять же он знал как писать на ORM и просто писал бездумно. Пришел другой разработчик, который знает только как писать на SQL, и потому переписал все на SQL (ему так тоже проще).
В статье я подчеркиваю, что нужно знать SQL и внутренее устройсвтво БД в любом случае. В вашем случае, вам бы все равно пришлось переписывать, то что он написал бы на SQL.
Каждому проще делать так, как умеет. Поэтому так много противников ORM и так же много их адептов, ведь это что-то, что тоже нужно уметь использовать. Найти причину не изучать не сложно. Вместо ORM можно подставить SQL в этом утверждении суть не меняется.
Люди хорошо владеющие ORM извекают максимум из его эффективности и отлично знают сам SQL, и используют его там, где ORM не эффективен.
Смысл ругать ORM за то, что ваш разработчик не понимал что делает.
SQL Builder хорошее решение для запросов в приложении, но не повод отказываться от ORM для миграций и админ панели. У нас во многих сервисах используется SQL Builder (не самописный) для запросов и все равно используем ORM для описания моделей, миграций и админки.
По поводу произовдительности уже отвечал, что оверхед там не большой. Даже на больших нагруках (у нас 20+ млн пользователей) он не станет узким местом. Позже дополню статью своими ответами в комментариях. А сложнее становится, когда запрос с фильтрами, а какие именно фильтры зависит от логики. И тут начинается склейка строк и т.д. Разработчики хорошо знающие SQL используют ORM не просто так.
В статье есть об этом и в комментах уже отвечал. Я сам не раз видел на ревью, что человек даже знаная про SQL-инъекции, иногда случайно вставляет переменную через форматирование строки. Человеческий фактор всегда будет стрелять. Чем больше проект и разработчиков, тем чаще. В маленьком проекте на 5 человек за этим следить относительно просто, а когда у вас большой проект особенно монолит над которым работает 100+ программистов уже сложнее. Один раз на ревью не заметят и уже могут быть огромные финансовые и\или репутациаонные потери для проекта.
В статье есть об этом и в комментах уже отвечал. Я сам не раз видел на ревью, что человек даже знаная про SQL-инъекции, иногда случайно вставляет переменную через форматирование строки. Человеческий фактор всегда будет стрелять. Чем больше проект и разработчиков, тем чаще. В маленьком проекте на 5 человек за этим следить относительно просто, а когда у вас большой проект особенно монолит над которым работает 100+ программистов уже сложнее. Один раз на ревью не заметят и уже могут быть огромные финансовые и\или репутациаонные потери для проекта.
Да, но проблему SQL-инъекций это не решает. Удаление таблицы это просто пример. Любое несанкционированное изменение\извлечение данных большая проблема и мне сложно представить, что все это можно решить на уровне СУБД. Что-то можно, но врядли это будет делаться для предотвращения всех SQL-инъекций скорее по другим причинам.