Не ORMом единым

[Vasia529]

А почему RawSQL, а не django.contrib.postgres.fields.KeyTextTransform?

[cvaynex]

Не KeyTextTransform, потому что очень мало про это документации, проглядели.

Сейчас попробовал, и он не приводит правильно, типы, взрывается на null значениях, даже если явно прописать Cast в DecimalField:

Cast(KeyTextTransform(partner.reporting_currency, 'hotel__currency_data'), DecimalField())

[voron3x]

Да, django ORM мощная штука. Мы также юзаем всю мощь annotate/aggregate для всяких вычисляемых полей (для соблюдения нормальной формы БД). Но ИМХО сложность этого запроса очень высока, и поддержка его в дальнейшем будет очень дорогой. И скорость для ручки в 3 секунды тоже так себе результат.

Мы в своей практики для такого юзаем OLAP решения. Если данные как-то связанны с временем то timeseries DB, если случай как у вас то чтонить типа Vertica. И в этих таблицах уже храним денормализированные представления которое легко и удобно обсчитывать.

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

[cvaynex]

OLAP
Vertica
timeseries DB

У нас всё это тоже есть, но больше используется для аналитики. Думаю стоит попробовать внедрить и в продукте.

И скорость для ручки в 3 секунды тоже так себе результат.

Это только первый ответ для большого партнера с сотнями бронирований. После
первого запроса кешируем результат на несколько минут и ручка отвечает в пределах 100 мс. За последние 90 дней среднее время ответа ручки — 600 мс. Для нас приемлемо, тем более, что это не ключевой функционал сервиса.

[voron3x]

А почему бы еще не использовать решение в лоб но в фоне? Данные не выглядят как realtime можно формировать их раз в сутки и отдавать готовые на дашборд.

Плюсы:
* Проще код, проще поддержка
* Дешевле изменения
* Быстрая отдача
* Легче тестировать
* Нагрузка в вeчернее или ночное время на один slave

Минусы:
* Не реалтайм
* Инфраструктуры для бэкграунд подсчета (разработка, поддержка)
* Доп. данные для хранения

[Tiendil]

Не видел ничего тормазнутее Django ORM. Лет 5 нада это был полный адище с кучей клонирований query при конструировании сложного запроса, сейчас это исправили и стало просто медленно.

Если есть возможность использовать сырой SQL, используйте его. Он не сложнее ORM и это позволит исключить огромный непрозрачный слой абстракций.

Django ORM можно использовать для админок, простых и/или редких запросов и прототипов. Для остального лучше не надо.

[veesot]

Наверное джанго можно использовать не только для простых запросов.
К примеру с использованием поддержки JSON(B), кастомного Manager/переопределением objects + RawSQL можно делать уже вещи поинтересней. В джанге очень много основано на переопределении и сделав свой собственный QuerySet на основе стандартного, можно написать свою альтернативу взамен EAV.

А «сырой» SQL… да, может он и очевиден, но зачастую не так удобно поддерживать его после тех кто писал этот SQL.

[Tiendil]

Можно всё.

Но если взять профайлер и посмотреть сколько времени тратится в подготовке запроса (а не выполнении), то может резко расхотеться его использовать.

[resetme]

Можно же один раз подготовить запрос и потом его переиспользовать.

[007913]

А не практичнее для сложных запросов использовать SQLalchemy? Ведь посути она может работать парралельно джанговскому ORM по тем-же моделькам той-же базы если речь идет о только выборках без блокировки?

[cvaynex]

А не практичнее для сложных запросов использовать SQLalchemy?

Соглашусь с ArsenAbakarov, чем меньше поддерживать технологий и описаний моделей, тем лучше.

[tuxi]

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

Если это так, вы можете дать оценку, насколько с точки зрения перфоманса и нагрузки, было бы выгодней (или наоборот) разработать свою «ORM» используя например паттерны того же М. Фаулера, под конкретные нужды конкретной предметной области?

[cvaynex]

Да, разрабатываем сами.

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