Сейчас совсем не понимаю с чего начать, нужно ли сначала спроектировать базу, а потом уже бекендом заняться, или все же вместе с беком все делать?
Из практики я не встречал в жизни такой задачи где-бы проектирование было с нуля и до конца.
Бизнес меняется. Постоянно появляются новые услуги. И под них растет база. Я-бы на твоём месте
не стал-бы упарываться вопросом именно проектирования базы. Я-бы доверился итеративному
процессу наподобие scrum-agile. Делаешь первую версию БД. Показываешь демо. Потом снова
итерации. Я надеюсь с командой alter table ты знаком? Ну и прекрасно. Значить в любую
табличку можешь внести изменения. Табличка это не железо-бетон. Если надо - пределай.
Если ты нашел в интернете нечто и хочешь под него что-то спроектировать в БД - тогда
экспертом по бизнесу являешся ты. И ты должен сам себе задать вопросы. Какие данные
будут лежать? Ключи и атрибуты.? Как они связаны.? Тут появляются связи один-ко-много или много-ко-много.
Это концептуальный уровнь. И на физическом уровне могут появится индексы. Партишены.
Если ты не знаешь какие сущности там будут лежать - то пойди от бизнес-кейсов. Например кейс.
Человек хочет сделать заказ. Или еще другой кейс. Человек пришел оплатить заказ.
Оплатил. Попользовался неделю. Потом ему что-то не подошло и он потребовал возврат.
Из кейсов сразу появляются сущности. Клиент. Заказ. Склад. Платеж. Фидбек. Flow товара по магазинам
и складам. И так далее.
Если начнешь делать - делай по минималке. Лучше сделать меньше но самодостаточно чем поначинать
тысячу сущностей и бросить их.
Простой
Средний