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

Question

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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