Я создаю веб-приложение для пабов и пивоварен, чтобы управлять их списком кранов и отображать его на разных носителях (телеэкраны, печать, веб-сайт и т. Д. c).
Фон
На этапе PO C я использовал очень простую систему Beer -> Tap <- Pub. Пользователи просто выбирают пиво, которое им предлагают в определенном пабе, вводят их цену и т.д. c и готово.
Они могут просто добавлять или изменять пиво (и пивоваренные заводы), и эта информация отображается непосредственно для их кранов. Например, название и lo go пива и пивоваренного завода.
Конечно, это не работает, когда многие пользователи начинают делиться этим набором основных данных пива. Вы не хотите, чтобы пользователь A изменил имя пивоварни, и это повлияет на все панели мониторинга ТВ пользователя в режиме реального времени.
Соображения
В настоящее время я изучаю лучшие варианты:
Вариант A - сохранить информацию о пиве и пивоварне в кране
Таким образом, есть еще один набор основных данных, но пользователям не нужно его редактировать. Если они хотят что-то изменить, они могут перезаписать значение по умолчанию в указанном кране c для определенного паба c (либо мы копируем все данные во время создания, либо сохраняем только перезаписанные атрибуты)
+ easy to implement, easy to reason about
- not very flexible (if they want to change the same beer across multiple locations or the brewery name across multiple beers)
Схема БД выглядела бы примерно так:
BREWERY
- id
- name
- etc
BEER
- id
- brewery_id (FK)
- name
- etc
PUB
- id
- name
- etc
TAP
- id
- beer_id (FK)
- brewery_id (FK)
- price
- etc
- beer_name
- brewery_name
- etc
В этом случае пользователи не смогут изменять существующие виды пива / пивоваренные заводы, а только перезаписывать вещи на уровне крана.
Вариант B - создавать теневые копии каждого пива и пивоваренного завода для каждого пользователя
Таким образом, все еще есть набор основных данных для всех пользователей, но как только они выбирают что-то из этого, чтобы добавить его к своим нажмите список, система создаст собственную версию (теневую копию) этого. Затем они могут изменить его в соответствии с содержанием своего сердца и не повлиять на копии других пользователей или его исходную версию.
+ cleaner design
+ allows updating your own copy of a beer/brewery and change affects all *your* data
- more effort
Схема БД будет выглядеть примерно так:
BREWERY
- id
- source_brewery_id (FK) - would be NULL for source brewery (master data)
- user_id (FK) - would be NULL for source brewery (master data)
- name
- etc
BEER
- id
- source_beer_id (FK)
- user_id (FK)
- name
- etc
PUB
- id
- name
- etc
TAP
- id
- beer_id (FK)
- brewery_id (FK)
- price
- etc
Таким образом пользователи могут редактировать элементы, которые им принадлежат.
Одна сложная часть может заключаться в дедупликации при просмотре и поиске пива и пивоваренных заводов, но я думаю, что, используя концепцию source_id, я смогу сделать это в SQL довольно просто.
Резюме
Я склоняюсь к вариант B , но мне было интересно, если я что-то упустил или это право способ создания общего каталога.
Кстати, я строю это с помощью Ruby на Rails, если это поможет кому-либо сделать еще более информированные предложения.
Спасибо за попытку помочь мне с это!