Как спроектировать БД для обслуживания запросов пользователей?
Существует некоторая сущность Конфигурация с набором параметров, которой управляет пользователь. Для простоты, конфигурация сервисов внутри VPS, в которой указывается количество единиц CPU, Memory, Storage для каждого сервиса. И в нашей системе храним эти конфигурации.
При помощи запроса пользователь отправляет заявку на размещение ресурсов в VPS. Третья сторона проверяет возможно ли это и если да, то выполняет адаптацию под новую конфигурацию или же получаем отказ. Если отказ, значит мы не можем сменить конфигурацию. С другой стороны, пользователю нужно дать возможность скорректировать свою конфигурацию и мы не можем просто выкинуть ее.
1. Есть ли какие-то шаблоны проектирования для обслуживания таких запросов?
2. Нужно ли хранить в БД оба состояния: текущее и желаемое?
3. Создавать новую сущность по типу транзакции? Или другие мысли?
Буду рад примерам, а также ссылкам на статьи, шаблоны проектирования, которые смогут помочь для решения проблемы.
Все зависит от того как вы будете использовать эти данные. Не зная этого, можно лишь гадать.
В общем случае, конфигурация и заявки на её изменение сущности разные и хранить их следует отдельно. Но если ваша конфигурация на самом деле просто заапрувленная заявка, то смысла нет. Смотрите как будете формировать select, исходя из них формируйте наиболее эффективную структуру.
Vitsliputsli,
можно ввести дополнительную сущность ЗаявкаНаКонфигурацию, но это похоже на перебор, т.к., по сути, храним то же самое.
Пока есть мысль просто добавить к Конфигурация (CPU, Memory, Storage, ...) дополнительные поля (CreatedAt:datetime, AppliedAt:datetime, IsCurrent:bool) и производить выборки WHERE IsCurrent=1, храня множество конфигураций в той же таблице. Или даже обойтись без IsCurrent, оставив только AppliedAt (nullable).
Ромзес Панагиотис, логически, сущности эти разные, пусть они и схожи в данный момент. Технически, зачем вам IsCurrent, по которому ещё и индекс будете строить, не проще ли сразу разделить?
Простой
Средний
Простой