Легко впорався з попередніми завданнями? Ну що, тоді ловиш щось складніше. Давай закріпимо твої знання по PL-SQL і напишемо кілька процедур та тригерів. Готовий?
Створення процедур
Нижче наведені процедури, які рекомендується додати в базу даних твого маркетплейсу. Кожна процедура супроводжується поясненням, які задачі й бізнес-процеси вона вирішує і чому її варто реалізувати. Ці процедури охоплюють автоматизацію ключових операцій, підвищення зручності для користувачів, оптимізацію роботи вітрини, логістики, саппорту, маркетингу та аналітики.
1. Оформлення замовлення з автоматичним резервом товарів
Оформлення замовлення — ключова операція для будь-якого маркетплейсу. Процедура має не просто створювати запис замовлення і його позицій, а ще й резервувати товар на складі, списувати кількість, фіксувати статус, ініціювати платіж і запускати наступні процеси (нотифікації, логістику). Автоматизація цього сценарію знижує ризик помилок при ручному вводі, допомагає уникнути over-selling і забезпечує узгодженість запасів у реальному часі.
2. Автоматизація поповнення запасів товару
Щоб уникнути out-of-stock і втрат продажів, важливо вчасно поповнювати склади, якщо рівень залишків нижче порогу. Ця процедура перевіряє залишки по всіх товарах, порівнює їх з мінімальним рівнем і автоматично формує заявки на закупівлю або внутрішній ресаплай. Автоматизація скорочує час реакції і зменшує ручне навантаження на операційний відділ.
3. Масове оновлення статусів замовлень і нотифікація клієнтів
У каталозі часто треба масово переводити замовлення між статусами (наприклад, “paid” → “shipped” або “shipped” → “completed”) залежно від етапу обробки. Процедура оновлює статуси всіх відповідних замовлень, пише історію змін (для аудиту) і може ініціювати відправку нотифікацій клієнтам. Це автоматизує роботу back-office і мінімізує ручні помилки.
4. Масове застосування знижок/промокодів до товарів
Просування товарів або проведення акцій часто вимагає масового застосування промокодів і знижок до всієї категорії, бренду чи вибірки товарів. Процедура автоматично проставляє знижки, слідкує за обмеженнями (дата, ліміти), оновлює лічильники використань і запобігає дублям.
5. Автоматичне повернення коштів користувачу
Оформлення повернень і повернення коштів — критично важливий процес для довіри клієнтів. Процедура має перевіряти статус замовлення, валідність повернення, ініціювати повернення по платежу, оновлювати статуси, логувати транзакції і нотифікувати користувача. Відпрацювання всіх умов в одній транзакції знижує ризик помилок і зловживань.
6. Перерахунок середньої оцінки товару / продавця
При кожному новому відгуку, зміні чи видаленні, середній рейтинг товару або користувача має бути актуальним. Процедура оперативно перераховує і оновлює поле “avg_rating”/“review_count”, щоб прискорити фронтові запити і забезпечити узгодженість аналітики.
7. Автоматичне відключення (деактивація) товарів з нульовим залишком
Для коректної роботи вітрини маркетплейсу і щоб уникнути негативного досвіду користувачів, товари з нульовим залишком мають бути автоматично приховані (деактивовані). Процедура регулярно перевіряє склади і статус товарів, змінює статус на “inactive”, логує зміну і допомагає тримати каталог в актуальному стані без ручної перевірки.
8. Автоматичне призначення замовлення кур’єру і оновлення статусу доставки
У логістиці важливо швидко і прозоро призначати кур’єра на замовлення, змінювати статус доставки, фіксувати всі дії для відстеження. Процедура автоматизує ці кроки і дозволяє виключити ручну роботу менеджера.
9. Масова розсилка нотифікацій користувачам (тригер акції, нагадування)
Нотифікації про розпродажі, повернення, зміни статусів чи маркетингові активності мають розсилатися масово, з урахуванням умов (активні користувачі, давно не купували, кинули кошик тощо). Процедура дозволяє ініціювати розсилку push/email нотифікацій по заданому сегменту.
10. Архівація застарілих даних (наприклад, завершених замовлень чи неактивних товарів)
Щоб підтримувати продуктивність бази даних і зменшити об’єм “гарячих” таблиць, застарілі записи (старі замовлення, архівні товари, застарілі тікети саппорту) мають періодично переноситися або позначатися як “архів”. Процедура полегшує операції по видаленню чи переміщенню даних і мінімізує ручну роботу адміністраторів.
Створення тригерів
1. Логування зміни статусу замовлення
Ведення повної історії зміни статусів замовлень критично для аудиту, саппорту, аналітики і автоматичної розсилки нотифікацій користувачам про хід обробки їх замовлень. Тригер автоматично створює запис у "order".order_status_log при кожній зміні статусу замовлення, звільняючи розробників від необхідності вручну підтримувати історію змін на рівні застосунку.
2. Автоматична фіксація історії зміни ціни варіанта товару
Історія зміни цін на SKU потрібна для аналітики, відображення "старої ціни", відстеження акцій і автоматичних нотифікацій про знижки. Тригер фіксує кожну зміну поля price у таблиці product.variant в історію product.price_history. Це дозволяє зберігати повну динаміку цін без помилок і пропусків.
3. Синхронізація залишку по складу при зміні товарів на складі
Кожна зміна залишків на складі (наприклад, перерахунок, надходження, списання) має автоматично оновлювати поле last_updated для коректної аналітики і контролю за актуальністю даних. Також, такий тригер може запускати автоматичну перевірку на досягнення мінімального порогу і ініціювати автозамовлення.
4. Автоматична деактивація варіантів товару з нульовим залишком
Щоб уникнути ситуацій, коли клієнт купує відсутній товар, при досягненні нульового залишку на всіх складах для варіанта товару автоматично переводиться його поле is_active у FALSE. Це знижує кількість негативних відгуків і скасувань замовлень.
5. Логування спроб входу адміністратора (безпека)
Контроль входу адміністраторів — ключ до інформаційної безпеки. Всі спроби входу (успішні і невдалі) автоматично фіксуються в admin.login_attempt через BEFORE INSERT тригер. Це дозволяє вчасно виявляти атаки, зломи чи підозрілу активність.
6. Логування ключових змін у товарі та автоматичний запис історії
Всі важливі правки товару (зміна статусу, опису, назви) мають фіксуватися для аудиту дій співробітників, відновлення помилок і контролю зловживань. Тригер створює запис у product.status_history при зміні статусу і може бути розширений для інших ключових полів.
7. Автоматичне оновлення лічильника використань промокоду
Коректний облік кількості використань промокоду важливий для обмеження акцій і запобігання зловживанням. Тригер при кожній вставці в marketing.promo_usage збільшує лічильник used_count у таблиці marketing.promo_code, виключаючи розбіжності даних.
8. Оновлення балансу гаманця користувача при транзакціях
Для коректного відображення балансу бонусного/кешбек-гаманця користувача важливо, щоб кожна транзакція автоматично оновлювала підсумковий баланс у таблиці payment.wallet. Тригер на вставку нової транзакції зменшує ймовірність втрати чи спотворення даних при помилках застосунку.
9. Автоматичне встановлення "основної" адреси, email або телефону
Щоб уникнути ситуації, коли у користувача немає основного email/телефону/адреси (а це критично для відновлення доступу і комунікацій), тригер автоматично виставляє прапорець is_primary=TRUE для першого запису, якщо таких немає, і гарантує унікальність серед записів одного користувача.
10. Підрахунок середнього рейтингу товару при додаванні відгуку
Для швидкого відображення "середнього рейтингу" на картці товару і в пошуку, оновлювати це значення при кожному додаванні нового відгуку ефективніше, ніж постійно перераховувати агрегати запитами. Тригер підтримує кеш поля avg_rating і/або review_count у таблиці product.product.
11. Автоматичне встановлення дати публікації контенту
Для статей, сторінок чи інших публікацій при зміні статусу на "published" важливо коректно заповнювати поле published_at. Це забезпечує цілісність CMS: користувачі й адміністратори бачать точну дату виходу матеріалу, а фронт не вимагає додаткових ручних оновлень.
12. Логування всіх подій саппорту (зміни статусу тікета)
Повна історія звернень у саппорт і зміни їх статусів дозволяє оцінювати роботу служби підтримки, проводити аналітику і забезпечувати прозорість для користувачів. Тригер автоматично пише запис у support.ticket_status_log при зміні статусу тікета.
Примітка
Додавання цих тригерів суттєво підвищить надійність, прозорість і автоматизацію ключових бізнес-процесів маркетплейсу, зніме навантаження з прикладного коду і забезпечить цілісність даних на рівні самої бази. Вони відображають best practices проектування реляційних систем для великого e-commerce.
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ