Фриланс-проєкти

Фриланс-проєкти

Postgres (Supabase) SQL - Поахувати кількість записів між датами

Name: Postgres (Supabase) SQL - Поахувати кількість записів між датами
Price: 1000 UAH
Availability: InStock

Бази даних та SQL — неправильно зазначені категорії?

1000 UAH

0. Є таблиця users, де id = id юзера (uuid).

1. Є таблиця usages, де зберігаються всі запити до API (тому що API має лімітувати кількість доступних запитів залежно від підписки). Має created_at.

2. Є таблиця 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 день

Добрий день.
Бази даних - основна спеціалізація. Є ідеї як вирішити Вашу проблему.

У списку не показані ставки, приховані замовником чи фрилансером з 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: телефони, дублі, міста

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