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

в разработке продуманность и енвайромент решает,

оно(продуманность и вообще технологичность) при прочих равных лучше чтобы было ибо та ды оне проще умозреть

но есть трабла совместимости поколений интерфейсов - поэтому я реально угорел когда недавно(ну меньше декагода) прочёл(может и раньше но видимо в прошлые разы как-то был совсем в не контекста) Программист-Навигатор Бахмана ну и уже совсем недавно полистал(pdf) русскоязычные книжки времени второго издания Дейты - где ещё не было всеобщей и окончательной оскулизации - так там чуть ли не на асме ibm/360 всякие деревья B*+ и прочий угар кутежа структур(хранения) данных

ну и да когда обнаруживаешь что Ульман(один из авторов дракона(книги)) угорал по копулятору sql (ну для отличных планов) то как-то лучшее понимаешь насколько о"пту"шилось(ну может всегда таким было в отличии от ожидания) обучение базам_данных на профильных специальностях когда аналоги книжки Рогова (об internals субд) ваще за горизонтом большинства экземпляров вышек

Можно ли разрабатывать деревянные изделия не зная лобзик (только но циркулярной пилой)?

Можно, и что-то даже будет получаться, но низкое качество и шанс испортить продукт и пальцы будут достаточно высокими.

SQL (как и лобзик) - достаточно простая технология, уж можно несколько дней жизни выделить, чтобы разобраться с транзакциями, джойнами, индексами и хорошими практиками (1+n, selectin, lazy load, etc)

Я не такой любитель ит-археологии. Я как чукча - пою, что вижу.

Пост травмирован (как гусениц из мультика Гагарин) во вьюнстве насколько фундаменталистки массивы (array в этом смысле не отличимые в паскакале ал(ко|)голе60 ) что буквально не смог понять на каком слове потребно понимание ООП

По индустриально поархиалогив (особливо Byte от калистеники до перекройки) пришло понимани что публике не нужны неправильные регалии

Т.е sql как лингва франка особливо при коллективной разрабе

ну скорее нет. ну либо я совсем тупой, что конечно не исключено, но как бы вряд ли.

вот сайтик для обучения

https://www.sql-ex.ru/

я точно потратил больше 6 часов n лет назад и трудные упражнения решал не все.

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

А я не говорю что будет хорошо, я говорю что «можно и без sql». Как на известной пикче - можно жить и без яиц, но грустно.

В некотором смысле резолюции setl/sql это буквально векторизация из apl но не над скалярами-..-тензорами а над records

Зы: примечательна что изначальная Коддовская нотация так же двухэтажна что и в Цузевском «исчислении планов» как планкакюле

Тупейший double-spend на уровне БД

Идемпотентность вообще боль, и почему-то я ни разу ни в одном примере «как надо делать» не видел чтоб хоть кто-то на этот счет парился.

SQL - суперпрост. Теория множеств по сути. Чтобы разобраться, почему накрывается база от запросов, также не очень сложно - пара-тройка инцидентов рядом со знающими людьми и ключевое слово EXPLAIN ANALYZE

Идемпотентность вообще боль, и почему-то я ни разу ни в одном примере «как надо делать» не видел чтоб хоть кто-то на этот счет парился.

Я унылых авторов не читаю почти, потому статистики подобной у меня нет, но... Недавно для себя делал обзор одной книжки Матрина Фоулера — там были пример со стратегиями обработки конфликтов транзакций и разные варианты разрешения онных.

И да, недавно авиабилеты покупал — мне страница оплаты выдала ошибки на трёх разных языках, потому что в ней совершенно отсутствует тестирование чего-то, отличного от happy path.

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

Что про Рогова опус речнёшь?

Это одно из(будь только такого рода оно бы наверн эволюционно не закрепило) проявлений паразитизма в сословных «не основания не верить»

Что про Рогова опус речнёшь?

Каких таких Рогов?

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

Так Fujitsu сразу сказало заказчику, что «система ходить будет, но только под себя». Там кучу лет скрывали тот факт, что к системе был скрытый удалённый доступ — его нельзя «случайно» сделать.

g:

postgresql внутренности рогов

postgresql внутренности рогов

Я не понимаю, при чём тут вообще постгря к нашему треду.

Обычно вопрос задаётся наоборот: правильно ли использовать чистый SQL вместо ORM. На мой взгляд, да — правильно. ORM от лукавого.

рыч но (r)dbms internals как полезной специи при обучении sql

имха orm это попытка получить то что ожидалось от sql

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

т.е. матрёшка абстракций которая не то что бы рухнула под собственным весом но примечательно успех «nosql» был следствием краха объектных баз

Да, можно. Пацаны на ORM работали, SQL толком не знали. С AI вообще вайбкодеры появились, которые и ЯП не знают. Правда и бекенд от таких пацанов нафиг никому не сдался и работает криво и через раз, требуя кучи ресурсов вычислительных. Но вообще SQL так прост, что его и обезьяну можно научить понимать.

Что ты там изучал? SQL реально можно брать и ехать вместе с гуглом в проект. И изучать всё на лету. Я больше скажу, найти в том же интерфейсе pgadmin4 некоторые вещи - более сложная задача, чем SQL изучать и более полезная, например, посмотреть на что там тот или иной запрос раскладывается, чтоб понять а что это оно так лагает и как это можно оптимизировать. Просто там всё, просто надо не книжку скучную читать, а хотя бы реальный хеллоуворлд лепить.

А проблема возникает на этапе оптимизаций, когда высокие нагрузки начинают стучать в дверь. Вот там надо SQL знать и понимать, как и понимать когда надо делать нормализацию, а когда денормализацию БД. И это единственная причина, почему бывает такая должность, как архитектор баз данных. Другое дело, что на каждые 10 проектов это нужно только в 1.

Можно и так

лол кек не столько sql сколько «структуры датых и алкоритмы» в части <db internals>

ибо sql изначально интерфейс для всякого датахранения

при трудоустройстве на позицию администратора гей-клуба
Это получается что я самозванец?

Если ты не гей, то получается, что да.

DEVILRU:

улови:

http://rkka21.ru/docs/turing-award/cb1973r.pdf

смекай"

Я ХЗ, у меня в ВУЗ-е была целая куча дисциплин про дискретку, структуры данных и алгоритмы, так что всё датахранение вообще кажется тривиальным. Вот нетривиально - это визуализировать эти данные. Например, сделать рендер формул с произвольной глубиной индексов (ака многоэтажные) на основе xml (да точно так же как в xml, тегами индексы). Современные браузеры так умеют, но далеко не все - имеют те у которых двигло серьёзное (гугловское, мозиловское или майкрософтовское, но и код для этого в них ого-го какой запутанный и навороченный в плане абстракций, не захочешь их тянуть к себе - абстракции эти), остальные поделия так не могут.

дык у всех было - и да сд и а достаточно тривиальны

лол кек в другом

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

как результат физической моделью в буклетах по rdbms для «самого массового листателя» оказываются таблицы и связи - а не «реальные»(чуть ближе к железу) структуры над raw_memory

т.е. проявление явления что для 80% задач достаточно навыка а не понимания

Краткий ответ: Если БД (в смысле и схема и данные) уже есть и нужно лишь извлекать из неё данные, то - да, пока можно без SQL. В ином случае - нет. И дело не в SQL а, как тут писали, в понимании БД (начиная от выбора её «марки»). Взрослая БД это бездна.

Хайп по носкул имел 2 причины - первая есть задачи, где носкул сильно быстрее, а с появлением облаков где платят не за сервер, а за реальную нагрузку это важно (оттого же взлетели всякие микросервисы, граали и го, а ванильной корпоративной джаве поплохело), а вторая причина - искусственный идиот, там куча данных в неструктурированном виде, а неструктурированный вид, это то, что очень плохо ложится на реляционные СУБД, потому как они про упорядоченные связи между таблицами. Понятно, что реляционных носкул баз данных раз два и нет, ничего кроме, пожалуй графовых СУБД похожего на реляционные БД не даст. Может ещё какая экзотика упоротая, где вместо SQL сочинили свой язык.

А у тебя есть выбор? Давай я одним постом всё напишу

Первый вариант, когда нужны бумажки от какого-то ФСТЭК или отечественный софт, там у тебя вариантов нема, какой-нибудь постгрес-про и всё.

Второй вариант - тебе нужна встроенная база к какому-то приложению, тут sqlite без вопросов, если язык не java, у java может захотеться использовать H2, если нет желания привязываться к платформозависимым либам.

Третий вариант - у тебя большая взрослая БД и тонны нефти, а так же на тебе нет санкций (юрисдикция не в РФ и прочие страны под санкциями США в пролёте) - Оракл без вариантов.

Четвёртый вариант - ты хочешь оракл но третий вариант не годится (нет денег/санкции душат) - PostgreSQL твой выбор.

Пятый вариант - ты старый пых-пыхер или не любишь PostgreSQL - бери MySQL.

Считаешь MySQL старьём, которое пилят полтора калеки - твой выбор MariaDB.

Ты - извращенец, который всё делает только для windows - для тебя есть изумительный Microsoft SQL Server.

Всё, на этом основные SQL СУБД закончились. Оптимизировать можно всё почти всегда, но постгри лучше всех ИМХО.

Бездна там не столько в выборе БД, сколько в оптимизации запросов и денормализации базы.

Маш код (особливо сворачивающий ставшими константными проверки полиморфя на ходу) ИСЧО быстрей

Как оказалось(при должном контексте) ОчевиДно остротупоконечность noSql vs Sql возможна при неадекватных абстракциях

Которые легче достижимы при инфляции лэйблов

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

Не понимаю сленг. Очевидно что есть задачи где надо или SQL или NoSQL и там нет альтернатив или то или это. Очевидно также, что есть задачи, где могут быть построены и применены хорошие, годные абстракции, которые можно делать как вокруг SQL, так и вокруг NoSQL. Многие почему-то забывают, что абстракции обычно не откуда-то прибитые гвоздями возникают, а ты сам можешь их придумывать такими, какими хочешь. Иногда удобнее одни, иногда другие. Знаю кучу примеров, когда вместо всей красивой и кучерявой теории люди используют Excel и не парятся вообще. Надо бы СУБД, веб технологии, обмазанные ИИ, а там ексель, к тому же криво-косо свёрстаный. И работать с ним всё равно лучше и удобнее, оказывается.

Ну, так-то всё правильно и метко, но выбор марки не обсуждался, я писал про изначальный вопрос - способ общения с БД. А под «бездной» имел ввиду подкапотное пространство и варианты его полноценного использования.

А детали общения прибиты к основному ЯП (библиотеки там всякие разные, драйверы, коннекторы). Но если обобщать, то опять только 3 с половиной способа - ODBC (дефолт если нет ничего родного), JDBC (ну не могли же джависты опять не выделиться эксклюзивно для Java, хотя разгадка проста - джависты любят стандарты и из драйвера/коннектора тоже сделали стандарт, так что считаю за половину способа), драйверы для ЯП, как правило, построенные вокруг того же ODBC (как JDBC, только выкрутас поменьше в плане оптимизаций и требований, зато вроде как многие из них берут заботу о SQL инъекциях, если программист не валенок, что увы обычно не так, он именно валенок и про SQL инъекции узнаёт только после того как его взломают), ORM (это такой подход, опять куча фреймворков и библиотек и все ещё к ЯП прибиты). Если глобально смотреть, то способа вообще только 2 - SQL или ORM, хотя есть гибридные уродцы «ни то ни сё». Если со стороны СУБД смотреть, то там тоже бывает всякое родное, у того же postgresql (остальные базы я постольку-поскольку знаю, в ВУЗ-е тыкал, но деньги за них не получал) есть libpq - самое низкоуровневое для сишки, драйверы для разных ЯП, JDBC (вот джавистам то неймётся, они свой стандарт сделали и его реализовывают ведь и учитывают), внутри есть ещё свой pl/pg-sql диалект для процедур ещё вроде как есть под другие ЯП, правда мне он так ни разу и не потребовался или почти ни разу, обычно хватает базового SQL. Но все эти libpq настолько нишевые, что знает про них полтора человека вне ниши, а использует вообще мало кто. Под капотом у СУБД тоже нет ничего особенного (хотя есть много оптимизаций которые и отожрали то гигантское количество человеко-часов что потратили на них), вся теория СУБД стоит вокруг одного единственного раздела дискретной математики - реляционной алгебры ну и немного цепанули ещё 2 раздела - теорию множеств и кортежи. Всё это изучается в профильных ВУЗ-ах математиками (я изучал по крайней мере, вся эта теория укладывается в 4 лекции, т.е. месяц по 1 паре в неделю). Да база математики должна быть к тому моменту (кажется это был 3 семестр). Но там тоже нет ничего особенного. А вот с предметной областью, с тем какие именно абстракции надо выбирать это как раз та самая бездна, про которую ты и говоришь. Потому что там столько вариантов и все правильные. Один просто работает лучше другого на ряде задач. А вот какие задачи будут именно у тебя - вопрос, на который обычно можно правильно ответить только после того как будет готовый продукт постфактум, собрав статистику пользователей. Что в свою очередь может привести к тому, что базу данных придётся дорабатывать годами (по факту её надо переделать с нуля, но она работает и в ней уже есть данные, так что изменения надо делать на лету, понятно что с тестированием и т.д.. но тут всё равно есть риски положить проду и именно они приводят к хорошим зарплатам у архитекторов баз данных).

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

в грубом смысле бд это распухшая структура данных для персистентности и мультидоступа

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

клёво конечно что ща моща железа такова что массам достаточно select в 90% + update/insert в остальных 9%

Нынче говно разрабатывать можно вообще ничего не зная.

Слишком много акцента на теорию компиляции и интерпретации (ИМХО абсолютно бесполезная фигня к тому же примитивная по своей природе). СУБД на это наплевать по большому счёту.

уточню

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

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

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

Так-то да, но вот например, сейчас мне приходится использовать libpq вместо любименького OCI и страдаю. Там совсем разный уровень - в OCI можно было в клиенте получить указатель на объект в памяти сессии (выглядит как возврат out-параметра из процедуры в void*). Или, можно было отдать на клиента полупрокрученный открытый курсор (out-параметр ref_cursor). А теперь смотрю - у Кликхауса вообще http-протокол :) А бездна - это я про все те оптимизации с чтением блоков, буферы, планы/статистики и прочие проекции из inmemory таблиц на диск.

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

Оракл тоже этим забавлялся, вспоминаю с содроганием.

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

Не буду спорить. Я именно про разработку. Designer/2000 и всё-всё-всё.

Добро пожаловать в разработку. libpq это про низкий уровень и оттуда боль.

Не, боль от того, что libpq не достаточно низок и функционален по сравнению с OCI :)