Стараюсь избегать CTE для сложных запросов. Очень часто это приводит к тормозам. При том в разное время запросы обрабатываются по разному. Причина в возникновении обратных join при построении плана выполнения. Когда связи обрабатываются наизнанку. Для не больших таблиц это не заметно, но для больших это возникает очень часто. Как выход из ситуации используются временные таблицы.
7:37 Ну например в oracle не получится сделать такой запрос, там обязательно необходимо указать from select 'string' from dual; Вопрос и как работать тогда с oracle ? На офф сайте либы sqlAlchemy, написано что она поддерживает oracle И почему у Автора выпал выбор именно на подтаблицы вместо view, в которую можно запихать любую логику
Интересно, а они рассматримали такой вариант как: 1) предварительно где либо откладывать по каждому рейсу нужные признаки (именно то что отфильтровывалось в таблицах), а потом 2) при выборке просто брать строки с нужными готовыми признаками. Так как таких признаком может быть очень много, то проще такое хранить или в json поле той же постгри, либо сразу взять no-SQL бд, например монгу.
Стараюсь избегать CTE для сложных запросов. Очень часто это приводит к тормозам. При том в разное время запросы обрабатываются по разному.
Причина в возникновении обратных join при построении плана выполнения. Когда связи обрабатываются наизнанку.
Для не больших таблиц это не заметно, но для больших это возникает очень часто.
Как выход из ситуации используются временные таблицы.
Ого, это же Миша!
7:37
Ну например в oracle не получится сделать такой запрос, там обязательно необходимо указать from
select 'string' from dual;
Вопрос и как работать тогда с oracle ?
На офф сайте либы sqlAlchemy, написано что она поддерживает oracle
И почему у Автора выпал выбор именно на подтаблицы вместо view, в которую можно запихать любую логику
Интересно, а они рассматримали такой вариант как: 1) предварительно где либо откладывать по каждому рейсу нужные признаки (именно то что отфильтровывалось в таблицах), а потом 2) при выборке просто брать строки с нужными готовыми признаками. Так как таких признаком может быть очень много, то проще такое хранить или в json поле той же постгри, либо сразу взять no-SQL бд, например монгу.
зачем все это делать если можно написать raw sql запрос?)
ORM у Django даже с Q выражениями скорее базовая, жалко, что запарно в Django использовать что-то кроме самого Django ORM