Architettura - Query DB esterne di terze parti

1

Il nostro team ha il compito di interrogare un database esterno di terze parti per ottenere informazioni. Non possediamo il database, quindi potrebbe cambiare senza preavviso e le nostre query smetterebbero di funzionare. Attualmente archiviamo le query DB in file SQL nel nostro progetto C # come risorse incorporate e le eseguiamo come SqlCommands.

Funziona quando funziona, ma ci sono soluzioni migliori là fuori? È stato suggerito di archiviare l'SQL nel nostro DB, quindi se dovessimo mai cambiarlo, è possibile farlo senza un rilascio, ma non sembra neanche la soluzione migliore.

    
posta Martin 04.01.2018 - 20:25
fonte

3 risposte

4

La robustezza di un sistema di applicazioni di database può essere aumentata quando l'applicazione fa affidamento solo sul schema del database, ma non (o almeno non troppo) sul suo contenuto.

SQL deve essere trattato esattamente come qualsiasi altro codice sorgente - deve essere scritto da uno sviluppatore, ha bisogno di alcuni test (test idealmente automatici), deve essere versionato, deve essere mantenuto, e quando si rompe deve essere eseguito il debug.

Ora, quando le query SQL sono strettamente collegate al codice delle applicazioni, quindi sono progettate per funzionare con una versione specifica dell'applicazione, non importa se tali query sono memorizzate nel database o direttamente nell'applicazione - sono effettivamente parte dell'applicazione in entrambe le situazioni. E quando è necessario distribuire una nuova versione di queste query - se sono archiviate nel database, in un file di configurazione o altrove - è effettivamente come se si distribuisse una nuova versione del software: l'intero sistema (applicazioni + SQL) ha bisogno di un nuovo numero di versione, il sistema nel suo complesso deve essere testato, mantenuto e talvolta sottoposto a debug.

Se, per qualche strana ragione, nel tuo ambiente hai un controllo migliore sulla distribuzione di nuove query SQL come contenuto del database piuttosto che sull'implementazione di nuove versioni della tua applicazione, potresti preferire utilizzarlo a tuo vantaggio. Ma questa non è in realtà una "soluzione tecnica intelligente" o una "best practice" - che è semplicemente una backdoor per l'implementazione di nuovo codice senza una corretta gestione delle versioni per qualcosa che merita il quest'ultimo. E devi assicurarti che al 100% nessun utente, utente esperto o amministratore inizi a trafficare con quelle query. Non necessariamente intenzionale, ma cosa succede se un amministratore db ripristina un backup del database dalla scorsa settimana, con le vecchie query, mentre la versione dell'applicazione è quella di questa settimana, ed entrambe non corrispondono?

Se ciò si verifica nel modo peggiore, potresti ricevere dal tuo cliente una strana chiamata di assistenza sul perché l'applicazione non funziona come previsto, ma il numero di versione dell'applicazione non ti dirà nulla delle SQL che il cliente ha nel suo database e quale potrebbe essere la causa dei problemi.

Quindi la mia raccomandazione qui è: non "esternalizzare" parti dell'applicazione che sono strettamente accoppiate ad esso in un altro posto, solo perché quel "altro posto" consente un diverso ciclo di rilascio. Un lavoro migliore per rendere meno dolorosa la distribuzione di nuove versioni della vostra applicazione (inclusi aggiornamenti, hot fix, ecc.). Avrai sicuramente un sacco di altri requisiti o problemi per i quali una rapida implementazione dell'applicazione in meno di, mi permetta di indovinare, 24 ore al giorno, potrebbe essere vantaggioso. Se hai risolto questo problema, non sarà più necessario creare soluzioni alternative come la memorizzazione di SQL al di fuori dell'applicazione.

EDIT: alcune note sul suggerimento di utilizzare un servizio web come "interfaccia tra l'applicazione e il DB di terze parti": questo ti dà un controllo migliore sulla gestione del rilascio, poiché consente di gestire i rilasci dell'applicazione , il db e il servizio in modo indipendente. Il servizio quindi non si assumerà solo le responsabilità sulle query SQL, ma anche sul modo in cui il sistema si connette al db di terze parti. Se la terza parte potrebbe modificare l'intero sistema DB o le politiche di connessione, è possibile risolverlo senza ridistribuire l'applicazione (ma ridistribuendo il servizio, ovviamente).

Tuttavia, questo non è gratuito: aggiungi un ulteriore livello di complessità al tuo sistema. Inoltre, l'intera comunicazione tra l'applicazione dell'utente e il DB di terze parti non viene più eseguita direttamente tra l'applicazione e quel DB, ma tramite il servizio Web, che potrebbe diventare un collo di bottiglia. Quindi è necessario verificare attentamente se questo passaggio da una semplice applicazione a due livelli a un'applicazione a 3 livelli più complessa vale davvero la pena.

    
risposta data 04.01.2018 - 21:10
fonte
4

Suggerirei di creare un servizio Web o altre API astratte per ciò che si sta ottenendo da questo database progettato in base alle proprie condizioni. Ad esempio, se hanno una cosa chiamata Entità che rappresenta una Persona nella tua progettazione, la tua API la chiama Persona.

Una volta che hai questo servizio o servizi sul posto, li tratti come la fonte dei dati. Il DB di terze parti dovrebbe essere invisibile al resto della tua applicazione. Quindi, quando la terza parte modifica qualcosa, si modifica il servizio in modo che continui a funzionare come era.

Come menzionato nei commenti su altre risposte, ci sono alcune cose che vorrete valutare, ad esempio se avete una leva per far implementare un servizio stabile a una terza parte. Questo è un miglioramento rispetto alla tua situazione ma non controllerai quell'interfaccia. Se costruisci la tua astrazione di servizio, puoi sostituire più facilmente la parte di terze parti. Se questo è probabile è un calcolo che la tua squadra deve fare. È anche irrilevante se non si riesce a spingere il venditore a farlo.

E ai punti che il dottore Brown fa, sono d'accordo in generale. Le prestazioni possono diventare un problema, ma se tutto ciò che stai facendo è tirare i dati, il ridimensionamento dovrebbe essere semplice. Ci sono anche opportunità che derivano dall'implementazione della facciata per utilizzare la memorizzazione nella cache e / o il pre-recupero per migliorare le prestazioni.

Ulteriori letture:

risposta data 04.01.2018 - 20:38
fonte
1

La risposta di JimmyJames di avere la terza parte esporre un'astrazione attorno ai dati relazionali grezzi (ad esempio un'API RESTful) è decisamente l'opzione che dovresti sostenere per il tuo team e spingere con forza.

Tuttavia, se deve interrogare un database di parti 3d perché la direzione ha deciso che accadrà così, il minimo che si dovrebbe chiedere è che la terza parte fornisca viste dedicate, stored procedure, tabella- funzioni di valore e / o una combinazione di tali meccanismi di database per questo scopo.

Ci sono molti motivi:

  • Maintainability. Come hai già detto, le loro attuali strutture di dati persistenti (tabelle) possono cambiare in qualsiasi momento. Se così facendo li costringe a cambiare l'implementazione ma non la forma di una vista che si interroga, sposta l'onere su dove dovrebbe essere e non interromperà mai l'applicazione in modi imprevisti.

  • Sicurezza. Se lo prendono seriamente, ti connetteranno al loro DB con un utente / ruolo che ha solo le autorizzazioni di lettura per quelle viste particolari.

  • Prestazioni. Se mantengono una vista corretta e, se possibile, aggiungono indici ad essa, sarete in grado di filtrare e ordinare i dati sfruttando efficacemente i poteri di RDBMS.

Ancora una volta, sottolineo che la soluzione preferita rimane il trasferimento dei dati in un altro modo, http (s) è la scelta più ovvia qui.

    
risposta data 04.01.2018 - 22:34
fonte

Leggi altre domande sui tag