Есть смысл использовать SQLAlchemy для своих программ?

важнее не размер кода, а размер базы. Для мелкой сгодится даже sqlite - на много легче и проще.

База большая, несколько десятков гигабайт. Это история стоимости криптозащекоинов, снимаемая каждые ~25 секунд. Но таблицы простые и не связанные.

ORM нет смысла использовать в 95% случаев. Другое дело, что SQLAlchemy — это не только ORM, но еще и построитель запросов, а это совсем другой зверь. А поскольку таблицы у тебя простые и несвязанные, то и построителя запросов тебе тоже не нужно.

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

Если смущает именно sql строками посреди кода, можешь взять PugSQL.

А так, чем сильнее задача отличается от типичного CRUD, тем более унылы ORM в использовании.

Ну и у SQLAlchemy есть часть которая называется Core, по сути построитель sql-запросов, без маппинга на объекты. Тоже может быть полезной штуковиной.

Она не очень-то и удобная, есть аналоги получше:

https://github.com/coleifer/peewee https://github.com/sdispater/orator https://github.com/kennethreitz-archive/records

Ну и у SQLAlchemy есть часть которая называется Core, по сути построитель sql-запросов, без маппинга на объекты

На сколько оно прожёрливое по сравнению с ручной долбёжкой эскьюэля? Есть вообще смысл этим заморачиваться если SQL не пугает? Или профит только в том что код будет понятнее падаванам для которых «SQL СЛОООЖНАА»?

Да вот мне тоже интересно, это моветон или нет, пихать SQL код в код. Коннекты беру и отдаю я вручную.

Вот допустим можно-ли через SQLA object.dict записать одним вызовом основываясь на загруженной карте?

Что как маленький, реализуй свое DAO и успокойся. ORM снизу реализован по такой же схеме.

На сколько оно прожёрливое по сравнению с ручной долбёжкой эскьюэля?

По сути оно просто строки конкатенирует. Ещё там своя подвязка над пулом соединений, универсальный формат строки подключения и прочий сервис, нивелирующий разницу между различными python db api драйверами.

Есть вообще смысл этим заморачиваться если SQL не пугает? Или профит только в том что код будет понятнее падаванам для которых «SQL СЛОООЖНАА»?

Один бонус с которым сам сталкивался — есть вещи которые на sql сделать трудновато, всякого рода динамические фильтры, сортировки, опциональные джойны и всякое такое. Ну как сложно, или держать рядом несколько вариантов одного запроса, или всё таки конкатенировать-подставлять строки, что чревато. А с sqlalchemy core чтобы вместо имени колонки на сортировку подставить любезно предоставленный пользователем DROP TABLE нужно приложить некоторые усилия.

О какой карте речь?

Тьфу, db.Model

Я бы сказал что это зависит от структуры твоих данных и запросов.

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

Если у тебя (слишком) много простых (со скалярными полями) таблиц и простые же запросы (т.е. самое сложное - join’ы, без CTE, json’ов, агрегаций, хитрых подзапросов, оконных функций и т.д.), я бы взял ORM, чтобы описывать структуру один раз в питоне и ни о чём больше не думать, а базу, миграции и ещё некоторые плюшки типа ленивых полей получать автоматом. Вообще, я с ORM плотно не работал и не знаю насколько сложные запросы они нынче умеют генерить - может список «без» выше уже и неактуален.

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

• Чистый SQL, можно писать сколь угодно сложные и эффективные запросы. Появилась новая фишка в постгресе - взял и начал использовать, не думая поддерживает её ORM и будет ли когда-то поддерживать
• Разделение кода на питоне и SQL (тут надо сказать что ORM от этой проблемы не избавляет - при его использовании не уйти от смешивния питона и ORM-диалекта SQL), как доп. плюшка - нормальная подсветка синтаксиса
• Нет других ограничений ORM, например когда-то алхимия не умела asyncio, и не уверен научилась ли. Тут можно генерить и синхронные и асинхронные функции - не важно
• Реализация по факту довольно простая, никакого sql парсить не надо, нужно только распарсить аннотации, создать функцию нужного формата которая внутри вызовет execute с телом запроса

Вот пример реализации: https://pypi.org/project/anosql/.

Ещё я видел похожую штуку в Repology, там прикручены ещё и jinja шаблоны - это конечно на любителя.

Тут https://github.com/phoglx/noorm немного другой подход - класс-обёртка над таблицей с операциями [], insert, update.

Это неправильный критерий. sqlite может и терабайты ворочать, индексу похрен прыгать в 100-й блок или в 100500-й. Важнее свойства типа пропускной способности и конкурентности.

Так у тебя ж реальная запись происходит не когда ты полю модели что-то присваиваешь, а когда session.commit делаешь. И да, один объект записывается за один вызов.

База большая, несколько десятков гигабайт

Нет, не большая.

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

Есть, в первую очередь ты будешь оперировать конкретными типами а не строками, отсюда упроститься написание юнитов, + возможно сделать нормальное кеширование так как точно будешь знать какие объекты меняются и какие взаимосвязи есть, и еще намного проще менять БД так как удалив поле ты сразу узнаешь какие места нужно поменять ещё

Это я знаю, я хочу меньше кода чтобы было. Только я уже понял что это можно сделать, надо просто загрузить ORM как classname(dict)

Что-то оно меня по сравнению с psycopg2.extras + queue вводит в уныние.

На сколько оно прожёрливое по сравнению с ручной долбёжкой эскьюэля? Есть вообще смысл этим заморачиваться если SQL не пугает?

У меня были запросы на локалхосте считанных связанных таблиц, в которых были тысячи символов в одном SQL. Проблема даже не в том, что «СЛОООЖНАА», а в том, что тупо требует много ручной работы. Как ассемблер. А не так давно столкнулся с тем, что построитель запросов не умеет запрашивать столбцы, начинающиеся с цифры. Если экранировать все названия столбцов, то внезапно окажется, что читаемость серьезно страдают. А построитель запросов может скрыть все подобные проблемы.

Я еще повеселился с ячейкой True.