Думаю ответ в том, что ОРМ написанный вне конкретного проекта поставляется с некоторым запасом универсальности, с тем чтобы подходить для использования в разных СУБД, из за этого их функциональность ограничивается возможностями самой ограниченной СУБД из списка совместимости.
Не хочу утверждать, но для тех запросов, для которых хорош ORM скорее лучше хранить данные в noSQL базах. Все таки запросы либо не оптимальные либо уровня я пишу свой первый селект возьму ка что ни будь с простым джойом и парочкой фильтров
в целом ORM хорош чтоб по быстрому накидать код и запилить mvp для презентации, вы же понимаете что будет тормозить в нагруженном продакшене, я бы попробовал выполнить у себя но есть большой риск что положу базу
Ну не могу сказать что он прям отвратительный, я ожидал худшего если честно. То что не самый оптимальный это факт. Очень жалею что не могу показать его модификацию учитывающую локали хранящиеся в json в базе и в виде json же отдающий, он за то же время отдает все тоже самое но сегментированное по странам
А что значит первый запрос в питоне можно написать? LIMIT OFFSET не всегда получается использовать, если лента изменится может быть ситуация когда при подгрузке мы дважды загрузим то что уже есть на странице либо пропустим часть данных
коллеги подсказали что здесь вокруг этого еще оконная функция может быть типа:
WITH base AS (
SELECT lag(rn, :count_before) OVER window_sorting lag,
lead(rn, :count_after) OVER window_sorting lead,
subq.*
FROM ( <query> ) as subq
WINDOW window_sorting AS ( <order> )
)
SELECT * FROM base
JOIN (
SELECT COALESCE(lag, 0) AS lag,
COALESCE(lead, 99999999) AS lead
FROM base
WHERE id = :starts_from_id
) sub ON base.rn BETWEEN sub.lag AND sub.lead
где rn это
row_number() OVER ( <order> )
чтобы выбирать заданное кол-во записей вокруг определенного id с учетом сортировки
Я не могу к сожалению показать то что хочу, но вот банальный пример из набора агрегатных функций:
select * from (
SELECT s.id,
s.name,
count(ss.id) as subscribers_count,
count(ss.id) FILTER (WHERE ss.cdate > now() - interval '1 month') as last_month_subscribers,
count(ss.id) FILTER (WHERE ss.cdate between now() - interval '2 month' and now() - interval '1 month') as previous_month_subscribers
FROM t_society s
JOIN t_society_subscriptions ss on ss.society_id = s.id
WHERE s.type in (3, 5)
AND s.removed = false
GROUP by s.id
HAVING count(ss.id) > 0
) as subq order by subq.last_month_subscribers - subq.previous_month_subscribers desc;
собственно тоже самое может быть в виде json с такими же данными но разбитыми по регионам {ru:...,en:...} для каждого society, и возможностью сортировать уже по трендам в произвольных списках регионов, типа для Европы или типа для франкоговорящих
что за гадания, без убедительных объяснений (если логика неочевидна и они требуются) любой код должен оставаться в песочнице, без инфраструктуры для тестирования с любой технологией в лужу сядешь, без раскатывания код на продакшн не попадет
Последствия? работает десятилетиями и каши не просит. Вот пример: есть таблица с пользователями, с правами пользователей, с сообществами на которые они подписаны, с правами на чтение/владение в самих сообществах, с контентом (включая специфические фильтры конкретных постов в json), c локализациями, c тегами и с лайками, нужно сформировать пользователю выдачу согласно его прав, предпочтений, исключить все что он игнорирует и отсортировать по дате публикации учитывая кол-во лайков (Чем старее пост тем больше ему нужно набирать лайков чтобы держаться вверху ленты), порядок таблиц — до десяти миллионов записей, актуализировать сортировку в пределах минуты, выдавать 20 постов из любого места отсортированной ленты для любого конкретного пользователя в пределах 100мс
Я не топлю за то, что бы писать всю бизнес логику внутри СУБД. Хотя в каждой конкретной задаче могут быть исключения. Но git давно уже умеет хранить изменения в DDL, а помимо PgAdmin есть DataGrip от JetBrains, в двоем они все кейсы покрывают. Можно еще поспорить насчет специфичности, т.к. Postgres фоловит стандарты Ansi SQL сравнительно лучше своих ближайших open source конкурентов. Я за баланс, для меня это скорее призыв одуматься тем, кто забыл как пользоваться SQL. Современные ORM ввиду своей (универсальности=>ограниченности) отучили многих коллег думать. Много раз видел как вместо того чтобы SQL функцией в пару строк получить готовые данные за десятки миллисекунд ребята гоняли гигабайты между стойками чтобы потом напрячь python и не расслаблять оперативку и ждали сотнями мс
На дворе 2020 — люди пытаются примерять petproject технологии на highload, автор прав в части выбора технологий, что там случилось с командой это не наше дело, зачем он вообще стал писать про их внутренние кадровые решения на этом сайте — не понятно. Если мидл бекенд не умеет работать с хранимками, мат вьюшками, sequence-ами, не знает как устроены индексы и чем sql отличается от no sql — значит такие требования у менеджмента компании к техническим специалистам. Если проект живет на одном сервере, в одной стойке, в одном дата-центре, на одном континенте — значит такие требования бизнеса.
Думаю ответ в том, что ОРМ написанный вне конкретного проекта поставляется с некоторым запасом универсальности, с тем чтобы подходить для использования в разных СУБД, из за этого их функциональность ограничивается возможностями самой ограниченной СУБД из списка совместимости.
Не хочу утверждать, но для тех запросов, для которых хорош ORM скорее лучше хранить данные в noSQL базах. Все таки запросы либо не оптимальные либо уровня я пишу свой первый селект возьму ка что ни будь с простым джойом и парочкой фильтров
в целом ORM хорош чтоб по быстрому накидать код и запилить mvp для презентации, вы же понимаете что будет тормозить в нагруженном продакшене, я бы попробовал выполнить у себя но есть большой риск что положу базу
Ну не могу сказать что он прям отвратительный, я ожидал худшего если честно. То что не самый оптимальный это факт. Очень жалею что не могу показать его модификацию учитывающую локали хранящиеся в json в базе и в виде json же отдающий, он за то же время отдает все тоже самое но сегментированное по странам
а можно теперь сгенеренный SQL в студию?
А что значит первый запрос в питоне можно написать? LIMIT OFFSET не всегда получается использовать, если лента изменится может быть ситуация когда при подгрузке мы дважды загрузим то что уже есть на странице либо пропустим часть данных
коллеги подсказали что здесь вокруг этого еще оконная функция может быть типа:
где rn это
чтобы выбирать заданное кол-во записей вокруг определенного id с учетом сортировки
Я не могу к сожалению показать то что хочу, но вот банальный пример из набора агрегатных функций:
собственно тоже самое может быть в виде json с такими же данными но разбитыми по регионам {ru:...,en:...} для каждого society, и возможностью сортировать уже по трендам в произвольных списках регионов, типа для Европы или типа для франкоговорящих