📝 Изменения в БД в связи подключением внешней системы 📝

Прежде чем показать пример маппинга данных, я детальнее проработала часть модели БД для #ShipEasyGA.

Показала ER-диаграммы ДО -> ПОСЛЕ на прикрепленной картинке 🖼


Ключевые решения:

1. Создана таблица address для хранения структурированных адресов.

Каждый адрес (отправления и получения) привязывается к клиенту-отправителю.

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

Это сэкономит запросы во внешнюю систему.

1.1. Один адрес может быть использован для нескольких заказов одного клиента.

1.2. Если два разных клиента введут одинаковые адреса, то структурированный адрес будет сохранен в БД дважды, для двух разных клиентов.

Это поведение системы считаем нормальным. При желании можно усложнять и оптимизировать 🙂

2. В таблице order добавила ссылки для адресов отправления pickup_address_id (UUID) и получения delivery_address_id (UUID).

Не обязательные, Так как для старых заказов, которые были созданы до обновлений, не будет структурированных адресов.

3. В таблице order для старых заказов останутся поля с полными адресами pickup_address (varchar(512), NOT NULL) и delivery_address (varchar(512), NOT NULL), их нельзя удалять.

Это нужно, чтобы сохранить обратную совместимость в БД - то есть не “сломать” старые заказы, которые ориентируются на это поле.

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

* Для каждого заказа хранится копия данных об отправителе и получателе.

Если клиент, как пользователь системы, сменит фамилию, почту или телефон, то мы не будем "ломать" старые заказы и сохраним исторические данные.



Теперь, когда мы понимаем и структуру БД проекта, можно переходить к маппингу для нашей интеграционной задачи 🙌

#ИнтеграцииGA #БДGA