true_engineering Jun 17 2014 at 14:51

Вводная по сложным запросам в SQLAlchemy

7 min

89K

True Engineering corporate blogPython*SQL*

+17

Comments 10

kivsiak Jun 17 2014 at 17:04

>— Расход памяти на вызовы функций, на хранение в памяти генераторов. Строка все-таки занимает меньше места в памяти.

Несколько смущает этот момент. Если это становиться хоть как то заметным то разве мы не можем сгенерировать запрос и затем уже использовать сконструированный?

estatic Jun 17 2014 at 19:02

Верно в случае, если не надо динамически строить запросы. К примеру, для оптимизации выкидывать цепочку из JOIN. Опять же под разные базы не нагенерируешь

kivsiak Jun 17 2014 at 19:20

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

estatic Jun 17 2014 at 20:11

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

Tanner Jun 17 2014 at 21:27

Мне кажется, вы немножко лукавите, говоря о таких преимуществах ORM, как:

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

Понять ORM без знания SQL невозможно. И SQL-код во всех примерах, кроме, пожалуй, самого простого JOIN, будет более компактным и удобочитаемым, чем обращения к ORM. SQL вообще очень литературен.

Хотя основного смысла применения ORM — писать на одном языке, а не на двух — я не отрицаю. И всё же ORM для более-менее сложной работы с данными — гиря на ногах.

kivsiak Jun 17 2014 at 22:30

Чем хорош ORM. В один прекрасный день вы пишете красивый компактный sql код. Все отлично. Потом вам захочется добавить добавить какое либо динамическое условие к запросу. Потом захочется добавить что нибудь типа педжинации. Потом сортировку по пользовательскому параметру… В один прекрасный момент окажется что вместо красивого компактной строчки sql кода приходится возиться с кучей стрингбилдеров и условных операторов. Это я еще про необходимость поддержки разных диалектов не говорю. Это надо будет как то поддерживать. Что то уйдет в хелпер методы. Потом появятся фабрики запросов… В один прекрасный момент вы проснетесь с понимаем того что написали еще одну ORM.

Чем хорош SQL Alchemy в отличие от той же DjangoORM — в первую очередь это конструктор запросов. Довольно гибкий и удобный. Во вторую меппер. Ну и всякие плюшки типа пулла конешенов, кешерирования и изоляции транзакций.

gleb_l Jun 17 2014 at 23:06

Это имхо напоминает пословицу — пока толстый сохнет — худой дохнет. К моменту, когда исходно стройно написанная на чистом SQL система настолько обрастает костылями, что с трудом поддерживается, ее ORM-based брат уже обычно существует в состоянии зомби, не в силах переварить ни объем данных, ни интенсивность запросов к ним, ни конкурентность их модификации.

-1

estatic Jun 18 2014 at 06:47

меня больше «напрягает» только одно. SQLAlchemy еще не имеет как таковую стабильную версию. Уже как лет 9 прошло с момента начала работ, но радует, что все активно развивается и особо не глючит.

alexander007 Jun 19 2014 at 11:06

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

Есть еще один вариант. Делают денормализации, вешают обработчики событий на CRUD операции, превращают SQL в NoSQL и на выходе получают не проект, а какашку.

P.S. Сам однажды вляпался в такое г.

B7W Jun 20 2014 at 12:30

Могли бы добавить генерируемый SQL к примерам. Во первых интересно что получится, во вторых более наглядно.