Исходная ситуация: конечный заказчик — производитель пищевых продуктов, использовал готовую зарубежную систему SAP для управления производством и складом. Компания решила перейти на собственное решение и собрала команду для его разработки.
Запрос заказчика: Нужно было создать систему, которая автоматизирует распределение продуктов на складе и поможет организовать своевременное и достаточное пополнение складов с учетом запланированного производства и сроков годности товара. Для расчета потребности в товарах использовали вычисления, сделанные нейросетью.
Задачи: у команды было несколько задач на проекте.
Задача №1
Команда разработчиков получила доступ к таблицам Excel, в которых содержатся типы самых разных данных. Данные делились на несколько уровней: прогноз, расчетные данные, фактические данные. Нужно было спроектировать структуру базы данных так, чтобы с ними можно было работать, а также продумать, как хранить и копировать эти данные, оптимизировать скорость и эффективность ее работы.
Команда разработчиков под руководством тимлида спроектировала схему базы данных, а затем создала модели для всех типов данных, указанных в спецификации. Модель в Django — это класс, на основе которого создается таблица в базе данных.
На проекте использовалось около десяти разных типов данных и таблиц, в которых содержатся записи номенклатуры и продукции. Количество записей доходило до миллионов. Разработчики применили метод партиционирования, то есть разделили большие таблицы на много маленьких, чтобы повысить производительность запросов.
В процессе работы параллельно создавали модели Django, Vue-модели, API и так далее. Команда использовала сериализаторы, которые позволяют преобразовывать сложные данные в удобный для хранения формат, и десериализаторы. С их помощью входные данные из таблиц Excel преобразовывались в данные для хранения в базе и наоборот.
Задача № 2
Другая задача — валидация (проверка) данных. На проекте была сложная многоуровневая нейросистема валидации.
Команда разработала интерфейс для взаимодействия с API, который позволил загружать исходные данные в подходящем виде для планирования. Помимо загрузки использовался механизм автоматического получения исходных данных из других компонентов системы, например, от модуля ИИ.
Также был создан API, который позволял отображать загруженные данные и результаты вычислений в виде графиков. Например, таким образом можно составлять графики поставки товаров, процент загрузки автомобиля, заполняемость складов и так далее.
Сложности:
Ранее наш специалист не писал хранимые процедуры в базе данных — блок кода или запросов, которые хранятся в базе и позволяют копировать данные из одной таблицы в другую. В процессе работы Константин изучил эту технологию и теперь может писать хранимые процедуры не только на SQL, но и на PostgreSQL, с применением специального процедурного языка.