Ho pensato e letto molto su questo argomento. Questo è un argomento ampio di controllo della configurazione e strategia di gestione delle modifiche. CMMI ha un dominio in questo argomento. Anche nelle aziende che hanno un accreditamento di CMMI 3-5, a volte non controllano la versione dei loro database.
È necessario rispondere a questa domanda tenendo presente i seguenti vincoli .
- Hai un custode e ogni DDL viene eseguito da questo custode.
- Altre persone hanno la capacità di eseguire istruzioni DDL.
- È necessario solo registrare le modifiche apportate, ma non è necessario confrontare grandi differenze.
- La progettazione del database viene eseguita tramite uno strumento esterno, quindi viene pubblicata nel database. Questo strumento esterno può essere anche script DDL nel controllo del codice sorgente. Ma il punto chiave è il controllo del codice sorgente, quindi la pubblicazione nel database.
- Non è necessario conoscere i cambiamenti istantanei ma di volta in volta: ovvero ogni ora, ogni giorno.
- Hai una struttura di server definita: sviluppo, test, produzione. E una buona strategia di test.
risposta 1
- se 1, 4,6 è vero, è possibile utilizzare un controllo sorgente esterno. Per esempio
- Embercadero ha uno strumento di gestione delle modifiche al database ( http://www.embarcadero.com/products/db-change-manager-xe ). Che ha la capacità di decodificare un database (Oracle) e metterlo nel loro controllo del codice sorgente. Quindi qualsiasi numero di sviluppatori, dba può raggiungere questo schema e apportare modifiche ad esso.
- Oracle SQL Designer è simile a questo approccio.
- Metterti a creare script di tabella per il controllo del codice sorgente (svn, mercurial ecc.) E mantenerli anche nella stessa cosa.
- http://www.liquibase.org è un approccio automatizzato di cui sopra.
- Ho scritto un generatore di codice che ha generato istruzioni DAL (Data Access Layer), DDL (Create Table). Abbiamo messo loro il controllo del codice sorgente e mantenuto lì. Penso che una soluzione dedicata come la liquibase possa funzionare meglio.
Questo approccio funziona bene se hai 6. Metti le istruzioni DDL, che è anche un codice, nel controllo del codice sorgente e lo mantieni. Nessuno cambierà i server di test e produzione senza la dovuta considerazione.
Gli svantaggi sono se si apportano modifiche alla produzione o ai server di prova per qualsiasi motivo, una correzione rapida dei bug, la modifica della chiave primaria ecc. È necessario eseguire il rollback di tali modifiche anche al server di sviluppo. Dal momento che in realtà il server di sviluppo è la tua VERITÀ TERRA. Non diversamente.
Questo è un approccio molto orientato agli sviluppatori. Ma quando si sviluppa per la prima volta un nuovo modulo funziona abbastanza bene.
Risposta 2
- se 1 e 6 sono veri:
Un approccio simile alla risposta 1 è mantenere un server di sviluppo. Tutti lo usano lo cambiano. Di quando arriva il momento di aggiornare. Si utilizza uno strumento di confronto dei database. Prendi questi come script, mettilo sotto il controllo del codice sorgente.
- Red Gate Schema Compare supports Oracle
- Embercadero has similar tool
- https://github.com/carbonfive/db-migration
- http://www.sumsoftsolutions.com/svco/ (I have not used this product but I believe it belongs to this category.)
- Rails Active Migration (http://www.oracle.com/technetwork/articles/kern-rails-migrations-100756.html)
La differenza tra la risposta 1 e la risposta 2 è che nella risposta 1 raccogli le istruzioni DDL per l'intero database e le memorizzi. Nella risposta 2 è necessario memorizzare ogni versione di modifica.
- Inizio
- V1
- V2
- V3
- ...
Se si inserisce una colonna in una tabella e successivamente si decide di rimuoverla. Gli script lo mostreranno in answer2 mentre in answer1 vedrai solo l'ultima versione. E devi confrontare V2 e V1 per vedere le differenze. Personalmente mi piace rispondere meglio 1 poiché posso facilmente confrontare Start e V3, V1 e V3. In answer2, devo cercare tutte le modifiche. Anche nella risposta 2 la sceneggiatura nel controllo del codice sorgente tende ad essere una sceneggiatura complessa e big bang. Informazioni difficili da trovare.
Risposta 3
Se 3 è vero. Si noti che in questa situazione non si ha il vincolo 6, ovvero: non si dispone di server di sviluppo, test e prodotto. Solo server di produzione. È possibile utilizzare i trigger DDL per registrare le modifiche apportate. Questo è principalmente usato per scoraggiare le persone dall'abusare delle loro sovvenzioni DDL. In caso di problemi, è possibile trovare un responsabile. Affinché ciò funzioni, ogni persona dovrebbe connettersi con il proprio account utente e l'account Applicazione non dovrebbe avere alcuna sovvenzione DDL. Poiché ogni sviluppatore conosce l'account dell'applicazione e può utilizzarlo.
Risposta 4
Se si dispone di 3 e 5. Si noti che in questa situazione non si ha il vincolo 6, ovvero: non si dispone di server di sviluppo, test e prodotto. Solo server di produzione. Invece di innescare per memorizzare le modifiche. Si utilizza uno strumento esterno per trovare le modifiche e archiviare gli script DDL nel controllo del codice sorgente.
Se questo strumento ha la capacità di registrare chi ha apportato le modifiche, sarebbe utile. Si noti che in questa soluzione si perde ulteriore DDL che viene eseguito a intervalli.