Il mio problema: ho intenzione di memorizzare un "progetto" in un database, in cui un progetto è composto da più elementi, ad es. documenti e ogni documento ha più elementi, ad es. paragrafi. I paragrafi possono fare riferimento incrociato ai paragrafi di altri documenti. Esistono molti team e ogni squadra può avere molti progetti. I membri del team modificano, aggiornano e perfezionano la posizione dei documenti con riferimenti incrociati fino a quando non sono felici, in cui il documento o il progetto viene quindi esaminato.
Quando viene emesso un documento, in seguito a una revisione, lo stato emesso viene mantenuto e qualsiasi modifica si verifica in un nuovo stato di staging / corrente.
Quando il progetto viene rilasciato, viene esaminato ed emesso nella sua interezza. Il set di documenti, il contenuto e i riferimenti incrociati vengono quindi mantenuti in tale numero, in modo che lo stato venga acquisito attraverso il progetto. Le eventuali modifiche successive vengono quindi applicate a una nuova versione di staging / corrente, lasciando disponibile il set emesso per la lettura così com'era nel punto di rilascio.
Ho preso in considerazione l'utilizzo di una tipica configurazione del database, ma temo che a) ci sarà rapidamente un'enorme crescita del numero di righe memorizzate; e b) che trovare l'insieme "attuale", o l'insieme per ogni progetto specifico sarebbe troppo complesso / fragile per un uso affidabile.
Come variante, memorizzerei i documenti in, ad es. JSON in una singola riga di documento interrompe la propagazione di paragrafi frammentati, senza incorrere in un notevole impatto sulle prestazioni?
Un pensiero alternativo è stato quello di assegnare un repository Git per progetto; ma poi preoccupati per l'archiviazione e le prestazioni e dover memorizzare "documenti" come ad es. Documenti JSON o simili per far funzionare il sistema in modo efficiente. Inoltre, finisci per gestire le aree di staging per sessione per ogni utente che ha effettuato l'accesso, il che sarebbe lento - giusto? Tranne GitHub, GitLab ecc consente un accesso rapido alla cronologia dei repo ...
Il database (o equivalente) sarà inizialmente accessibile tramite un'applicazione web. Alla fine, può essere servito ai client locali su un'API, o addirittura consentire ai client locali di lavorare con i repository git, se questo è il percorso seguito. Idealmente, sarebbero utilizzate tecnologie facilmente accessibili a PHP o NodeJS.
Domanda specifica: in che modo dovrebbero / devono essere archiviati e accessibili più artefatti correlati che richiedono il controllo della configurazione?
Questo è stato precedentemente chiesto su StackOverflow , ma mentre i punti premio saranno assegnati, è stato il posto sbagliato per questa domanda.