Cómo manejar los cambios en los datos duplicados en NoSQL

Question

Estamos evaluando NoSQL para un próximo proyecto. Tiendo a pensar las cosas de una manera RDBMS y estoy teniendo problemas para conceptualizar la falta de normalización.

Entiendo que la duplicación de datos no se considera incorrecta en NoSQL. Lo que tengo problemas para comprender es corregir los cambios en los datos para evitar anomalías.

Explicación de la pregunta por ejemplo:

está organizando una serie de torneos de póquer. Tienes jugadores, ubicaciones y eventos de torneos. Según tengo entendido, un evento de torneo puede contener una ubicación y una colección de jugadores. No es necesario que tenga todos los datos del jugador , pero si desea obtener los nombres y las direcciones de todos los que van al próximo torneo, esa información debe estar en la colección del torneo.

Alguien se casó y se mudó, cambiando su apellido y la dirección . ¿La aplicación necesita actualizar la colección de jugadores y la colección del torneo? ¿O es incorrecto mi modelo de colecciones? ¿Cómo hacen los desarrolladores de "mantener un registro" de dónde se duplica la información?

Answer 1

El modelo que veo siendo usado un poco últimamente es tener una inmutable colección "maestro" de datos (en su caso, la lista de jugadores, la lista de torneos con los jugadores en cada torneo modelado " relacionalmente ", donde el registro del torneo tiene una lista de identificadores de jugadores), y una lista desnormalizada (en su caso, una lista de torneos con los datos de jugadores completamente poblados) que solo se actualiza ejecutando un proceso periódico sobre el" maestro ". "datos".

De esta manera, la aplicación solo necesita actualizar los datos maestros, y el proceso de actualización periódico finalmente reconstruirá el resultado desnormalizado.

Answer 2

Una cosa para hacer es tener un "sistema de registro" o maestro para cada tipo de datos que tenga. No es necesario que haya una sola fuente para todos los datos, pero cada uno debe tener uno.

Otra medida a tomar es hacer que los datos sean versionados (conservar los cambios históricos) para que los datos desnormalizados puedan ser inmutables: en su ejemplo, los datos del jugador para un torneo que ocurrió en el pasado son correctos para ese momento. Si un jugador se mudó a una nueva dirección desde entonces todavía puede obtenerlo yendo al "sistema de registro" del jugador para obtener la dirección actual, pero el registro del torneo refleja su dirección en el momento, etc.