Sono parte di un team che costruisce un nuovo sistema di gestione dei contenuti per il nostro sito pubblico. Sto cercando di trovare il modo più semplice e migliore per creare un meccanismo di Revision Control. Il modello a oggetti è piuttosto semplice. Abbiamo una classe "BaseArticle" astratta che include proprietà per dati indipendenti dalla versione/meta come "Titolo" & "CreatedBy". Un numero di classi eredita da questo come "DocumentArticle" che ha la proprietà "URL" che sarà un percorso di un file. "WebArticle" eredita anche da "BaseArticle" e include la proprietà "FurtherInfo" e una collezione di oggetti "Tabs", che includono "Body" che manterrà l'HTML da visualizzare (gli oggetti Tab non derivano da nulla). "NewsArticle" e "JobArticle" ereditano da "WebArticle". Abbiamo altre classi derivate, ma queste forniscono abbastanza esempi.Come progettare un database con cronologia revisioni?
Ci sono due approvi alla persistenza per Revision Control. Io chiamo questi "Approach1" e "Approach2". Ho usato SQL Server per fare uno schema di base di ciascuno: 
Con Approach1, il piano sarebbe per le nuove versioni degli Articoli da mantenere tramite un aggiornamento del database. Un trigger verrebbe impostato per gli aggiornamenti e inserirà i vecchi dati anche nella tabella xxx_Versions. Penso che un trigger debba essere configurato su ogni tavolo. Questo approccio ha il vantaggio che l'unica versione "principale" di ciascun articolo è contenuta nelle tabelle principali, con le vecchie versioni eliminate. Ciò semplifica la copia delle versioni head degli articoli dal database di sviluppo/staging a quello Live.
Con Approach2, il piano sarebbe per le nuove versioni degli articoli da inserire nel database. La versione principale degli articoli sarebbe identificata attraverso le viste. Questo sembra avere il vantaggio di un minor numero di tabelle e meno codice (ad esempio non trigger).
Si noti che con entrambi gli approcci, il piano sarebbe quello di chiamare una procedura memorizzata Upsert per la tabella mappata all'oggetto pertinente (dobbiamo ricordare di gestire il caso di un nuovo articolo da aggiungere). Questa procedura memorizzata verso l'alto lo chiamerebbe per la classe da cui deriva, ad es. upsert_NewsArticle chiamerebbe upsert_WebArticle ecc.
Stiamo usando SQL Server 2005, anche se penso che questa domanda sia indipendente dal sapore del database. Ho effettuato alcune ricerche approfondite su Internet e ho trovato riferimenti a entrambi gli approcci. Ma non ho trovato nulla che paragona i due e mostri l'uno o l'altro per essere migliore. Penso che con tutti i libri di database nel mondo, questa scelta di approcci debba essere sorta prima.
La mia domanda è: quale di questi approcci è il migliore e perché?
Hai mai pensato di acquistare un CMS e di personalizzarlo? Sono ingannevolmente difficili e richiedono molto tempo per costruire bene. Può finire per essere piuttosto costoso. –
Certamente diventa piuttosto complicato quando passi dalla visione all'implementazione. Ma penso che abbiamo le capacità per costruire ciò di cui abbiamo bisogno ... Voglio solo essere sicuro di fare il backend nel miglior modo possibile. Inoltre, se avessimo scelto una soluzione standard, mi sarebbe rimasta la domanda teorica su quale approccio adottare :-(BTW, guarda i commenti che ho fatto al post di Blender per i link a pagine interessanti. – daniel