Telegram-бот з PostgreSQL: як спроєктувати БД, щоб не переробляти
Схема бази, накидана за десять хвилин на старті, визначає, скільки болю буде через рік. Кілька рішень варто ухвалити свідомо одразу.
Базовий набір таблиць
Користувачі з ідентифікатором Telegram, датою першого контакту й мовою. Події або дії - журнал того, що робив користувач. Основні сутності вашої предметної області: замовлення, записи, заявки.
Ідентифікатор Telegram варто зберігати як окреме поле, а не використовувати як первинний ключ - так простіше згодом додати інші канали.
Типові помилки
Зберігати все в одному полі у вигляді неструктурованого об'єкта. Спочатку зручно, потім неможливо ні знайти, ні порахувати.
Не зберігати історію змін статусів. Коли клієнт запитає, коли саме змінився стан його замовлення, відповісти буде нічим.
Що врахувати наперед
М'яке видалення замість фізичного: користувач може заблокувати бота й повернутись через пів року, а історія має зберегтись.
Часові позначки з часовим поясом на всіх записах. Без цього аналітика за днями почне брехати при переході на інший час.
Коротко
Структуровані поля замість звалища, історія статусів і м'яке видалення. Три рішення, які найчастіше доводиться впроваджувати заднім числом.