это как "маппить" питоновые функции

Ну в большинстве случаев так и есть.

А вот когда начинаются агрегации и реляции то да, сложно

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

А вот когда начинаются агрегации и реляции то да, сложно

А нахрена вам РЕЛЯЦИОННАЯ бд без реляций?!))

Реляции по внешнему ключу тоже легко разруливаются

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

идем в таблицу по owner_id и вытаскиваем оттуда поля, вот и построили родительский объект. При этом в коде никаких упоминаний про join не будет

> Это частный случай. Вот этот частный случай и решает орм, и случай очень типичен

Бложики, форумы, интернет магазины, CRM системы почти все им покрываются

> идем в таблицу по owner_id и вытаскиваем оттуда поля, вот и построили родительский объект. хрен вы чего построите по динамически создаваемой таблице

> Это частный случай. Вот этот частный случай и решает орм, и случай очень типичен

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

Бложики, форумы, интернет магазины, CRM системы почти все им покрываются

ну ты понел)

Ой, этого и без ORM всегда происходит :)

У нас в базе были почти везде ORM объекты, и штук 10 мест где были аццкие реляционные raw запросы, которые драйвер тоже легко позволяет делать.

Но если бы не было ORM объектов то при изменении схемы нам бы пришлось бегать по сотне мест и подправлять запросы, это ваще не ок

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

Против лома нет приема. Если растет сложность логики и инфраструктурная нагрузка, то как ни исхитряйся, все будет трудно и проблемно.

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

нужно стремиться к минимизации источников данных и мест, создающих/модифицирующих данные

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

И что ты предлагаешь? Заюзать ORM чтобы не работать с сырыми данными?

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

Воот

То есть хотели убежать от орм, потом решали сложности построения динамических запросов и все равно к орм пришли

ну, то есть, это не прямое отображение таблиц на объекты, а некие бизнес-сущности, структура хранения которых не важна для остальной части приложения

Ну да, там целый дивный мир DDD, агрегаты, слои хранения и прочее и прочее

и, естественно, там будут некоторые компромиссы между удобством и скоростью)

Но если бы не было ORM объектов то при изменении схемы нам бы пришлось бегать по сотне мест и подправлять запросы, это ваще не ок

а могли бы API описать

Это попахивает старым добрым god классом с 100500 методами апи на все случаи жизни, и у каждого метода по 15 аргументов? =)

нет

ну вот на последнем большом SQL проекте так описывали: https://github.com/DSoftOut/pgator

создаётся натурально API, в данном случае - rest

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

Знаешь же зачем придумали GraphQL ? )

примерно догадываюсь. Оно там ЛЕЗЕТ в схему

Потому что загрузка сложной страницы через REST превращается из 100 запросов в базу в 100 HTTP запросов и в каждом 1 запрос в базу.

Это АПИ это все ровно те же яйца только в профиль

блять, ну значит не rest используйте, не важно что - принцип важен

Взяли выкинули слой объектов, подсунули слой JSON объектов, ну отлично )

НЕ объектов

функций вызываемых

{ "jsonrpc": "2.0", "method": "test_echo", "params": { "value_for_echo": "Hello, world!" }, "id": 1 }Вот это вот json объект

И возвращается тоже json объект

определение объекта в студию

ебанулись ООПшники, везде у них объекты мерещатся

https://www.w3schools.com/js/js_json_objects.asp

Подозреваю, идея GraphQL появилась, когда большую часть бизнес-логики вынесли на фронтэнд)

Ну в этом смысле объект, терминология у них такая. Но это не объект ORM или как в С++

это просто декларации функций по факту

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

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

Ага но JSON объект это придурки придумали так назвать.

назвали бы сообщением было бы меньше путаницы

Туда добавить еще метод с логикой и получится поведение

Туда добавить еще метод с логикой и получится поведение

Щито?

class Message(Json)

Объект с нулевым поведением)

Как они там у джавистов называются?

ValueObject

Или DTO

а в чём там суть?

Во многом, так всего и не объяснишь. Смотря с какой стороны смотреть :)

Суть в том, что это просто структура в терминах си)

Связанный набор данных

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

А если у вас прикладные кодеры схему БД пытаются понимать получится херня

Почему это херня? Может получиться и миллиардный бизнес

типа телеграма )

но чаще - херня

Почему это херня? Может получиться и миллиардный бизнес

Запомню - универсалный ответ)

Вот на сайте dlangru кто будет прикладным кодером а кто инженером БД ?

Надо там делать API для бложека?

везде надо где БД используется. Это же роли, так что может и один человек исполнять.

Ну и почему тогд он схему не сможет понять? Да там вообще будет стайная разработка.

Пришел аноним, сделал пулл реквест, кто-то его замержил.

Кто-то отревьюил.

Так может в плюсах просто кривые ОРМки все? Которые только проблем доставляют. Такое тоже бывает.

Ну и почему тогд он схему не сможет понять? Да там вообще будет стайная разработка.

Может только это не надо - дальше API он не уйдёт.

Так может в плюсах просто кривые ОРМки все? Которые только проблем доставляют. Такое тоже бывает.

ORM сама по себе кривая концепция.

/me больную мозоль разворошили

Ну не кривее чем машинный нуль какой-нибудь

ты о чём?

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

нельзя, верно

Ну и как теперь жить? Ракеты то взлетают как-то, иногда.

А CAP теорема это тоже концепт с кучей компромиссов

Про БД и ОРМ: БД не отдают вам свои внутренние "переменные" (таблицы) или их части - они отвечают на запросы. Это две большие разницы. Поначалу когда вы делаете heloo world всё отлично, вроде бы ОРМ работает потмоу что вам кажется что вы куски из таблиц запрашиваете. Но рано или поздно наступает момент когда эта концепция даёт трещину. И переписывать приходится всё, потмоу что к тому времени идея ОРМ пускает корни по всему проекту (связность)

Ну и как теперь жить? Ракеты то взлетают как-то, иногда.

Никто не использует float для описания рациональных дробей

> Но рано или поздно наступает момент Да не обязательно он наступает

"Обязательно в жизни специалиста", поправлюсь

на 10 проекте

5 твиттеров, 2 телеграмма и потом херак - форум превратился в лапшу

Но без этого ты не сможешь стартовать )

ОРМ - необходимая ступень.

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

Но без этого ты не сможешь стартовать )

когда я был "молодой и зелёный" я шикарно стартовал - я сразу начал писать свою ОРМ)

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

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

Максимализм какой. Сколько тех запросов для форума надо? 10? полчаса делов.