Postgres (Supabase) SQL - Сохранение количества записей между датами

Name: Postgres (Supabase) SQL - Сохранение количества записей между датами
Price: 1000 UAH
Availability: InStock

Базы данных и SQL — неверно указаны категории?

1000 UAH

Проект переведен автоматически. Войдите или зарегистрируйтесь, чтобы увидеть оригинал 0 0 0Есть таблица users, где id = id пользователя (uuid).1 .Есть таблица usages, где хранятся все запросы к API (потому что API должен ограничить количество доступных запросов в зависимости от подписки).Имеет created_atВтораяЕсть таблица subscriptions, где для каждого user_id должен (или не должен) быть запис со status = 'active'♰ 'trialing'.Каждая запись имеет current_period_start, current_period_end.3 .Есть таблица user_activity, где есть поля executions_amount_used, executions_amount_granted.Таблицы 1-3 имеют foreign key user_id к users.Что нужно сделать: 1 .Необходимо эффективно на insert в usages (то есть когда троировали API и записали активность), по user_id в таблице user_activity записать количество usages, которые имеют created_at между current_period_start и current_period_end от подписки со статусом active или trialing.Если такой подписки нет, нужно удалить все usages пользователя (чтобы если он канцелировал подписку, то executions_amount_used брался за весь период, который есть в таблице usages).Не нужно использовать count(), нужно использовать estimates и функцию https://wiki.postgresql.org/wiki/Count_estimate. Данная функция уже есть и она работает, но запрос каким-то образом выдает рандомные данные, когда фильтр по дате.Это может быть quick fix, но может потребоваться перестроить логику тригера (вон также к вещам есть).Если есть лучшие предложения сделать это, было бы великолепно услышать.Но нам не нужно на каждый API call делать count по usages (таблица велика), поэтому API call смотрит только на таблицу user_activity и там должны быть актуальные цифры и все.Посмотрите внимательно экраны изменения знака < > вообще не работает, но оно ни в коем случае не учитывает дату.Также он может выдавать usage не с начала даты подписки, хотя все даты в UTC в базе данных.Поэтому есть рассинхрон, если подпись обновлена, оно поднимает usages с нерелевантной даты, к current_period_start, а должно быть только после current_period_start.Это тоже нужно фиксировать.

Ставки 3 Обсуждения 6

Александр Д.

22 0

Проекты 22
Оценка 5.0
Рейтинг 868

Бюджет: 1000 UAH Срок: 1 день

Добрый день .
Базы данных - основное специализация. Есть идеи, как решить вашу проблему.

В списке не показаны ставки, скрытые заказчиком или фрилансером c профилем Plus, а также ставки, нарушающие правила

Vitalii Valchuk 18 февраля 2024

Якщо вам не потрібен точний підрахунок, поточна статистика з таблиці каталогу pg_classможе бути достатньо хорошою, і її набагато швидше отримати для великих таблиць. 
Воно і буде показувати не точний підрахунок. Краще вірно побудувати індекси, тоді і підрахунок буде швидким.

Vitalii Valchuk 18 февраля 2024

Кількість живих рядків у таблиці. Це лише оцінка, яку використовує планувальник. Вона оновлюється командами VACUUM, ANALYZE та деякими командами DDL, такими як CREATE INDEX.

Vitalii Valchuk 18 февраля 2024

Але нам не потрібно на кожен API call робити count по usages (таблиця велика),  
ну так зробіть таблицю, де буде пораховано на початок і при кожній вставці - оновляти дані. буде більш-меньш точно і швидко

Maxim M

18 февраля 2024

Дякую! Тобто після створення індексів вже буде можливо робити select count(1) на кожен insert, не використовуючи count_estimate? Я так розумію, вона взагалі не підходить для даного завдання.

Vitalii Valchuk 18 февраля 2024

можете взагалі зробити окрему таблицю зі статусами і обновляти після кожного insert дані. тобто якщо вам потрібно просто кількість користувачів зі статусом active - то вам не потрібно знати їх id, достатньо порахувати кількість, записати таблиці і в тригері додати оновлення. як варіант

Olexandr Basalaiev 21 февраля 2024

Я бы использовал MATERIALIZED VIEW что обновляется по расписанию

Добавить комментарий

Актуальные фриланс-проекты в категории Базы данных и SQL

Разработка CRM-модуля «Обращения» в кастомной 1С (шинный центр)

Управление клиентами и CRM 12 ставок 31 июля

Не указан
Построение автоматической схемы движения товарно-денежных потоков

31 ставка 30 июля

Не указан
Поддержка Самотура и серверов под него

17 ставок 27 июля

1000 UAH
Чистка базы клиентов в SIMLA CRM: телефоны, дубликаты, города

Управление клиентами и CRM 41 ставка 27 июля

8000 UAH
Разработка аналитической системы с дашбордом

Автоматизация управления предприятием 43 ставки 20 июля

Не указан

Maxim M
Киев, Украина

Проектов 3
Оценка -
Рейтинг 95

Александр Д.

Ставки пока отсутствуют

Актуальные фриланс-проекты в категории Базы данных и SQL

Разработка CRM-модуля «Обращения» в кастомной 1С (шинный центр)

Построение автоматической схемы движения товарно-денежных потоков

Поддержка Самотура и серверов под него

Чистка базы клиентов в SIMLA CRM: телефоны, дубликаты, города

Разработка аналитической системы с дашбордом