Как обрабатывать изменения в дублированных данных в NoSQL

Мы оцениваем NoSQL для предстоящего проекта. Я склонен думать о вещах в режиме РСУБД, и у меня возникают проблемы с концепцией отсутствия нормализации.

Я понимаю, что дублирование данных не считается ошибочным в NoSQL. У меня возникли проблемы с пониманием - это исправление изменений данных для предотвращения аномалий.

Объяснение вопроса по примеру:

Вы организуете серию турниров по покеру. У вас есть игроки, местоположениях и турнирах. Насколько я понимаю, турнир событие может содержать местоположение и коллекцию игроков. Оно делает не нужно иметь все данные игрока, но если вы хотите получить имена и домашние адреса всех, кто собирается на следующий турнир, эту информацию должен быть в коллекции турниров.

Кто-то женился и переехал, изменив фамилию и адрес. Нужно ли приложению обновлять коллекцию игроков и сборник турниров? Или неправильная модель коллекций? Как разработчики "отслеживают", где информация дублируется?

Ответ 1

Модель, которая, как я вижу, используется в последнее время совсем немного, состоит в том, чтобы иметь неизменную "основную" коллекцию данных (в вашем случае список игроков, список турниров с игроками в каждом турнире, моделируемый "реляционно", где в турнирной записи есть список идентификаторов проигрывателя) и денормализованный список (в вашем случае - список турниров с полностью заполненными данными игрока), который обновляется только периодически, запустив периодический процесс над "ведущими" данными.

Таким образом, приложению требуется только обновить основные данные, а процесс периодического обновления в конечном итоге восстановит денормализованный результат.

Ответ 2

Одно дело - иметь одну "систему записи" или мастер для каждого типа данных, которые у вас есть. Не обязательно иметь единственный источник для всех данных, но каждый должен иметь один.

Еще одна мера, которую нужно предпринять, состоит в том, чтобы сделать данные версиями (сохранить исторические изменения), чтобы денормализованные данные могли быть неизменными - в вашем примере данные игрока для турнира, которые произошли в прошлом, являются правильными для этого времени. Если игрок перешел на новый адрес, с тех пор вы все равно можете получить это, перейдя в "систему записи" игрока, чтобы получить текущий адрес, но запись турнира отражает его/ее адрес в то время и т.д.