Un unico database, più dipendenze del sistema

1

Considera un ambiente in cui disponiamo di un unico database principale, con molti sistemi separati che utilizzano questo unico database.

Questo porta a tutti questi sistemi hanno una dipendenza comune, che alla fine introduce l'accoppiamento tra di loro.

Ciò significa che non possiamo sempre evolvere i sistemi indipendentemente l'uno dall'altro. Le modifiche strutturali al database (anche se sono intese solo per un particolare sistema) richiedono un test completo di TUTTI i sistemi e potrebbero richiedere che altri sistemi vengano "riparati" e successivamente rilasciati.

Questo è particolarmente complicato quando vuoi avere team separati che lavorano su diversi progetti.

Che cosa è un buon "modello" per aiutare ad evitare tale accoppiamento?

Immagino che un database dovrebbe essere affidato esclusivamente ad un sistema. Se altri sistemi richiedono dati per qualsiasi motivo, dovrebbero richiedere tali servizi da un tipo di servizio API.

Un inconveniente di questo approccio che viene in mente è la prestazione: il routing dei dati tra sistemi ad alta velocità attraverso le chiamate di servizio è molto più lento rispetto a una connessione di database.

    
posta davenewza 21.08.2014 - 07:26
fonte

1 risposta

5

Alcuni suggerimenti raccolti negli anni ...

  • Il database è il repository centrale dei tuoi dati. dovrebbe essere condiviso da molte applicazioni.
  • I database sono relativamente benigni quando si tratta di nuovi progetti che richiedono un'estensione. L'aggiunta di colonne o tabelle aggiuntive non dovrebbe alterare i prodotti esistenti. Se i campi si spostano, allora sì le tue applicazioni esistenti sono interessate, perché la tua azienda ha bisogno di essere cambiata.
  • Configura un "livello" attorno al tuo database che esegue operazioni commerciali anziché CRUD (ad esempio makePayment (), placeOrder (); deliverTo ()). Se lavori con Java, il mio strumento preferito è MyBatis, ma ci sono molte altre opzioni (Hibernate, TopLink, Spring JDBC per nominarne alcune)
  • Non utilizzare mai " seleziona * da someTable .. . Assegna sempre in modo esplicito le colonne di cui hai bisogno. Quindi, quando qualcuno aggiunge un blob da 5 GB alle tue righe, non sarai colpito dal sovraccarico di leggendo un enorme blob.

Non c'è un proiettile d'argento. Un'API che nasconde i dettagli raramente aiuta. In particolare, SOAP è pignolo: il minimo cambiamento nell'API significa che tutti i clienti richiedono attenzione. REST è un po 'più amichevole.

Buona fortuna!

    
risposta data 21.08.2014 - 08:51
fonte