🪲 Типичные ошибки проектирования БД 🪲

При проектировании реляционных БД разработчики и аналитики допускают ошибки, которые могут привести к проблемам в ее использовании.

БД - это как фундамент в строительстве дома. Если вы не построите основание правильно, то в дальнейшем будут возникать проблемы, которые могут стать катастрофическими 🏡

Хочу поделиться с вами подборкой типичных ошибок проектирования БД и рекомендациями, как их избежать 🪲


Неправильное определение первичного ключа

🪲: При проектировании базы данных для онлайн-магазина, первичный ключ для таблицы "Товар" определили как "Имя".
Это может привести к ситуации, когда два товара с одинаковым названием нельзя будет создать, хотя такое может быть необходимо пользователю системы.

💊: Лучше определить первичный ключ как уникальный идентификатор, который не зависит от вводимых пользователем данных и не может быть случайно задублирован. Например, можно использовать автоинкрементирующееся поле "id". Также я рекомендую использовать UUID-ы (f81d4fae-7dec-11d0-a765-00a0c91e6bf6), но они занимают много памяти.


Использование ненужных таблиц

🪲: При проектировании базы данных для онлайн-магазина, разработчик создали отдельные таблицы для каждого типа товаров (продукты, хоз. товары, одежда и т.д).
При этом не обратили внимание, что все эти типы товаров имеют почти одинаковый набор свойств (полей).

💊: Лучше использовать одну таблицу "Товары" с полем "тип товара" и заполнять только нужные данные под каждый тип товара. Это позволит избежать дубли и сложные запросы к БД для работы со списком всех товаров в системе и поиском по ним (как минимум).


Хранение паролей в БД в чистом виде (без шифрования)

🪲: Не храните пароли в явном виде или в форме, которую можно легко прочитать.

💊: Если вы хотите, чтобы данные ваших пользователей были в безопасности, то вместо того, чтобы хранить пароли в явном виде, храните их в зашифрованном виде.


Продолжение скоро 👇

🪲Типичные ошибки проектирования БД - часть 2 🪲

Не описан алгоритм изменения схемы БД в процессе релиза (миграции данных)

🪲: При изменении базы данных было добавлено новое обязательное поле "Внешний идентификатор" в таблицу "Заказ", чтобы поддержать обработку заказов из внешних систем, типа (Amazon, Ozon и тд). Но от аналитика не было требования чем заполнить это поле для старых заказов, которые были созданы ранее. Что туда добавлять?

💊: Не забывайте про миграции.
Миграции БД - это процесс изменения схемы БД со временем, что может быть необходимо для поддержки новых функций или исправления ошибок.
Не забывайте добавлять требования к миграции при каждом изменении структуры базы данных, иначе вы можете создать баги, связанные с недостатком данных или с несовместимостью версий БД.


Поддержка регионов и часовых поясов

🪲: При разработке не учли, что пользователи системы живут в разных часовых поясах. Сведения о часовом поясе отсутствуют для значений времени в БД и им могут отображаться некорректные данные: например о времени отправления поезда в билетной системе.

💊: Не забывайте о часовых поясах и специальных форматах времени и даты.


Неверные типы данных в БД - выход за границы диапазона

🪲: При разработке налоговой системы ИНН решили хранить в целочисленном виде. В процессе работы системы пришла ошибка, что ИНН не сохраняется или почему-то выглядит не так, как ввел пользователь.

💊: Проверяйте ограничения по типам данных в СУБД (PostgreSQL, MySQL. и другие) и сопоставляйте с реальными значениями, которые могут ввести пользователи. Ищите границы и выбирайте соответствующие типы данных. Особенно часто проблемы встречаются с номерами телефонов, документов и подобными. Часто их вообще лучше хранить в виде строки.


Это распространенные ошибки начинающих специалистов, которые погружаются в техническое проектирование систем. Сохраняйте эти примеры. Они помогут избежать ошибки в вашей работе 🙌

🗓 Актуальные онлайн-встречи по проектированию БД и SQL 🗓

С этого года у нас изменения в работе с темами по проектированию БД и SQL.

Было много запросов на погружение в вопросы распределенных БД, индексов в таблицах и оптимизации, миграций между СУБД и другие. И это действительно те темы, которые нужно и важно разобрать.

Что теперь есть в GetAnalyst по БД и SQL:

🟨 Полная практическая программа “Проектирование БД и основы SQL”
Если вы начинаете разбираться с темой с нуля и вам нужно всё:
+ анализ требований и влияние на БД,
+ практика создания всех трех уровней моделей,
+ перенос их в реальную СУБД,
+ обучение SQL-запросам на реальной, разработанной вами БД,
+ миграция данных и развитие БД,
+ постановка задач на разработчиков,
++ углубленные темы в течение всего доступа к программе.


🟨 Онлайн-практикумы “Проектирование БД и SQL” - углубленное изучение
Если вы уже в теме и вам нужно больше практики, то теперь есть возможность регулярно посещать онлайн встречи для освоения углубленных тем по проектированию БД.

Прийти можно на 1, 2, 3 и сколько угодно встреч 🙂

🗓 Ближайшие онлайн-встречи:

13.02.2024 Проектирование БД с нуля: создание ER-диаграммы
14.03.2024 Разработка требований к миграциям БД
25.04.2024 Проектирование распределенных БД
06.06.2024 Оптимизация БД. Работа с индексами в БД
16.07.2024 Инструмент D-Beaver. Практика SQL-запросов

Полное и подробное расписание доступны здесь.


🎁 До 10 февраля 23:55 Мск активна скидка 20% на углубленные онлайн-практикумы (код: DB2024), а также добавили дополнительный практикум по БД и SQL в подарок!

Если уже выбрали интересные темы - планируйте заранее своё расписание 😉 В канале тоже будем напоминать о предстоящих практикумах.

🧐 Потребность улучшать БД в процессе работы с JSON и реальными потребностями клиентов API: собираем все части проектирования воедино.

...
"goalWeight": user.goal_weight.


А теперь самое интересное:
👉 "caloriesHistory": это история потребления калорий по дням - последние 5.

Если посмотреть на текущую модель БД то возникают сложности со сбором этих данных.

1. В таблице с историей потребления продуктов user_product_record нет группировки по дням.

2. Нет истории изменения веса по дням в БД, только текущий вес в user. История в текущей модели БД не хранится.

3. Сейчас нам нужно искать и вычислять калории за последние 5 дней по данным всей таблиц user_product_record + product. Это выглядит трудозатратно по ресурсам.

Учитывая, что потом будет нужна полная история, которую придется группировать по дням и сортировать, я бы ввела дополнительную таблицу user_daily_statistic, в которой бы группировала потребление продуктов внутри каждого дня + хранила бы текущий вес за день.

Обсудим новую таблицу user_daily_statistic:
- Если мы меняем что-то в таблице user_product_record, то информацию в таблице с ежедневной статистикой пользователя придётся пересчитывать. Это можно делать асинхронно, через очереди, после выполнения очередного запроса на изменение данных и возврата пользователю успешного ответа.
- Каждый день нужно будет создавать новую запись при обновлении веса или при добавлении любого продукта в историю. Для веса это делать в любом случае придётся.
Так что выглядит хорошим решением.

Вот так мы пересмотрели модель БД благодаря потребностям клиента и необходимости собрать это в структуру JSON. Хочется отметить, что такое возможно с любым форматом сообщений.

Системный аналитик видит системы насквозь и держит в голове много деталей, и это… Самое крутое в нашей работе! ❤️‍🔥


Для самостоятельной работы с JSON рекомендую: https://jsoneditoronline.com/. С помощью этого инструмента можно проверять правильность структуры.

А дальше предлагаю переходить к архитектуре систем, очередям и микросервисам 😎

Работа занимает большую часть нашей жизни. Чтобы чувствовать счастье, важно не просто "работать", а жить своим делом, получая от него удовольствие и вдохновение, и конечно же иметь цели в развитии, постоянно 🙌

Когда работа не просто обязанность, а любимое дело с достижимыми целями в нём, каждое утро начинается с предвкушения нового дня, полного задач, общения с коллегами, обмена опытом и возможностей проявить себя.

В такие моменты я знаю к чему иду, и этот путь наполнен смыслом, я понимаю свою личную цель и цель нашей команды.

Для меня системный анализ это не о том, чтобы просто "работать работу", а о том, чтобы стремиться к чему-то важному, развиваться и достигать новых вершин 🏔 Жизнь это не о том чтобы просто сущуствовать, я всегда ищу новые цели. Без них грустно и неинтересно.

Каждый проект — это не просто набор задач, это возможность изменить мир к лучшему, сделать что-то уникальное, узнать новое и получить опыт.

Наша работа скрывает в себе огромный потенциал для творчества и инноваций. Когда у нас есть цели, мы не просто выполняем задачи, мы создаем будущее.

Пусть каждый ваш день будет наполнен радостью от осознания того, что вы вносите свой вклад в развитие технологий и облегчаете жизнь многих людей. Просто задумайтесь, у вашего приложения уже есть или скоро будут пользователи, которым важно то, что вы делаете! ❤️‍🔥

Да, работа — это большая часть нашей жизни, но когда она приносит удовольствие, каждый день становится приключением, каждая задача — шагом к достижению мечты.

Желаю вам набираться сил, чтобы войти в новую неделю полными сил для новых достижений и изменений! ❤️‍🔥

📌 Новый проект GetTickets: распил монолита на микросервисы 📌

Проект "GetTickets" - платформа для онлайн-бронирования и покупки авиабилетов. Разрабатывался и запускался как стартап.

Функциональность платформы включает:

1. Поиск и сравнение билетов:
Пользователи могут искать подходящие авиабилеты с помощью интерфейса поиска, который позволяет фильтровать результаты по различным критериям, таким как цена, дата, время и авиакомпания.

2. Обработка транзакций:
Система обеспечивает процесс оплаты забронированных билетов банковской картой.

3. Уведомления и подтверждения:
Пользователи получают уведомления и подтверждения о бронировании на почту, телефон и push в мобильных приложениях.

4. Интеграция с различными авиакомпаниями и системами бронирования:
Платформа интегрируется с базами данных авиакомпаний и системами бронирования, чтобы предоставлять пользователям самые актуальные и полные данные о доступных билетах, позволяя найти площадку с наиболее выгодной ценой.

5. Персонализированные рекомендации и предложения:
Система использует алгоритмы машинного обучения для анализа предпочтений и истории покупок пользователей, чтобы предлагать им персонализированные рекомендации и специальные предложения.

6. Личный кабинет пользователя:
Пользователи могут просматривать историю покупок и поиска.

7. Администрирование:
Владельцы платформы могут получать доступ к аналитике по поиску, бронированиям и продажам за различные периоды, с применением различных критериев. Отчеты можно выгружать из систем в формате XLSX и PDF.


Для упрощения разработки был выбран архитектурный подход к проектированию - Монолит 🙌

На момент запуска целью было как можно скорее сделать продукт и начать привлекать пользователей, зарабатывая на комиссии с продажи билетов. Так что идея монолита на старте никого не смутила. Тестировали гипотезы быстро 👌 Но пришел этот самый момент....

#АрхитектураGA #GetTickets

🙈 Монолит и его проблемы 🙈

Монолитная архитектура - это подход к разработке программного обеспечения, при котором все компоненты приложения интегрированы в единый и цельный блок, называемый монолитом.

В такой архитектуре вся функциональность приложения, включая:
- интерфейс пользователя,
- базу данных,
- и бизнес-логику,
обычно реализуется внутри одного приложения и работает как единое целое.

Так что спустя 2 года после запуска GetTickets, когда платформа по продаже билетов набрала популярность и ожидать от 1000 запросов в минуту стало обычным делом, возникли проблемы:

1. Масштабируемость
1.1. Большое количество мощностей (облачных серверов) к аренде. Высокие затраты на инфраструктуру, так как на серверах можно устанавливать только копии монолита.
1.2. Высокое время ответа на отдельные запросы к системе, которые требуют обработки большого объема данных из БД (построение отчета по продажам).

2.Сложность поддержки и развертывания
2.1. Бывает, что приходится полностью останавливать работу системы в процессе обновлений. Это становится недопустимо. Важно работать 24/7, чтобы обеспечивать высокий уровень сервиса.
2.2 Тестирование перед релизом в продакшн превращается в каторгу для тестировщиков. Покрытия автотестами нет. Почти всё тестирование ведется вручную.

3. Сложность масштабирования команды разработчиков
Есть части системы, которые можно развивать и дорабатывать независимым командам разработки. Но они сильно связаны друг с другом, что делает параллельную работу над ними более сложной.

4. Единая точка отказа
Например, из-за отказа в работе основной и единственной БД, возникает остановка работы всей системы. Монолит - это одна большая точка отказа в системе.

5. Гибкость и инновации
Затрудняется внедрение новых технологий и подходов. Изменения в приложении могут оказаться затруднительными из-за жестких связей между его компонентами.

Это основные проблемы монолитной архитектуры 😔

В связи с тем, что проект GetTickets успешно развивается, пришло время привлечь в него специалистов, которые пересмотрят архитектуру и помогут ему масштабироваться и начать переезд на микросервисную архитектуру.

Welcome to the New Project! 🚀

#АрхитектураGA #GetTickets

🔺 Микросервисная архитектура (MSA) 🔺

Микросервисная архитектура представляет собой набор принципов разработки программного обеспечения, в котором сложное приложение разбивается на небольшие, независимые части, выполняющие конкретные функции. Эти части называют микросервисами.

Микросервисы могут существовать независимо друг от друга:

🔺1. Разрабатываться.

Разработчики могут создавать, тестировать, модифицировать и обновлять микросервисы отдельно друг от друга, без необходимости координировать эти действия с работой над другими частями системы.

Не надо думать о том, какие части будут задеты в результате изменений, как в монолите. Основное о чём думаем - сохранение способов взаимодействия с микросервисом при модификации.

Также одно из главных преимуществ - каждый микросервис можно разрабатывать на своём языке программирования, и выбирать наиболее подходящие инструменты и технологии для решения специфических задач.


🔺2. Развёртываться.

Развёртывание - процесс подготовки и настройки приложения для его работы в продуктивной (или тестовой) среде. Этот процесс включает в себя установку программного обеспечения на сервера или в облачную среду, настройку необходимых параметров, создание баз данных, настройку сетевых соединений и т.д., чтобы приложение было готово к использованию конечными пользователями.

Микросервисы могут быть развернуты независимо, что упрощает обновления и быстрое внедрение новых функций без влияния на остальные части системы.


🔺3. Масштабироваться.

Микросервисы открывают возможность дешевого горизонтального масштабирования систем. Когда можно добавлять и запускать дополнительные экземпляры приложений - микросервисов, работающие параллельно, для распределения нагрузки.

Вместо того, чтобы запускать еще один экземпляр большого приложения для распределения нагрузки, можно запустить только маленькую часть.


#АрхитектураGA

🤔 Деление монолита на микросервисы: с чего начать? 🤔

Если в проекте принято решение о переезда с монолита на микросервисы, то нужно построить план переезда. Какие есть варианты?


🔸 Вариант 1 - Переписываем с нуля

Самый простой план - разработать всё с нуля и запустить ту же самую систему на микросервисах. Но его обычно не выбирают.

1️⃣ Во-первых, в глазах заказчика (владельца продукта) это технический долг. И технический долг не должен тормозить развитие основной функциональности.

Представьте себе ситуацию:
Мы с архитектором приходим к владельцу продукта GetTickets и говорим, что ПО, которое мы разрабатывали в течение 2 лет, невозможно далее развивать и поддерживать, так как это монолит.
Нужно переписать весь код с нуля и повторить существующую систему, но по-другому - сделать микросервисы.
Чтобы это сделать надо ещё 2 года. И только после этого мы сможем взять новые задачи на новую функциональность 😁

Согласитесь, звучит так себе. Смена подхода в разработке архитектуры не должна блокировать развитие системы.

Техдолг техдолгом, а бизнес за новые фичи платит. Так что такую идею заказчику мы не продадим, и этот вариант рассматриваем только в случае, если вообще никуда не торопимся и у заказчика много денег.

2️⃣ Во-вторых, даже при таком раскладе через 2 года придётся задуматься о миграции (переносе) существующих данных из старой БД в новые БД микросервисов. Это достаточно сложная задача и её никак не избежать..

Кстати, именно перенос данных между БД одна из основных проблем в миграции с монолита на микросервисы.

3️⃣ И в-третьих, в течение двух лет разработки с нуля системы на микросервисах, оставить монолит без поддержки скорее всего не удастся. Поэтому команда будет одновременно сопровождать и разрабатывать две независимые системы.

Это может привести к тому, что если в монолите потребуются какие-то изменения в логике для исправления тех же ошибок или из-за законов (по разным причинам), то их могут упустить и не перенести в монолит по разным причинам.

#АрхитектураGA #GetTickets