Часть 2. Рефакторинг SrokOk: Как я «приручил» базу данных
Продолжаю историю с категориями в SrokOk. Настало время навести порядок.
Что изменилось в архитектуре:
• Нормализация: создал отдельную таблицу CategoryEntity. Теперь у каждой категории свой уникальный ID.
• Foreign Key: в таблице продуктов заменил String на categoryId: Long. Теперь база сама следит, чтобы продукт не ссылался на пустоту.
• Безопасность данных: добавил логику «Без категории». Если категория удаляется, продукты не исчезают, а автоматически перемещаются в системный раздел.
Главный вызов: когда я поменял тип поля в базе, «посыпался» весь проект — мапперы, DAO, UI. Пришлось внедрять JOIN в SQL-запросы, чтобы подтягивать имя категории для экрана.
Рефакторинг — это больно, но это единственный способ превратить пет-проект в профессиональное приложение.
А вы сталкивались с тем, что простое изменение в базе тянуло за собой переписывание полпроекта? 👇
· 14.04
Странная постановка вопроса. Рефакторинг вообще та еще штука. Надо заранее прорабатывать, что хотите, какого типа ключи. Если проектируете с помощью LLM и агентов, то ключи надо UUID - гарантия уникальности. Но при проектировании уже на уровне приложения, упорно ставится либо int, либо long. Просто UUID гораздо лучше при конкурентных запросах. Так что тестировать и еще раз тестировать. Иногда фиг поймешь, где ошибка, а там какой-то оператор вдруг взял и требует ключи типа int, а у вас UUID и ошибка.
ответить
коммент удалён
· 15.04
Спасибо за развёрнутый комментарий! Про UUID возьму на заметку, особенно если буду делать синхронизацию. А про тестирование — железно, сам на этом обжигался 😄
ответить
ответ удалён