Как Django и Alchemy (не) справляются со сложным SQL
Ғылым және технология
Михаил Попугин (S7, Python-разработчик) @ Moscow Python №77
"Иногда проект перерастает Django ORM, и в игру входит SQLAlchemy. Расскажу, как каждый из них справляется (или нет) с нашей сложной бизнес-логикой. Ещё немного о том, почему мы выбрали SQLAlchemy, а что всё-таки можно было сделать, не выходя из Django".
Слайды: moscowpython.ru/meetup/77/dja...
MoscowPython: moscowpython.ru
Курсы Learn Python: learn.python.ru
Moscow Python Podcast: podcast.python.ru
Пікірлер: 5
Ого, это же Миша!
7:37 Ну например в oracle не получится сделать такой запрос, там обязательно необходимо указать from select 'string' from dual; Вопрос и как работать тогда с oracle ? На офф сайте либы sqlAlchemy, написано что она поддерживает oracle И почему у Автора выпал выбор именно на подтаблицы вместо view, в которую можно запихать любую логику
Стараюсь избегать CTE для сложных запросов. Очень часто это приводит к тормозам. При том в разное время запросы обрабатываются по разному. Причина в возникновении обратных join при построении плана выполнения. Когда связи обрабатываются наизнанку. Для не больших таблиц это не заметно, но для больших это возникает очень часто. Как выход из ситуации используются временные таблицы.
Интересно, а они рассматримали такой вариант как: 1) предварительно где либо откладывать по каждому рейсу нужные признаки (именно то что отфильтровывалось в таблицах), а потом 2) при выборке просто брать строки с нужными готовыми признаками. Так как таких признаком может быть очень много, то проще такое хранить или в json поле той же постгри, либо сразу взять no-SQL бд, например монгу.
ORM у Django даже с Q выражениями скорее базовая, жалко, что запарно в Django использовать что-то кроме самого Django ORM