Riutilizzo delle procedure memorizzate SQL tra le applicazioni

Question

Sono curioso di conoscere l'approccio delle persone all'utilizzo delle procedure memorizzate in un database a cui accedono molte applicazioni.Nello specifico, tendi a mantenere diversi set di procedure memorizzate per ciascuna applicazione, provi a utilizzare un set condiviso o fai un mix?

Da un lato, il riutilizzo degli SP consente meno modifiche in caso di modifica del modello o qualcosa di simile e, idealmente, meno manutenzione.D'altro canto, se le esigenze delle applicazioni divergono, le modifiche apportate a una procedura memorizzata per un'applicazione possono danneggiare altre applicazioni.Dovrei notare che nel nostro ambiente ogni applicazione ha il proprio team di sviluppo, con scarsa comunicazione tra di loro.Tuttavia, il team dati ha una comunicazione migliore e ha principalmente il compito di scrivere la procedura memorizzata.

Grazie!

Answer 1

Tutto dipende dalla tua strategia di astrazione.Le procedure memorizzate vengono trattate come un punto di astrazione distinto o vengono trattate semplicemente come un'altra parte dell'applicazione che le richiama.

La risposta ti dirà come gestirli.Se sono un'astrazione discreta, possono essere condivise, come se avessi bisogno di nuove funzionalità, aggiungerai nuove procedure.Se fanno parte dell'app che li chiama, non devono essere condivisi.

Answer 2

Le procedure archiviate devono essere create in base ai dati che si intende restituire e non all'applicazione che effettua la richiesta.Se si dispone di una procedura memorizzata GetAllItems, dovrebbe restituire tutti gli elementi nel database.Se una delle applicazioni desidera ottenere tutti gli elementi per categoria, creare GetAllItemsByCategory.Non vi è alcun motivo per cui le regole aziendali di una procedura memorizzata cambino in base all'applicazione che richiede i dati.

Answer 3

La mia esperienza è stata che avere SP condivisi da più applicazioni è causa di problemi.In effetti, direi che avere un database a cui accedono direttamente più di un'applicazione non è la migliore architettura a lungo termine.

Il modello che consiglio e che ho implementato è che solo un'applicazione dovrebbe "possedere" ciascun database e fornire API (servizi, ecc.) affinché altre applicazioni possano accedere e modificare i dati.

Ciò presenta diversi vantaggi:

1. L'applicazione proprietaria può applicare qualsiasi logica aziendale, registrazione, ecc.per assicurarsi che rimanga stabile
2. Se lo schema viene modificato, tutte le interfacce sono note e possono essere testate per assicurarsi che le applicazioni esterne funzionino ancora

Answer 4

Le procedure archiviate dovrebbero esporre regole aziendali che non cambiano a seconda dell'applicazione che le utilizza.Ciò consente di archiviare e aggiornare le regole una volta anziché in ogni luogo in cui vengono utilizzate, il che è un incubo.

Answer 5

Pensare in questo modo:le tue procedure memorizzate riguardano i dati che si trovano sotto di esse e non dovrebbero realmente conoscere le applicazioni sopra di esse.È possibile che un'applicazione debba leggere o aggiornare i dati in un modo diverso da un'altra, e quindi una utilizzerebbe SP che l'altra non farebbe.

Se fosse la mia applicazione/database/ecc. e le modifiche a un SP per migliorare un'applicazione ne rompessero un'altra, considererei questa prova di un problema di progettazione più profondo.

Answer 6

Credo che l'ultima parte della tua domanda abbia risposto da sola.

Con una comunicazione già scarsa, la condivisione delle procedure tra i team di sviluppo non farebbe altro che aumentare i potenziali punti di fallimento e potrebbe causare difficoltà a entrambi i team.

Se faccio parte dello stesso team e lavoro su più progetti, risparmieremo tempo e condivideremo le procedure, ma in genere ho scoperto che una piccola duplicazione (alcune procedure qua e là) aiuta a evitare modifiche/duplicazioni catastrofiche necessarie in seguito, quando le applicazioni iniziano a divergere.

LordScarlet sottolinea anche un elemento chiave: se è generico senza condivisione di logica aziendale, non dovrebbe costituire un problema.

Answer 7

Ogni volta che avevamo procedure memorizzate comuni a più applicazioni, creavamo un database solo per quelle procedure (e viste e tabelle, ecc.).Quel database (che abbiamo chiamato "base") avrebbe quindi uno sviluppatore (o un team) responsabile (manutenzione e test).

Se un team diverso avesse bisogno di una nuova funzionalità, potrebbe scriverla e lo sviluppatore di base la implementerebbe nel DB di base o suggerirebbe un modo più semplice.

Answer 8

Cerchiamo di utilizzare un unico processo memorizzato condiviso ove possibile, ma ci siamo imbattuti anche nella situazione che descrivi.Lo abbiamo gestito aggiungendo un prefisso dell'applicazione ai processi memorizzati (ApplicationName_StoredProcName).

Spesso questi processi memorizzati chiamano il processo memorizzato centralizzato o "master", ma questo metodo lascia spazio a modifiche specifiche dell'app lungo il percorso.

Answer 9

Non penso che la condivisione di Sprocs tra più applicazioni abbia senso.

Vedo l'opportunità di condividere un database in applicazioni correlate, ma presumibilmente tali applicazioni sono separate in gran parte perché trattano i dati in modo molto diverso l'una dall'altra.

L'utilizzo della stessa architettura potrebbe funzionare in tutte le applicazioni, ma immagina di provare a utilizzare lo stesso livello di logica aziendale in più applicazioni."Ma aspetta!" Dici: "È sciocco ...se utilizzo lo stesso BLL, perché dovrei avere un'app separata?Fanno la stessa cosa!"

QED.

Answer 10

Idealmente utilizzare un processo e non più versioni.Se hai bisogno di versioni per cliente, esamina l'idea di 1 db per cliente anziché 1 db per tutti i clienti.Ciò consente anche alcune interessanti fasi di staging di db su server diversi (assegnare quelli di utilizzo più grande/più pesante a server più grandi mentre quelli più piccoli possono condividere l'hardware)

Answer 11

Se cerchi la possibilità di condividere il codice SQL, prova a creare una libreria di funzioni astratte.In questo modo potresti riutilizzare parte del codice che esegue operazioni generiche e mantenere la logica aziendale separata per ciascuna applicazione.Lo stesso potrebbe essere fatto con le visualizzazioni: potrebbero essere mantenute abbastanza generiche e utili per molte applicazioni.

Probabilmente scoprirai che non ci sono molti usi per le procedure memorizzate comuni man mano che procedi.

Detto questo, una volta abbiamo implementato un progetto che funzionava con un database legacy progettato molto male.Abbiamo implementato una serie di procedure memorizzate che semplificano il recupero delle informazioni.Quando altre persone di altri team hanno voluto utilizzare le stesse informazioni, abbiamo rifattorizzato le nostre procedure memorizzate per renderle più generiche, aggiunto un ulteriore livello di commenti e documentazione e consentito ad altre persone di utilizzare le nostre procedure.Quella soluzione ha funzionato piuttosto bene.

Answer 12

Molte procedure memorizzate sono indipendenti dall'applicazione, ma alcune potrebbero dipendere dall'applicazione.Ad esempio, le procedure memorizzate CRUD (Create, Select, Update, Delete) possono passare attraverso le applicazioni.In particolare puoi inserire la logica di controllo (a volte eseguita nei trigger ma c'è un limite alla complessità che puoi ottenere nei trigger).Se nel tuo negozio di software disponi di un tipo di architettura standard, il livello intermedio potrebbe richiedere una procedura memorizzata per creare/selezionare/aggiornare/eliminare dal database indipendentemente dall'applicazione, nel qual caso la procedura è condivisa.

Allo stesso tempo potrebbero esserci alcuni modi utili per visualizzare i dati, ad esempio GetProductsSoldBySalesPerson, ecc.che sarà anche indipendente dall'applicazione.Potresti avere un sacco di tabelle di ricerca per alcuni campi come dipartimento, indirizzo, ecc.quindi potrebbe esserci una procedura per restituire una vista della tabella con tutti i campi di testo.Cioè invece di SalesPersonID, SaleDate, CustomerID, DepartmentID, CustomerAddressID la procedura restituisce una vista SalesPersonName, SaleDate, CustomerName, DepartmentName, CustomerAddress.Questo potrebbe essere utilizzato anche in tutte le applicazioni.Un sistema di relazioni con i clienti richiederebbe Nome cliente/Indirizzo/Altri attributi così come un sistema di fatturazione.Quindi qualcosa che effettui tutte le unioni e ottenga tutte le informazioni sui clienti in un'unica query verrebbe probabilmente utilizzato in tutte le applicazioni.È vero che la creazione di modi per visualizzare i dati è il dominio di una vista, ma spesso le persone utilizzano procedure memorizzate per farlo.

Quindi, in pratica, quando elimini dalla tua tabella devi eliminare da altre 3 o 4 tabelle per garantire l'integrità dei dati.la logica è troppo complicata per un trigger?Quindi una procedura memorizzata utilizzata da tutte le applicazioni per eseguire le eliminazioni potrebbe essere importante.Lo stesso vale per le cose che devono essere fatte durante la creazione.Se sono presenti join comuni che vengono sempre eseguiti, potrebbe avere senso avere una procedura memorizzata per eseguire tutti i join.Quindi, se in seguito cambi le tabelle, potresti mantenere la stessa procedura e cambiare semplicemente la logica lì.

Answer 13

Il concetto di condivisione di uno schema di dati tra più applicazioni è difficile.Invariabilmente, il tuo schema viene compromesso per motivi di prestazioni:denormalizzazione, quali indici creare.Se riesci a dimezzare la dimensione di una riga, puoi raddoppiare il numero di righe per pagina e, probabilmente, dimezzare il tempo necessario per scansionare la tabella.Tuttavia, se includi solo funzionalità "comuni" nella tabella principale e mantieni i dati solo di interesse per applicazioni specifiche su tabelle diverse (ma correlate), devi unirti ovunque per tornare all'idea della "tabella singola".

Un numero maggiore di indici per supportare diverse applicazioni comporterà un tempo sempre maggiore per inserire, aggiornare ed eliminare i dati da ciascuna tabella.

Anche il server del database diventerà spesso un collo di bottiglia, perché i database non possono essere bilanciati nel carico.Puoi partizionare i tuoi dati su più server, ma anche questo diventa molto complicato.

Infine, il grado di coordinamento richiesto è tipicamente enorme, senza dubbio a causa di scontri tra diversi dipartimenti su quali requisiti abbiano la priorità, e i nuovi sviluppi rimarranno impantanati.

In generale, il modello del "silo di dati isolato per applicazione" funziona meglio.Quasi tutto ciò che facciamo - io lavoro per una software house a contratto - si basa sull'importazione ed esportazione di dati da altri sistemi, con i database propri delle nostre applicazioni.

Potrebbe essere più semplice nei sistemi di data warehouse/supporto decisionale;Generalmente lavoro su sistemi OLTP in cui le prestazioni delle transazioni sono fondamentali.