Modellazione di database, sviluppo software e controllo della versione

Naviga le tue risposte
3

Ecco il framework

Abbiamo un database SQL in cui vive il nostro modello di database. Dall'altro lato, c'è un mucchio di codice che usa e riempie quel database.

Ecco cosa vogliamo

  • Vogliamo inserire sia il modello del database che il codice del software sotto il controllo della versione per poter andare avanti e indietro all'interno versioni differenti.
  • Dal momento che il nostro modello di database diventa sgradevole, vogliamo uno strumento grafico che ci assista con la modellazione logica del database e che crei i nostri script SQL DLL

Questo post riguarda la domanda su come soddisfare entrambi questi requisiti allo stesso tempo. Personalmente, tendo a saltare il requisito per lo strumento grafico e semplicemente a scrivere il nostro modello di database dei fori all'interno degli script SQL e aggiungerli a git. Tuttavia, è molto difficile mantenere il modello mentre il modello diventa più complicato e (facile) i cambiamenti logici possono essere enormi cambiamenti di codice.

Ecco la nostra "soluzione" corrente

Il nostro codice software è sotto controllo di versione con git. La nostra logica il modello di database viene invece mantenuto con PowerDesigner, che porta (con alcune limitazioni) il proprio controllo di versione. Alla fine della giornata, generiamo le nostre istruzioni DDL SQL dal modello logico.

Ecco i nostri problemi con la situazione attuale

Anche se il codice è sotto controllo di versione, lo sviluppo del codice è in qualche modo scollegato dallo sviluppo del modello di database. Una modifica di un oggetto nel modello di database logico (come la modifica del nome di una colonna) è non visibile in git. Anche se eseguiamo il checkout di una determinata versione in git, è necessaria un'ulteriore mappatura che ci indichi quale versione di modello di database logico che devo usare. Inoltre, filiali in git non può essere mappato a rami all'interno di PowerDesigner, il che rende caotico lo sviluppo.

Ecco alcune idee di unificazione che abbiamo trovato

Exporting the logical model from PowerDesigner as (XML) and put it under version control in git.

Qui, so quale versione del codice si riferisce a quale versione di PowerDesigner, dal momento che posso semplicemente importare il codice XML. comunque, il git diffs sull'XML sono inutili e la fusione con diversi modelli logici in git è senza speranza. Quindi, ci deve essere una fusione all'interno di git e all'interno di PowerDesigner. Inoltre, devo esportare il modello in un XML per ogni commit che comporta modifiche sul modello del database (che sono purtroppo abbastanza frequenti) e quali rallenta molto il processo di sviluppo. Inoltre, i bug sono difficili da traccia, perché devo cercare il mio codice con git e il mio modello logico all'interno di PowerDesigner separatamente.

Put the database scripts generated by PowerDesigner under version control.

Qui, le differenze di git hanno un significato e posso mettere in relazione i cambiamenti del codice proprio per le modifiche del modello logico. Ma non posso andare ripristinare una versione in PowerDesigner solo con gli script del database generati. Quindi, di nuovo, ho bisogno di esportare l'XML del modello e ho gli stessi problemi di quelli precedenti.

Ecco le mie domande

  • Come si collega il mondo del codice, il mondo del database logico modellazione e il mondo del controllo della versione?

  • È fattibile chiudere i database complessi su uno strumento grafico e codificare tutto con gli script SQL?

  • Quali sono i buoni modelli di lavoro per mantenere questi due repository e coordinare gli sviluppatori?

posta Tobias Windisch 10.02.2017 - 20:42
fonte

3 risposte

4

Dovresti esaminare le migrazioni dei database, è una strategia comune utilizzata sui database.

Fondamentalmente si associa il codice base con una versione dello schema del database. Per mantenere aggiornato lo schema, mantieni una catena di script di modifica incrementale ciascuno con un numero di versione sequenziale.

Questo ha il vantaggio aggiunto che è possibile utilizzare gli script per aggiornare un database esistente con i dati utente in esso contenuti (gli script di creazione SQL non funzionano lì).

Includete gli script di migrazione "delta" nel vostro sistema di controllo versione, insieme al vostro codice base. Quando qualcuno ottiene la versione più recente, otterrà anche tutti gli script di cui hanno bisogno per eseguire il loro database corrente.

A volte puoi ancora usare i tuoi strumenti visivi se riesci in qualche modo a estrarre script diff, ci sono strumenti software che possono aiutarti con questo.

vedi ad esempio: link

    
risposta data 11.02.2017 - 12:48
fonte
1

Conserverei sicuramente l'SQL utilizzato per creare i dati senza che sia necessario lo strumento per ottenere l'XML nel repository del codice. In questo modo tutto ciò che è necessario per costruire il sistema è in un unico posto. Questo SQL deve contenere la struttura del database più eventuali dati che devono essere presenti affinché l'applicazione funzioni effettivamente.

Ho visto pochissimi modelli di database logici. Ho costruito diagrammi ER dal database attuale (reverse engineer). Questo di solito viene fatto mentre sto imparando quali sono le relazioni all'interno del database, e nessuno ha visto un ER del database in anni. Solitamente scopre sia l'uso incoerente che semplicemente un cattivo design.

Facci sapere che cosa finalmente fai.

    
risposta data 11.02.2017 - 16:22
fonte
0

Se il tuo database è ragionevolmente piccolo (es. meno di un megabyte o qualche decina di megabyte) potresti prendere in considerazione il dumping in formato SQL (ad es. con sqlite3 yourdb.sqlite .dump > yourdb.sql se usi un SQLite database yourdb.sqlite ) e controllo di versione che yourdb.sql file di dump testuale.

Se vuoi solo la versione del database schema (senza contenuto della tabella), puoi scaricare solo quello (in formato SQL) e controllare la versione dell'output (ad es. di sqlite3 yourdb.sqlite .fullschema se si utilizza un < a href="http://sqlite.org/"> SQLite database). Quindi, è molto probabile che si adatti a dimensioni ragionevoli.

Potresti anche automatizzarlo (dumping a pre-commit, caricamento post-fusione), usando git hooks . (Guarda il mio progetto di github old-melt-monitor per un esempio).

In alternativa, se il tuo codice ha bisogno solo di alcune tabelle da creare (ma non ci sono dati reali), potresti prendere in considerazione alcune routine di inizializzazione (come il mio create_tables_for_dump_mom routine ) facendo alcune richieste SQL di CREATE TABLE IF NOT EXISTS (e altre simili CREATE " se non esiste "richieste di indici, eccetera...) . Quindi lo schema del database (o modello di database) si trova nel codice (come stringhe letterali). Potresti aggiungere a ciò le poche tabelle e il loro contenuto, mantenendo informazioni quasi non mutevoli (ad esempio messaggi di errore).

    
risposta data 11.02.2017 - 14:56
fonte

Leggi altre domande sui tag

È una cattiva idea utilizzare ProgramData per consentire agli utenti non amministratori di aggiornare il nostro programma? C # ha un modo di usare un'istanza dichiarata multi-interfaccia, o qualcosa di simile quando si applica l'ISP?