Ничего не поделаешь, люди не предсказуемы, когда дело оплаты касается. А если брать Ваш вопрос, то ответ на него лежит в юридической плоскости. Все зависит от того в какой момент право собственности переходит согласно договору. Но в случае продажи дизайна другому покупателю деньги видимо первому надо вернуть. Полностью или часть - зависит от условий договора. Вообще говоря такие вещи договором регулируются.
Это все взаимозависимые вещи, они параллельно развиваются в процессе проектирования. Изменения в одном элементе приводят к изменениям в других элементах. Тем не менее я считаю базовым элементом схему данных, т к на нее опираются API и интерфейс.
Это Вы извините, что ответ дал не линейный. Напишите потом по результату правильно я сказал или нет).
Если линейно отвечать, то Вам надо сделать проект системы. Я бы начал с ролей и доступного функционала, потом модель данных и скетчи интерфейса запилил. Дальше уже вопрос выбора методологии реализации проекта и технологического стека.
Там миллион всяких тонкостей в зависимости от точки изменений. Я думаю для начала надо чтобы ноды заработали параллельно, а потом модель обновления под каждое изменение.
Рад что смог помочь, пожалуйста.
Точно сказать что почитать не могу, я уже слишком давно эту тему вкуривал, но ищите по теме "Моделирование реляционных баз данных"
Вот так в MySQL WorkBench выглядит в части видов поддержки. В терминах моей схемы:
Post - Сущность для описания
PostSupport - Поддержка для сущности
Support - Список видов поддержки.
Остальное по аналогии. Поля какие нужны не ключевые, надо по предметной области смотреть.
На моей схеме я сущностью назвал, то к чему Ваш вывод опций на картинке. Их же много как я понимаю. Для каждой надо указать какие есть опции по валюнтам, клиентам и суппортам из существующих вариантов. В целом это все сущности в терминах моделирования данных и при нормализации для каждой сущности одна таблица. На моей схеме есть 7 таблиц, 3 отношения один ко многим и 3 внешних ключа. По хорошему надо добавить уникальный составной индекс по полю ключ сущности, ключ опции для контроля непротиворечивости данных.
Есть еще вариант с таблицами существующих опций по каждой категории и подчиненой таблицей доступных опций. Он кстати более правильный с точки зрения моделирования и упрощает вывод на фронте..... Короче первый ответ дал не подумав. Сорри) Но функционально задачу решают обе модели.
