А чем, собственно, плох Django ORM?

>Ведь мало того, что в джанге можно использовать тот же SQLAlchemy заместо джанго ОРМ. Но и сам этот ОРМ далеко не так плох. Его более чем достаточно чтобы быстро сделать базу любой сложности.

Джанговский ОРМ хорош, потому что прост и удобен. Сложный JOIN (три таблицы с промежуточной, например) на нём не сделаешь.

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

Хотя, в большинстве случаев, джанговского ОРМ-а хватает.

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

Кроссплатформенность для разных БД мешает.

> Сложный JOIN (три таблицы с промежуточной, например) на нём не сделаешь.

вот конкретно три табилцы с промежуточной (2 + 1), на нем сделаешь.

А вот тот же sqlalchemy в плане возможностей намного мощнее, но и для освоения сложнее.

SQLA - это реально SQL на питоне, только более многословный.

ОРМ сам по себе не особо нужен, в частности когда всё доходит до больших нагрузок. А вся дьянга практически гвоздями привазяна к ОРМу и если, допустим, пишешь бэкенд с интенсивным использованием возможности СУБД, то значительная часть плюшек дьянги просто лежит рядом. Да, я знаю что считается будто ОРМ в дьянге не привязан к остальным компонентам, но это далеко не так.

вот конкретно три табилцы с промежуточной (2 + 1), на нем сделаешь.

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

Зато есть такой вот монстр на sqlalchemy, я тут не виноват, но так вышло:

    query = Site.dbquery.outerjoin(Site.queries).\
            options(contains_eager('queries')).\
            outerjoin((Position, and_(Position.query_id == Query.id,
                                      Position.check_date > from_date))).\
            options(contains_eager('queries.positions')).\
            outerjoin(Query.urls).\
            options(contains_eager('queries.urls')).\
            options(contains_eager('queries.urls.queries')).\
            order_by(Site.site_name, Query.query, Position.check_date.desc())  

Я бы побоялся такое на джанговском ORM писать.

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

Во-первых, тем, что ORM.

Во-вторых, тем, что гвидня поганая

Disquss и Mozilla вполне себе обходятся без SQL. Да, конечно, приходится думать головой и оптимизировать, и, действительно, от кое-каих фич отказываться. Но тем неменее, эти два компании своим оптом подтверждают, что ORM пригоден для больших нагрузок.

Может быть просто у вас проблемы с архитектурой базы данных?

> Disquss и Mozilla вполне себе обходятся без SQL

На сколько я помню disqus рассказывал, как они уменьшили нагрузку в несколько раз, воспользовавшись где-то постгресовским with recursion.

Mozilla

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

>> Disquss и Mozilla вполне себе обходятся без SQL

На сколько я помню disqus рассказывал, как они уменьшили нагрузку в несколько раз, >воспользовавшись где-то постгресовским with recursion.

Не помню такого. Пару выступлений смотрел. РАзработчии выступали против raw-sql.

Mozilla

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

Не считаю это хаками. Разрабы расшири функиционал ORM для своих нужд. OOP модель, никто не мешает расширять функционал.

ORM - не панацея, но это во стократ лучше raw-sql. Экономия времени разработки, сопровождеиния катастрофическая.

А чем, собственно, плох Django ORM?

да нормальный ORM, у которого есть свой класс задач, которые он прекрасно решает

>Может быть просто у вас проблемы с архитектурой базы данных?

Там очень специфические источники данных и алгоритмы их вывода. Тут либо доставать всё одним запросом сразу, либо делать ~1000 запросов по-отдельности.

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

Тут надо было брать не-SQL БД по-настоящему, но на момент написания проекта не было опыта работы с этими базами.

Кроссплатформенность для разных БД мешает.

Кроссплатформенность для разных СУБД это такой миф.

Тем, что ОРМ. От него не так много толку, как пропагандируется. И все расно в итоге рн становится похож на SQL

> внутри все прибито гвоздями

Получается, тут обманывают?

ORM - не панацея, но это во стократ лучше raw-sql. Экономия времени разработки, сопровождеиния катастрофическая.

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

Кроссплатформенность для разных СУБД это такой миф.

+.

cherrypy+sqlalchemy+mako = нашефсё

Ничем не плох. Отличный ORM. Ругают либо за сильно специфичные вещи, либо по причине собственного скудоумия.

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

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

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

Всякие PL/SQL намного менее выразительны, нежели python, ruby и даже php. Писать и поддерживать их - это ад, за который платят очень большие деньги. Делать это стоит только тогда, когда производительность ну очень критична.

[quote]Всякие PL/SQL намного менее выразительны, нежели python, ruby и даже php. Писать и поддерживать их - это ад, за который платят очень большие деньги. Делать это стоит только тогда, когда производительность ну очень критична.[/quote]

Совершенно верно.

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

Он для валидации и представления SQL'ных типов данных в типы данных ЯП

И при этом становится:
1) непереносимым между языками
2) завязанным на конкретную библиотеку

Всякие PL/SQL намного менее выразительны, нежели python, ruby и даже php

Не намного ORM-код выразительней SQL-ного. Вот анонимус и привел пример. ИМХО, ни разу не выразительней pure SQL.

> Я бы побоялся такое на джанговском ORM писать.

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

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

С этими задачами превосходно справляются биндинги(интерфейсы) к языкам. Не везде, конечно, всё замечательно, но в общем достаточно хорошо. В частности psycopg2 для питона всё это делает из картобки. ОРМ нужен таки не для этого.

Всякие PL/SQL намного менее выразительны, нежели python, ruby и даже php.

Во первых не идёт речи о впихивании всего в PL/SQL, достаточно сделать некое API в качестве прослойки. Во вторых, в СУБД есть PL кроме SQL, те же явы и питоны тоже можно найти. Но для манипуляциями объектами внутри СУБД ничего лучще PL/SQL таки нет.

> И при этом становится:

1) непереносимым между языками

Конечно, потому что в разных языках разные типы данных, КО.

2) завязанным на конкретную библиотеку

А это чем плохо? При выборе любой библиотеки ты оказываешься на нее завязан.

Не намного ORM-код выразительней SQL-ного. Вот анонимус и привел пример. ИМХО, ни разу не выразительней pure SQL.

Анонимус привел плохой пример.

> С этими задачами превосходно справляются биндинги(интерфейсы) к языкам.

Они тебе не дают, например, всякие URLField, IPAddressField вместе с валидацией, возможности кастомизации. Они не преобразуют ответ SELECT * FROM ... в нужный тебе объект, тебе придется это делать самому. Также как get_or_create, getattr с ленивым запросом в базу и кэшированием и прочее.

Они тебе не дают, например, всякие URLField, IPAddressField вместе с валидацией, возможности кастомизации.

Дают. В psycopg, например, можно засунуть какой угодно кастомный тип данных и для PG это очень актуально т.к. к слону есть куча расширений с экзотическими типами, ОРМы с ними работать не умеют.

Они не преобразуют ответ SELECT * FROM ... в нужный тебе объект, тебе придется это делать самому

Ну и какой же мне объект нужен из 'SELECT * FROM'? В нужный _мне_ объект это можно сделать только руками, т.е. своим конструктором. ОРМ опять тут пролетает кроме совсем очевидных схем.

Также как get_or_create, getattr с ленивым запросом в базу и кэшированием и прочее.

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

Конечно, потому что в разных языках разные типы данных, КО.

а SQL - один. И, при необходимости, легко переносится.

А это чем плохо?

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

Анонимус привел плохой пример.

Все примеры, которые приводились были сопоставимы по усилиям написания и поддержки с pure SQL.
Также прошу не забывать о проблемах с кэшами при использовании ОРМ, о том, что некоторые ОРМ требуют подганять под себя базу и т.д.
Теоретическая выгода от ОРМ - их большая предметная ориентация. Но эта оринтация упирается в СУБД; не получается ее от базенки оторвать. Тебе все равно надо мыслить ее категориями. А под эту задачу лучше заточен SQL.

Они не преобразуют ответ SELECT * FROM ... в нужный тебе объект, тебе придется это делать самому.

А нахрена ТАК делать? Нахрена задачу уровня переганать данные из таблички в веб-морду делать с помощью маппинга таблицы в объектное дерево, чтобы снова трансформировать это дерево в таблички на вебе? Ощущения маразма происходящего у тебя не возникает?