Buenas Prácticas para Entidades versionadas?

Question

Buenas tardes,

Actualmente estoy en la fase muy temprana de un nuevo proyecto escrito en / de almacenamiento y el uso de .Net Marco de la entidad para la persistencia de datos. Una de las características requeridas es la capacidad de 'versión' ciertos tipos de modelos. P.ej. un modelo es un 'requisito' que tendrá n 'Requisito Versiones', básicamente, tener un modo de volver atrás en la historia / ciclo de vida de ese caso particular 'Requisito'. Lo único que tiene que ser estática a través de todas las revisiones es que es 'ID', todo lo demás es absolutamente cambiante a lo largo de toda la vida del requisito.

Ahora, el Q es, debería 'simplemente' crear una relación 1: n entre un requisito >> RequirementVersion? Otras características necesitan son la posibilidad de revivir por completo los estados viejos para ser el actual / última, debe existir la posibilidad de tener la versión de menor y mayor (cambios) y tal, y por último pero no menos importante la capacidad de crear una 'línea de base' a través una colección de Requisitos con la última versión para volver a la línea de base en particular en un momento posterior y la visualización de todos los RequirementVersions incluidos?

Esto tiene que escalar hasta un par de millones de registros Requisito, cada uno de ellos con un par de miles de revisiones .. eso es todo eso pido .. el aspecto de escala de un simple 1:. N relación etc.

Alguien ha hecho algo similar y tal vez algunas sugerencias / etc mejores prácticas en relación con el control de versiones / línea de base, etc?

Saludos y gracias, -Jörg

Answer 1

Esto depende de la cantidad de datos cada requisito tiene.

Si Requisito tiene grandes campos (por ejemplo Requisito Descripción).

1. Es probable que le gustaría campos de versión en su lugar, no Requisito sí. Por desgracia, parece que no hay manera fácil de tratar Marco de la entidad.
2. Otro solución (hicimos esto para CMS) es tener tablas separadas para el requisito y para Requisito Descripción. Así como consecuencia que tendrá RequirementVersions y RequirmentDescriptionVersions.

Si el requisito es lo suficientemente pequeño que puede utilizar Requisito >> RequirementVersion. En la mayoría de los casos usted no tendrá que crecen datos significativos, especialmente se puede utilizar la compresión SQL2008.