È stupido scrivere un programma di elaborazione batch di grandi dimensioni interamente in PL/SQL?

Question

Sto iniziando a lavorare su un programma che è forse più naturale descritto come un insieme di calcoli su tabelle di database, e saranno eseguiti una volta al mese.Tutti ingresso è in tabelle di database Oracle, e tutto l'output sarà per Oracle database e tabelle.Il programma dovrebbe rimanere gestibile per molti anni a venire.

Sembra straight-forward per implementare questo come una serie di stored procedure, ogni esecuzione di una sensibile trasformazione, per esempio, la distribuzione dei costi tra i dipartimenti secondo alcune regole di business.Posso quindi scrivere unit test per verificare se l'uscita di ogni trasformazione è come mi aspettavo.

È una cattiva idea di fare tutto questo in PL/SQL?Ti piacerebbe fare pesanti batch calcoli in un oggetto tipico linguaggio di programmazione, come C#?Non è più espressivo di utilizzare un database centric linguaggio di programmazione come PL/SQL?

Answer 1

Normalmente io dico di mettere poco in PL/SQL, come possibile, è in genere molto meno gestibile - in uno dei miei ultimi lavori ho davvero visto come disordinato e difficile da lavorare con si potrebbe ottenere.

Tuttavia, poiché è l'elaborazione in batch - e dal momento che l'ingresso e l'uscita sono sia il DB - fa buon senso di mettere la logica in PL/SQL - per minimizzare le "parti mobili".Tuttavia, se si trattasse di logica di business o componenti utilizzati da altre parti del sistema, direi di non farlo..

Answer 2

Si descrivono i seguenti requisiti

a) Deve essere in grado di implementare l'Elaborazione in Batch b) Risultato deve essere facile da gestire

La Mia Risposta:

1. PL/SQL è stato progettato per ottenere ciò che si descrive.E ' anche importante notare che ci sono incrementi di efficienza in PL/SQL che non sono disponibili in altri strumenti.Una stored procedure lingua di mettere il trattamento successivo alla data - che è dove l'elaborazione in batch deve sedersi.
2. È abbastanza facile da scrivere poco codice gestibile in qualsiasi lingua.

Detto quanto sopra, i vostri attuazione dipenderà dall'abilità disponibili, una corretta progettazione e l'adesione a una buona qualità dei processi.

Per essere efficace l'implementazione deve elaborare i dati in batch ( selezionare in lotti e di inserimento/aggiornamento in batch ).Il pericolo con un OO approccio è che è facile essere guidati verso un design che elabora i dati riga per riga.Questo tipo di approccio contiene un inutile sovraccarico, e sarà molto meno efficienti di un design che elabora i dati in batch di file.

È possibile utilizzare entrambi gli approcci con successo.

Mathew Butler

Answer 3

Qualcosa per gli altri commentatori di nota - la questione è di circa PL/SQL, non su SQL.Alcune delle risposte sono stati ovviamente su SQL, non PL/SQL.PL/SQL è un database funzionale della lingua, ed è molto maturi.Ci sono alcune lacune, ma per il tipo di cosa che il manifesto vuole fare, è molto buona.

Answer 4

No, non è necessariamente una cattiva idea.Se la soluzione sembra semplice per voi e vi permette di testare e verificare ogni processo, la sua suona come potrebbe essere una buona idea.OO piattaforme può essere (anche se non deve) essere un male per grandi insiemi di dati, come la creazione di oggetti e overhead può uccidere prestazioni.

Oracle progettato PL/SQL con problemi come il tuo in mente, se non c'è sufficiente aziendale, conoscenza dei database PL/SQL e questo mi sembra una soluzione ragionevole.Mantenere batch di grandi dimensioni set in mente, come ogni chiamata da PL/SQL per l'effettivo motore SQL è un cambio di contesto, in modo singolo record dei processi che devono essere raggruppati insieme, ove possibile, per migliorare le prestazioni.

Answer 5

Basta assicurarsi di che, in qualche modo, log di quello che succede mentre si sta lavorando.Altrimenti avrete una scatola nera, e se si ottiene bloccato da qualche parte per ore, vi starete chiedendo se interrompere o lasciarlo lavorare "un po ' di piu'.

Answer 6

PL/SQL è un linguaggio maturo che ben si integra con SQL.Con ogni versione di Oracle diventa sempre più potente.Anche a partire da Oracle 11, PL/SQL viene compilato in codice macchina per impostazione predefinita.

Answer 7

Ho scritto una quantità enorme di elaborazione in batch e la generazione di report programmi sia in PL/SQL e ProC per un progetto.Generalmente preferito scrivo in PL/SQL come proprio gli sviluppatori che permetterebbe di mantenere in futuro trovare quella più facile da capire che ProC codice.

È finito per essere solo il davvero funky di elaborazione o segnalazioni, che ha finito per essere scritto in Pro*C.

Non è necessario scrivere queste stored procedure come altri hanno già accennato, possono essere solo i file di script che vengono eseguiti come necessario, come una sorta di script di shell.Rendere il codice sorgente di controllo di revisione e la migrazione tra test e sistemi di produzione, un diavolo di molto più facile, troppo.

Answer 8

Fintanto che i calcoli è necessario eseguire può essere adeguatamente E readably catturato in PL/SQL, quindi utilizzando solo PL/SQL avrebbe più senso.

La vera fregatura è manutenibilità, e ' molto facile scrivere non gestibile SQL, se non altro perché ogni RDBMS ha una sintassi diversa, e diversa funzione la prima volta che fate un passo al di fuori della semplice SQL DML, e senza un vero standard per la formattazione.commenti, etc.

Answer 9

Ho creato programmi batch utilizzando C# e SQL.

Pro di C#:

Hai colto in pieno il libreria delle .NET, e la potenza di un linguaggio OO.

Contro di C#:

*Programma Batch e db separato - questo significa, dovrete gestire il vostro programma in lotti separati dal database.

*Avete bisogno di sfuggire a tutto che dang di codice sql.

Pro di SQL:

*Si integra bene con il DBMS.Se questo lavoro solo a manipolare il database, avrebbe senso includere con il database.Si finisce con un unico db e tutti i suoi componenti in un unico pacchetto.

*Non c'è bisogno di fuggire codice sql

*mantenendolo reale - la programmazione nel dominio del problema

Contro di SQL:

La sua SQL e io personalmente non so bene come SQL.

In generale, vorrei bastone con utilizzo di SQL a causa dei vantaggi sopra descritti.

Answer 10

Questa è una domanda caricato :) Ci sono un paio di programmazione di database di progetti di architettura si deve sapere e ciò che i loro costi/benefici.2 Tier generalmente significa che hai un client che si connette ad un DB, emissione diretta chiamate SQL.3 Tier generalmente significa che hai un "application server" che è emanazione diretta di SQL chiamate al DB, ma il client comunica al server di applicazioni.Generalmente, questo offre "fuori scala".Infine, si dispone di 2 1/2 livelli applicazioni che utilizzano un Livello 2 come formato, solo il lavoro è suddiviso in compartimenti all'interno di stored procedure.

Il processo di suoni come un "back office" una cosa del genere, e i clienti/processi, solo bisogno di risultati che vengono aggregati e nella cache una volta al mese.Che è, non c'è nessun agente che collega, e si connette spesso, e dice "fare i calcoli".Invece si allude a un processo che si verifica una volta in un po', e si può ottenere via con non in tempo reale.

Dunque, di fronte a tali esigenze, direi che, in generale, sarà più veloce per essere più vicini ai dati, e lasciare che SQL server fare tutti i calcoli.Penso che troverete che la vicinanza ai dati che vi servirà bene.

Tuttavia, nell'esecuzione di questi calcoli, si potrebbe scoprire che alcuni calcoli non sono suscettibili di SQL Server.Prendiamo ad esempio il calcolo del rateo di interesse del prestito obbligazionario, o qualsiasi strumento fixed income.Non molto bella in SQL, e molto più adatto per un ricco linguaggio di programmazione.Tuttavia, se si hanno medie semplici e altri abbastanza sano di mente aggregati, mi piacerebbe bastone di stored procedure su SQL lato.

Quindi, di nuovo, non ci sono abbastanza informazioni per la natura dei calcoli, o ciò che la vostra casa mandati in termini di SQL capacità degli sviluppatori per assistenza, o che cosa il vostro capo, dice...ma dal momento che ho una conoscenza di SQL, e come stare vicino ai dati, mi piacerebbe rimanere puro SQL Stored Procedure per un compito come questo.

YMMV :)

Answer 11

Di solito non è più espressiva, perché la maggior parte delle stored procedure lingue succhiare il design.Ma probabilmente tornerà a correre più veloce di un app esterne.

Credo che tutto si riduce a come ti conoscono sono con PL/SQL, quanto tempo hai per scrivere questo, quanto è importante la prestazione e se si può ragionevolmente aspettarsi manutentori di essere abbastanza familiarità con PL/SQL per mantenere un programma scritto in esso.

Se la velocità non è rilevante e manutentori sarà probabilmente non PL/SQL esperto, si potrebbe essere meglio con un 'tradizionale' la lingua.

Si potrebbe anche usare un approccio ibrido, in cui si utilizza PL/SQL per generare dati intermedi (ad esempio, tabella di join e di somme o quello che è) e un'applicazione separata per il controllo di flusso e controllo i valori e gli errori.