Domanda

Buon pomeriggio,

Sono attualmente in fase molto precoce di un nuovo progetto scritto in .Net e l'utilizzo di Entity Framework per la persistenza dei dati / storage. Una delle caratteristiche richieste è la capacità di 'versione' certi tipi di modello. Per esempio. un modello è una 'requisito' che avrà n 'Versioni requisito', in pratica avere un modo di tornare indietro nella storia / ciclo di vita di quel particolare 'requisito' esempio. L'unica cosa che deve essere statica in tutte le revisioni è che è 'ID', tutto il resto è assolutamente modificabile per tutta la vita del requisito.

Ora la Q è, dovrei 'semplicemente' creare un 1: n relazione tra un requisito >> RequirementVersion? Altre caratteristiche hanno bisogno sono la possibilità di far rivivere completamente i vecchi Stati membri ad essere la corrente / ultima, ci deve essere la possibilità di avere la versione minore e maggiore (cambiamenti) e tale, e, ultimo ma non meno importante la possibilità di creare una 'linea di base' tutto una raccolta di requisiti con l'ultima versione di tornare a quel particolare Baseline in un momento successivo di tempo e la visualizzazione di tutte le RequirementVersions inclusi?

Questo ha a scalare fino a un paio di milioni di dischi Requisiti, ognuna delle quali ha un paio di migliaia di revisioni .. che è particolarmente per questo che chiedo .. l'aspetto di scala di un semplice 1:. N rapporto etc

qualcuno ha fatto qualcosa di simile e forse alcuni suggerimenti / pratiche migliori per quanto riguarda il controllo delle versioni etc / baselining etc?

Saluti e grazie, -Jörg

È stato utile?

Soluzione

Questo dipende dalla quantità di dati ogni requisito è.

Se Requisito ha grandi campi (ad esempio Requisito Descrizione).

  1. Probabilmente vorrebbe campi di versione, invece, non Requisito per sé. Purtroppo, sembra che non v'è alcun modo semplice per trattare con Entity Framework.
  2. Altro soluzione (abbiamo fatto questo per CMS) è quello di avere tabelle separate per il requisito e per il requisito descrizione. Quindi, come risultato si avrà RequirementVersions e RequirmentDescriptionVersions.

Se il requisito è abbastanza piccolo si può usare Requisito >> RequirementVersion. Nella maggior parte dei casi non sarà necessario crescono dati significativi, in particolare è possibile utilizzare la compressione SQL2008.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top