Quale componente è responsabile dell'aggiornamento dello schema del database?

0

Abbiamo ciò che può essere definito un'applicazione distribuita : un'app web in piena regola e un piccolo servizio REST. Entrambi devono essere dispiegabili separatamente. Entrambi accedono allo stesso schema di database (in realtà condividono solo due tabelle). La funzionalità comune è incapsulata in un artefatto comune (un file JAR qui, poiché è tutto Java). Fin qui, tutto bene.

Tuttavia, non sono sicuro di come gestire correttamente le modifiche allo schema. L'app Web utilizza Flyway per gli aggiornamenti dello schema, funziona come un fascino. Ma quale dovrebbe essere la procedura consigliata se una delle tabelle condivise ha bisogno di un aggiornamento? Di chi dovrebbe essere la responsabilità dell'aggiornamento? (Al momento è l'app web che esegue tutti gli aggiornamenti, forse è abbastanza buono, ma mi preoccupa.)

Ho pensato magari a cambiare anche l'architettura per avere un'applicazione o un servizio separati che ha sia l'app web che il servizio REST come client, ma ciò renderebbe le cose difficili, in realtà non rimuovere il problema.

    
posta MPi 08.08.2013 - 20:58
fonte

2 risposte

1

Il modo in cui Flyway si descrive, analizza sia lo stato esistente dello schema del database che tutte le "migrazioni" definite sul percorso della classe del programma in cui è utilizzato, e quindi fa automaticamente la cosa giusta. Pertanto, la risposta ovvia è "entrambi". Chiunque acceda per primo al database eseguirà la migrazione, quindi l'altro client non dovrà.

(Ovviamente esiste la possibilità che entrambi i client possano accedere al database in modo sovrapposto e "rubare" i rispettivi aggiornamenti, ma questo non è diverso dalla gestione di qualsiasi normale accesso in lettura / scrittura a una risorsa condivisa - se è necessario transazionale semantica, presumo che tu abbia già un modo per garantirlo.)

    
risposta data 08.08.2013 - 21:20
fonte
1

La tua webapp accede direttamente al DB? Questo è un po 'un anti-pattern proprio lì e non dovrebbe essere incoraggiato (principalmente per ragioni di sicurezza), quindi proverei a mettere il DB con l'altro servizio di livello app il più possibile in parte per cercare di incoraggiare la suddivisione dell'accesso ai DB dall'accesso client (o web server).

Altrimenti, basta creare un nuovo componente che sia "il DB" e gestisca tutte le modifiche dello schema indipendentemente da entrambe, quindi nessuna delle due cambierà le altre modifiche allo schema, ed entrambi dovranno abituarsi all'utilizzo di questo nuovo progetto come una dipendenza.

    
risposta data 08.08.2013 - 21:52
fonte

Leggi altre domande sui tag