È una cattiva pratica mantenere gli script DML (database schema scripts) e la manipolazione (DML) in diversi moduli

Question

È una cattiva pratica mantenere gli script DML (database schema scripts) e la manipolazione (DML) in diversi moduli

#1 da (1 voti)
#2 da (0 voti)

0

abbiamo una struttura di progetto come la seguente

Il modulo

"module-shared" dipende dal modulo "module-database" e alcuni altri moduli dipendono dal "module-shared" ma nessun altro modulo dipende da "module-database".

Tutti gli script SQL di DML sono memorizzati in "module-shared" ma DDL sono memorizzati in "module-database".

Il vantaggio di questo design è che

non è necessario rilasciare il database se le modifiche riguardano DML in "module-shared" e utilizzare i test di integrazione del database per accertarsi che siano ancora compatibili.

Lo svantaggio è che

questo crea alcune confusioni sulle versioni. Ad esempio è possibile avere "module-shared" 2.3.1 dipende da "module-database" 1.4.2 e alla fine dimenticheremo quale versione è compatibile con quale.

Domande:

Sarebbe un progetto migliore se avessimo un "module-database" che contenga sia DDL e DML (e tutte le altre operazioni di database se esistenti) sia che il modulo condiviso contenga tutto ciò che aveva tranne le operazioni del database?

Quali sono le tue esperienze nell'avere architetture multi-livello? usi sempre i moduli per separare i livelli? Hai esperienze in cui potresti avere DAO e servizi nello stesso modulo? Se lo fai, dove hai mantenuto gli script di schema DDL?

UPDATE: dimentica di menzionare che il DDL è sottoposto a versioning usando il sistema di controllo delle versioni degli script del database come flyway. In modo che tutte le modifiche DDL siano incrementali

Nota: ad es. un modulo potrebbe essere un modulo gradle, modulo Maven, ecc.

Nota: sto facendo del mio meglio per non essere prevenuto mentre faccio questa domanda. Quindi supponiamo che non abbia alcuna preferenza su nessuna delle due soluzioni. :)

sql database modules

posta user2001850 15.08.2014 - 23:34

fonte

2 risposte

Leggi altre domande sui tag sql database modules

Rappresenta la gerarchia di gruppi di numeri utilizzando l'ereditarietà del tipo Come concatenare i punti in un array

score 1 · Answer 1

In pratica, è difficile rilasciare una nuova versione del database. Mentre è bello avere un modulo con il DDL corrente, in molti casi è probabile che si stia modificando un database esistente. Lo terrei come un modulo separato.

La pratica per DDL che utilizzo è quella di generare uno script di aggiornamento (e downgrade) per ogni versione. Le modifiche che interrompono la versione corrente (eliminazioni e nuovi vincoli) vengono rimandate alla prossima versione. Vi sono altre considerazioni che consentono a due versioni di funzionare con una versione di database. Questi script includono la versione DML a cui si applicano nel loro nome.

La maggior parte del tuo DML dovrebbe funzionare su una vasta gamma di versioni. È possibile che tu abbia molte versioni DML senza modifiche DDL. In altri casi, potresti avere modifiche DDL per risolvere problemi di prestazioni che non hanno modifiche DML corrispondenti.

Se si codifica il codice nel proprio sistema di controllo della versione, non importa molto quale dei due moduli è stato modificato. Se non si esegue il check-in di un identificatore di versione, è corretto disporre di più tag sullo stesso codice.

EDIT: ho dato una rapida occhiata al flyway. Non penso che altera in modo significativo le raccomandazioni di cui sopra. Suggerirei di fare in modo che le dipendenze DML dell'applicazione permettessero di aumentare la versione DDL. Non vorrei rompere la mia applicazione aggiungendo un indice, una colonna o una tabella. (Le modifiche DDL possono includere DML per aggiornare i dati che dovrebbero trovarsi nello stesso repository del DDL.)

Considerare la deprecazione di colonne e tabelle che vengono eliminate. Dovresti essere in grado di utilizzare la ricerca di testo sul DML per identificare e rimuovere l'uso di oggetti deprecati. Questo dovrebbe consentire di testare alcune regressioni senza dover regredire il database.

score 0 · Answer 2

Ho familiarità con la memorizzazione di script DDL in repository che utilizzano un ORM (cioè rubino su rotaie).

Quando ho visto DML mescolato con il DML, i risultati che ho visto sono:

Puoi configurare un database da zero usandoli ma perdi la possibilità di tornare facilmente indietro per i singoli passaggi.