Можно ли разрабатывать бэкенд не зная SQL (только но ORM)?

Наверное возможно, но зачем…

В чём проблема «знать SQL»? Проблема решается часов за 6 чистого времени (три дня по 2 часа в день, например), если не меньше.

Прям за 6? Потратил я сегодня 8 часов +- - изучил до joinов

Я вот нисколько не тратил на именно абстрактное «изучение sql», само собой изучилось по мере надобности. Для начала достаточно знать select, insert, update, delete в их тривиальной форме:

SELECT список полей FROM имя таблицы WHERE условие;
INSERT INTO имя таблицы SET поле=значение, поле=значение, ...;
UPDATE имя таблицы SET поле=значение, поле=значение, ... WHERE условие;
DELETE FROM имя таблицы WHERE условие;

Ну естественно зависит от индивида. Но мне интересно, что там можно 8 часов ДО join’ов изучать?.. С них же всё по сути начинается…

Но в общем, если так прикинуть, то если до join’ов (я так понимаю, ты только всякие SELECT, INSERT, CREATE и т.п. + всякие WHERE с ORDER BY изучил?) дошёл за 8 часов, а по моим прикидкам до них час… То тебе ещё часов 40 до полного просветления. Это всё равно не та проблема, которая должна стать препятствием для разработки бэкенда.

Не зная SQL это делать можно, думаю. Но просто не очень понятно, ради чего. Звучит скорее как челлендж, чем как упрощение задачи.

Можно. Есть монга и прочий nosql. Есть вообще расширение к редису чтоб сделать из него бд. Есть всякая аналитика где тоже вместо sql хрен знамо что бывает

я решил перекатиться на алхимию (sqlalchemy). Прошерстив доку, понял что запросы повторяют один в один SQL

Тебя ничего не смутило в названии SQLalchemy?

Можно ли разрабатывать бэкенд не зная SQL

Да

Экспертом по SQL не являюсь, но… а в чем проблема выучить несколько типовых запросов, тем более в век ИИ который всё подскажет и объяснит

изучил до joinов

А собственно, что ещё-то там осталось? Джойнишь нужные таблицы нужным образом, фильтруешь по where x=y, сортируешь по z desc, ограничиваешь по limit n. Всё, SQL кончился, поздравляю.

Ну такая вот жизнь в этих вебмастерах что надо знать

• sql( лучше пару диалектов)
• яп для написания бэкенда
• js/html/css для написания фронтенда (к js лучше добвить typescript)

А собственно, что ещё-то там осталось? Джойнишь нужные таблицы нужным образом, фильтруешь по where x=y, сортируешь по z desc, ограничиваешь по limit n. Всё, SQL кончился, поздравляю.

там еще бывают хранимые процедуры и триггеры, если движок базы поддерживает. Да и потом там куча инфы как хранить, мониторить и прочая - пределов совершенству нет.

–

по топику: да можно быть, но изучение SQL только в плюс будет.

абстрактное «изучение sql»

- там обычно нужно уметь сделать join по time buckets и в SQL запросе аттрибуцировать, например, юзера из разных систем учёта по имеющимся в таблицах данным. Вот тогда «SQL изучен».

Group by + having забыл

Можно. Есть монга и прочий nosql. Есть вообще расширение к редису чтоб сделать из него бд. Есть всякая аналитика где тоже вместо sql хрен знамо что бывает

Кстати, недавно разбирал очередную парашу с гитхаба на монге (Twikoo). Люди реально написал это ничего не понимая в монге, и ничо.

Блин, люди делают криптобиржы. оперирующие миллионами долларов, ничего не понимая в БД и безопасности:
https://www.penligent.ai/hackinglabs/crypto-exchange-data-leak-deep-dive-mong...

Ещё с начала криптоистерии бесчисленное кол-во криптобирж было тем или иным способом взломано/ограблено:
https://www.infoq.com/news/2014/04/bitcoin-banking-mongodb/
Тупейший double-spend на уровне БД. Это «серьёзный бизнес» — что можно ждать от какой-то закрытой энтерпрайзной софтины или школьного проекта на гитхабе? Вон, вв бриташке десяток человек посадили в тюрьму до того, как не вскрылась ошибка обработки данных в БД.

Так что как бы да, сам SQL можно изучить за пару дней — но потом чтобы научиться его использовать нужны годы общей подготовки.

1. можно

2. когда это нужно?

возми какой учебник по структурам хранения данных желательно с главой по истории субд  — тогда станет понятней зачем и когда полезен промежуточный язык определения и манипулирования данными как там пролог мимо проходил и почему чистая декларативность манипуляций долго проигрывала императивным курсорам

чисто для умозрительности представь обычный массив ( хэш ваще через key-value прям «NoSQL» ) но синтаксис не через привычные имя_индекс_в_квадратных_скобках а какой ране коболистый get put

как оказалось join в ansi sql тока в sql92 завезли так что чел(ТС) возможно не так уж и не знаком с

where достаточно ( особенно когда есть аля *= и =* )

аксиоматически вроде как клауза агрегирования чисто синтаксический сахар ( как и join при наличие ассиметричных where) - ну да без декларативной агрегации более курсористо(императивно) - но ващет sql всегда был компромисс компромиссов - а по мере роста излишков cpu шёл в сторону всё большей декларативности ( которая лучше может быть оптимизирована ибо меньше ограничений накладывает на субд)

Однажды я обнаружил, что тоже хочу быть бэкендером, но SQL знал на тот момент очень поверхностно. Я нашел сайт в задачами по SQL и сидел тупо их решал. Если было непонятно, то открывал книжку/гуглил. Этого было достаточно чтобы прокачать базовый уровень. Остальное уже по необходимости. Сложные запросы очень редко требуется писать, да и LLM есть.

https://stepik.org/course/63054/promo

Интерактивный тренажёр по Sql

бриташке десяток человек посадили в тюрьму

там еще и самоубийства были из-за этого и не могли доказать десяток десяток лет что ли

Есть монга и прочий nosql. Есть вообще расширение к редису чтоб сделать из него бд. Есть всякая аналитика где тоже вместо sql хрен знамо что бывает

это хрен знает что в этих ваших монгах может оказаться (и зачастую оказывается) таким хрен знает чем, что потом в цирке перестанешь смеяться. И свалишь обратно на постгрес.

Для прикладного написания бекенда CRUD приложения надо разобраться с двумя понятиями.

1. N+1 проблема.

Получаем список из 250 пользователей, потом еще на каждого из 250 пользователей делаем по запросу для получения url его аватарки. И того 1+N: 1 запрос на список, N запросов на каждый элемент списка.

Решается при помощи JOIN.

2. Индексы в базах данных.

Этот концепт сложней. С прикладной точки зрения: те поля по которым будет происходить поиск надо индексировать.

С позиции механизма дела обстоят так, если просто искать по базе данных сложность будет O(N) - где N количество записей в базе данных.

• 1 - одну посмотрели.
• 2 - две посмотрели.
• 1024 - 1024 посмотрели чтоб найти.
• 32768 - 32768 посмотрели чтоб найти.

В худшем случае надо будет перебрать все записи.

Когда поля по которым идет поиск про индексированы, то поиск идет быстрей сложность Log(N), где N количество записей.

• 1 - сделали 1 движение.
• 2 - сделали 2 движения.
• 1024 - 10 движений сравнений и нашли нужную запись.
• 32768 - 15 движений-сравнений и нашли нужную запись.

Итого сравниваем. Не индексирования база данных 1024 сравнений, индексирования 10. Не индексирована база данных 32786 сравнений, индексирования 15 сравнений.

Индексация БАЗ данных дает возможность искать БИНАРНЫМ ПОИСКОМ.

Вот это вот две идеи которые покрывают 80% всей разработки. Поняв их можно спокойно писать при помощи ORM толком не вдаваясь в синтаксис языка SQL.

Ну и Qwen, DeepSeek, ChatGPT, Grok в помощь. Разберите этот текст, вам там напишут детали. Это так затравка для Prompt.

там еще и самоубийства были из-за этого и не могли доказать десяток десяток лет что ли

Я хотел по этому приколу статью накатать, но руки не дошли. Боже, там такая забавная история была, где судья принял решение о том, что в программах не бывает ошибок. Ну, как «не смогли доказать»... эксперты и ответственные люди и так всё знали, а обвиняемые, они же по факту пострадавшие, не имели средств и связей, чтобы донести свою правоту до судьи, а судья в этих ваших комплюктерах ничего не понимает. Это прежде всего дискредитация судебной системы была, как ни странно, поскольку показало чудовищную некомпетентность онной.

Вообще-то скуль разработывали как простой человекопонятный язык для общения с бд, чтобы булгактеры зарплату людям могли считать.

особенно когда есть аля *= и =*

Ух, прям продолжаете удивлять широтой познаний.

Одна из незабываемых болей переписывания запросов в Sybase с этими звездочками на Postgres'овский SQL с JOIN'ами.

Я пишу на петухоне

Дальше не стал читать. Прям эталонно, молодец.

Знаю базовые CRUD команды и фильтрацию, но остальное

нужно редко

про explain analyze еще (ну или как-там план запроса смотреть) хотябы поверхностно поизучай.

поможет, когда синтаксис изучишь и пойдут вопросы что я делаю не так.

дяденька я не настоящий сварщик

чисто обнаружил буквально на днях что join не был в (перво)SQL а токмо с sql89 - лолкек в том что когда «меня зовоут 'вова' учусь в универе я» ознакамливали с sql как то автоматом закусился с преподом о не нужности(избыточности в смысле чистоты- так то оно как бе более явное - если вообще не считать существование некой неявной таблицы констант из которой where берёт значения наряду с перечисленными во from) join —

т.е ознакомления с эволюцией инженерного решения очень полезно при должном уровне обучения — ибо тогда очевидней почему трейдоффы таковы

ваще хайп с noSql показатель насколько «культура торговли» влияет на молчание инженеров на базаре.

зы. noSql как явление ( в части отказа от промежуточного слоя универсального языка манипуляции и языка определения данных - который как и кобольчик был в первую голову не для творителей субд на машкодах а для менеджерья среднего звена с общепонятным пинжин-английским) чисто очередная итерация упрощаем/усложняем вразных аспектах ибо по сути nosql это же более тесная привязка прикладухи к физической структуре данных от чего как раз и обещал избавить sql Ж)

ну нет жи

сукл был для удешевления ай-бе-ме переноса легаси на всё более оторванные от реальности движки баз данных — без необходимости воскрешения гуру структур хранения данных окаменелостей что бы понят и простит

декларативность ровно от-ту-да-же

upd: Psilocybe курни Пограмист-навигатор Бахмана и его проигрыш в споре с Коддом и Ко(ко) — он жи(Бахман) дедушка noSql

и да - первой бд на работе была Sybase :)

но про *=/=* «вспомнил» на днях читая коменты на рутреке об ненужности/нужности груберовской кривопереведённой книжке об sql от 1993 р.х. где буквально нет join

Ты реализуй его без SQL на файлах сам. Поизучай где затыки, где приходися автоматизировать удобства. В итоге хоть поймешь зачем тебе вообще нужна SQL и будешь вообще осознавать чего от нее ждать.

Попробуй что нибудь практическое и нагруженное. И желательно в стесненных условиях.

ну подтяни знания sql не фиг и проблема (простой диалект), проблема как ты без этого работал

Если кратко, то: Можно, но не нужно.

Я почему-то сразу вспомнил старый стишок, когда было еще более-менее актуально:

Если к xxxx приспособить
Процессор фирмы Cray -
Можно срать в два унитаза,
В сорок тысяч раз быстрей!

Сейчас с роем агентов, и не такой понос можно родить, без знаний.

https://habr.com/ru/companies/postgrespro/articles/899380/

https://postgrespro.ru/education/books/internals

вот можешь - если задача требует сам часть internals в своём бэкенде воплотить - ща прст проще import psycopg2

но лучшее:

import duckdb

тот же pickle эт же (де|)сереализация и хранение между пусками состояния

https://www.anekdot.ru/id/600953/

А о какой истории идёт речь? Прям интересно стало

королевская почта

фильм(сюриал) с Саймоном Пегом

Mr Bates vs The Post Office

не с пегом

В базовой части - можно, но когда перейдешь к оптимизации, придется писать тонкости руками. Плюс хорошо помогает понять план выполнения запросов.

забавно что sql важнее для пирамид где трудящиеся наймиты - если же в одного амбар али ракету собираешь то слой sql не всегда выгоден в долгую

т.е легко представить альтернативную вселенную где нет массивов в раме - а все индексируемые сущьности персистенты и ходят к ним через sql

я решил перекатиться на алхимию (sqlalchemy).

Алхимия менее очевидная, чем просто SQL. Сначала пишешь запрос на sql, потом придумываешь запрос на алхимию. И то, если уперся в диалект определенной версии, то от алхимии будет больше вреда, чем пользы.

For these users,natural language or menu selection (3,4) seem to be the most viable alter-natives. However, there is also a large class of users who, while they arenot computer specialists, would be willing to learn to interact with a com-puter in a reasonably high-level, non-procedural query language. Examplesof such users are accountants, engineers, architects, and urban planners.It is for this class of users that SEQUEL is intended.

Donald D. Chamberlin Raymond F. Boyce
SEQUEL: A STRUCIURED ENGLISH QUERY LANGUAGE

Кодд вроде той же проблемой казуалов занимался и идею реляционной алгебры у него сперли.

Это и есть SQL (Structured Query Language). Создавался изначально для бухгалтеров. А что потом в него накрутили – тут уже без документации порой и ногу сломать можно.

Тоже самое и с шелл. Писать на нём шахматы изначально в него не закладывалось.

менеджерью всегда легче втулить «вы попустите этих фриков из замков из кастальи слоновьей - зачитываясь чё они наскрибуют на общепонятном (кобол там сквад/последовательный) - тот же нонешней ой-ииии заменит ровно речекряков т.е ща отчёты рисовать и втирать что всё хороше ой-и лучшее чем те ещё лизкоблюды»

основной бизнес был именно на отвязки прихладух от потрохов - Бахман на этом проиграл «Кодду»

так то в 2k-проблему_эпоху оказалось что для уеба на коленках сикл просто был излишен пока снова не вылезла проблема «а теперь со всем этим легаси с прошлого этого стратапа-единкорога нуна бы и взлететь как обещано»

+ всегда так было (ну пролог из лиспа вылупившийся как раз начало 70ых) - желание удешивить доступ переложив владение навыком на машину ( те же копуляторы жи тоже задумывались - не нужно знать потроха вы только бормулы строчите)

Мне кажется, что тебе надо не ставить вопросы из серии «что есть куча», а просто доучить ту часть SQL, которую ты не знаешь (предполагаю, что речь про разнообразные JOIN-ы). SQL, да, прелестен тем, что запросы можно писать годами, не пользуясь JOIN-ами, но это неоптимально, да.

Тут, впрочем, возникают два вопроса.

1. Сам стандартный SQL на самом деле не очень-то и большой, даже с джойнами. Что-то очень-очень неочевидное появляется, когда ты углубляешься в диалекты конкретной СУБД, и там этого неочевидного действительно много, но тут надо уточнять, про какую СУБД идёт речь.

2. Если писать на чистом SQL, постепенно появляется ощущение, что при большом количестве таблиц и запросов ты уже пишешь прикладную задачу на ассемблере с кучей лишнего кода. Так что я, наоборот бы уже, двигался в сторону ORM. Другое дело, что по работе я уже не особо плотно с БД занимаюсь, а в хобби-проекте это, скорее всего, не особо оправдано.

В любом случае, просто доучивай SQL, это более конструктивно, чем думать, что же ты продавал. :)

Так это классика межделмаша выкатывать тулзы для написания программ без программирования (один процес-сервер чего стоит) и рождать этим новую прослойку рукожопов. Но если говорить про теории заговра то я лучше поверю, что архитектура второго жвс была сделана под максимальный жор цпу ибо лиценция шла от числа ядер.

+ всегда так было (ну пролог из лиспа вылупившийся как раз начало 70ых) - желание удешивить доступ переложив владение навыком на машину ( те же копуляторы жи тоже задумывались - не нужно знать потроха вы только бормулы строчите)

более того обученный наймит дороже удержать - т.е. опрощение доступа к железке с многих сторон выгодно владельцу железок - не случайно что для пользования gui(именно интуитивно понятных изводов а не в целом) логика часто мешает - да и арифметика бывает не просто бесполезна а вредна на уровне самого общеупотребимого интерфейса

не случайно возникновения апокрифа:

Элементарно: сделай продукт, которым даже идиот может пользоваться, и только идиоты будут его использовать...

пролог

Да ладно, пролог эпичен, я до сих пор без пузыря факториал на нем не раскурю.

да не заговор сё

вот у унихов в их лабе все секретари/рши вполне регулярками на постоянной основе пользовались  — тока засада именно в том что если навык не нужен(пока и если) в массовом пользовании то эволюционно выигрывает нагромождение трюков не ортогональных

в частности поэтому plan9(и в частности их регулярки которые отказались от строк) не смогли «кто раньше встал того и тапки» systemV|bsod

как и линукс когда миникс ужо бредил микроядром взлетел через wintel

кто раньше встал того и тапки

Это потребительский уровень, в разработке продуманность и енвайромент решает, иначе бы все скобки писали до сих пор и жаба бы никому не нужна была.

когда миникс ужо бредил микроядром

Так в том то и дело, что бредил в тот момент ни тулинг не был готов, ни понимания что этого монстра без внутреннего идл не запилить.