Бюджет: 1000 UAH Термін: 1 день
Добрий день.
Бази даних - основна спеціалізація. Є ідеї як вирішити Вашу проблему.
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. Це теж треба пофіксити.
Бюджет: 1000 UAH Термін: 1 день
Добрий день.
Бази даних - основна спеціалізація. Є ідеї як вирішити Вашу проблему.
Якщо вам не потрібен точний підрахунок, поточна статистика з таблиці каталогуpg_classможе бути достатньо хорошою, і її набагато швидше отримати для великих таблиць.Воно і буде показувати не точний підрахунок. Краще вірно побудувати індекси, тоді і підрахунок буде швидким.
Кількість живих рядків у таблиці. Це лише оцінка, яку використовує планувальник. Вона оновлюється командами VACUUM, ANALYZE та деякими командами DDL, такими як CREATE INDEX.
Але нам не потрібно на кожен API call робити count по usages (таблиця велика),ну так зробіть таблицю, де буде пораховано на початок і при кожній вставці - оновляти дані. буде більш-меньш точно і швидко
Дякую! Тобто після створення індексів вже буде можливо робити select count(1) на кожен insert, не використовуючи count_estimate? Я так розумію, вона взагалі не підходить для даного завдання.
можете взагалі зробити окрему таблицю зі статусами і обновляти після кожного insert дані. тобто якщо вам потрібно просто кількість користувачів зі статусом active - то вам не потрібно знати їх id, достатньо порахувати кількість, записати таблиці і в тригері додати оновлення. як варіант
Потрібно розробити окрему CRM-систему для централізованої обробки всіх роздрібних замовлень з різних каналів продажу (Prom, Rozetka, власні сайти та ручні замовлення). Основні вимоги: Єдиний реєстр замовлень з усіх джерел із збереженням інформації про джерело та його статус. Окремий внутрішній статус CRM, який працює незалежно від статусу на маркетплейсі чи сайті, із двосторонньою синхронізацією статусів там, де це підтримується. Гнучка інтеграція з 1С: для кожного джерела адміністратор може окремо ввімкнути або вимкнути автоматичне вивантаження замовлень. Інтеграція з перевізниками для автоматичного створення ТТН, збереження її номера в CRM та передавання номера ТТН на Prom і Rozetka. Інтеграція з Checkbox для створення проєктів чеків, використовуючи налаштовувану відповідність способів оплати, з подальшим контролем фіскалізації. Підтримка ручного створення замовлень (телефон, Viber, Telegram, Direct тощо) з повним подальшим циклом обробки через CRM. Усі API-ключі та налаштування інтеграцій повинні керуватися адміністратором через інтерфейс CRM без участі програміста. Повний журнал дій і логування інтеграцій для контролю роботи системи. Основна мета Менеджер повинен мати можливість повністю обробити замовлення в одному інтерфейсі CRM — від отримання замовлення до створення документа в 1С, ТТН, проєкту чека та завершення замовлення, без необхідності заходити в кабінети Prom, Rozetka, сайтів, перевізників або Checkbox.
У нас працює синхронізація двох джерел даних із CRM. Система в цілому стабільна. Але залишається частина, які розсинхронізуються. Основна гіпотеза — в одному з джерел дані змінюються вже після первинної синхронізації, і ці зміни не завжди підтягуються в CRM. + данні в двох джерелах мають різні назви/ідентифікатори хоча являють собою одні і тіж сутності
Завдання:розгорнути LLM-сервіс,який знає всю документацію компанії тавідповідає на запитання менеджеріввідділу продажів. Що є зараз:замовник збирав прототип самостійно(окремий проєкт із завантаженоюінформацією про компанію,розміщений на сервері), алеінформація з бази непередається в модель —імовірно, проблема з API. Коді доступи надамо. Першийкрок — аудит: полагодитинаявне абоаргументовано перезібрати з нуля. Необхідний функціонал: Завантаження всієї документаціїкомпанії: опис кожноїпослуги, регламенти, FAQ,ціноутворення (усі матеріалинадамо). Відповіді строго набазі завантаженихдокументів (RAG). Модель невигадує фактів; якщовідповіді в базі немає — чеснопро це повідомляє. Доступ для менеджерівза посиланням(веб-інтерфейс), завторизацією. Сценарії: менеджерставить будь-якезапитання про роботукомпанії; вставляєзапитання клієнта «як є» йотримує готову відповідьдля відправлення;знаходить потрібнийрегламент/звіт за запитом. Оновлення бази знань безрозробника (завантаженняфайлів через інтерфейсабо підключенупапку). Англійська мова. Історіязапитів для контролюякості. Технічні очікування:LLM через API(Claude/OpenAI —запропонувати з розрахунком вартостітокенів), RAG-пайплайн (векторнабаза, embeddings), хостинг нанашому сервері або в хмарі, HTTPS.Архітектура має дозволяти вмайбутньому підключити асистента доаналітичного сховища даних(паралельний проєкт). У відгуку вказати:прикладисхожих RAG-проєктів,стек, строк, вартість роботи таорієнтовну щомісячнувартість володіння (токени +хостинг).
Привіт Є невелике відділення, куди поступають пацієнти. Потрібно розробити просту "базу даних", в якій можна буде вносити розхідні матеріали, перпарати та інше, прихід вихід, а також списувати використання на конкретного пацієнта. Функціонал який необхідний Довідники Медикаменти Витратні матеріали(можливість вносити вручну) Пацієнти(можливість вносити постійно нових і видаляти тих хто виписаний) Працівники(можливість змінювати)Облік руху Єдина таблиця (журнал руху), в якій реєструються все Прихід та списання Можливість корекції в ручну При списанні медична сестра повинна вибрати: дату; пацієнта; препарат або матеріал; кількість; своє ПІБ. Система автоматично зменшує залишок. При приході старша медична сестра повинна мати можливість внести: Дата поставки; Препарат/матеріал; Залишкова кількість; Звідки прийшло; Термін придатностіАвтоматичний функціонал автоматичний розрахунок залишків; контроль мінімального запасу; контроль термінів придатності; попередження про низькі залишки; захист від списання більшої кількості, ніж є в наявності; випадаючі списки; перевірка правильності введення даних; умовне форматування.Звіти Потрібно реалізувати автоматичні звіти: поточні залишки; використання за період; використання по пацієнту; використання по працівнику; історія руху конкретного препарату.Бажано реалізація на Google Sheets; Заповнювати бази будемо самостійно. Потрібен шаблон для роботи. Скільки це коштує не знаю, тому почнемо зі 50$, а ви пропонуйте свої варіанти і бажано щоб був досвід.
Потрібно обрахувати статистику у медичному проекті (включно з кореляціями). Також, є запит на створення математичної моделі прогнозування розвитку патологій на основі наявних даних.