Linguaggi diversi da SQL in Postgres

Question

Ultimamente ho usato PostgreSQL un po' e una delle cose che penso sia interessante è che puoi usare linguaggi diversi da SQL per funzioni di scripting e quant'altro.Ma quando è effettivamente utile?

Ad esempio, la documentazione dice che l'uso principale di PL/Perl è che è piuttosto bravo nella manipolazione del testo.Ma non è forse questo qualcosa che dovrebbe essere programmato nell'applicazione?

In secondo luogo, esiste un motivo valido per utilizzare un linguaggio non attendibile?Sembra che fare in modo che qualsiasi utente possa eseguire qualsiasi operazione sarebbe una cattiva idea su un sistema di produzione.

PS.Punti bonus se qualcuno può fare PL/LOLCODICE sembrare utile.

Answer 1

"non è [la manipolazione del testo] qualcosa che dovrebbe essere programmato nell'applicazione?"

Di solito sì.Il generalmente accettato "tre livelli" La progettazione dell'applicazione per i database afferma che la logica dovrebbe trovarsi nel livello intermedio, tra il client e il database.Tuttavia, a volte è necessaria una logica in un trigger o è necessario indicizzare una funzione, richiedendo che del codice venga inserito nel database.In quel caso tutto il solito "Quale lingua dovrei usare?" vengono sollevate domande.

Se hai solo bisogno di un po' di logica, probabilmente dovresti usare il linguaggio più portabile (pl/pgSQL).Se hai bisogno di programmare seriamente, potrebbe essere meglio usare un linguaggio più espressivo (forse pl/ruby).Questo sarà sempre un giudizio.

"esiste qualche motivo valido per utilizzare un linguaggio non attendibile?"

Come sopra, sì.Ancora una volta, inserire l'accesso diretto ai file (ad esempio) nel livello intermedio è la soluzione migliore quando possibile, ma se è necessario attivare le cose in base a trigger (che potrebbero richiedere l'accesso a dati non disponibili direttamente nel livello intermedio), è necessario le lingue.Non è l'ideale e generalmente dovrebbe essere evitato.E devi assolutamente proteggerne l'accesso.

Answer 2

@Mike:questo tipo di pensiero mi rende nervoso.Ho sentito molte volte "questo dovrebbe essere infinitamente portatile", ma quando viene posta la domanda:prevedete effettivamente che ci sarà qualche porting?la risposta è:NO.

Attenersi al minimo comune denominatore può davvero compromettere le prestazioni, così come l'introduzione di livelli di astrazione (ORM, PHP PDO, ecc.).La mia opinione è:

• Valutare realisticamente se è necessario supportare più RDBMS.Ad esempio, se stai scrivendo un'applicazione web open source, è probabile che tu debba supportare almeno MySQL e PostgreSQL (se non MSSQL e Oracle)
• Dopo la valutazione, sfrutta al massimo la piattaforma che hai scelto

E comunque:stai mescolando database relazionali con database non relazionali (CouchDB è non un RDBMS paragonabile ad esempio a Oracle), esemplificando ulteriormente il fatto che il bisogno percepito di portabilità è molte volte ampiamente sovrastimato.

Answer 3

In questi giorni, qualsiasi caratteristica "unica" o "interessante" in un DBMS mi rende incredibilmente nervoso.Mi viene un'eruzione cutanea e devo smettere di lavorare finché il prurito non scompare.

Odio semplicemente essere rinchiuso su una piattaforma inutilmente.Supponiamo di costruire una grossa parte del tuo sistema in PL/Perl all'interno del database.Oppure in C# in SQL Server o PL/SQL in Oracle, ci sono moltissimi esempi*.

Ora scopri all'improvviso che la piattaforma che hai scelto non è scalabile.Oppure non è abbastanza veloce.O qualcosa.Peggio ancora, c'è un nuovo ragazzo nel blocco del database (qualcosa come MonetDB, CouchDB, Cache, diciamo ma molto più interessante) che risolverebbe tutti i tuoi problemi (anche se il tuo unico problema, come il mio, è avere una piattaforma databse poco interessante).E non puoi passare ad esso senza ricodificare metà della tua applicazione.

(*Certamente, i prodotti a pagamento cercano in una certa misura di bloccarti convincendoti a utilizzare le loro caratteristiche uniche, il che non è un'accusa che può essere rivolta direttamente ai fornitori gratuiti, ma l'effetto è lo stesso).

Quindi questo è uno sfogo sulla prima parte della domanda.Di cuore, però.

Esiste un motivo valido per utilizzare una lingua non attendibile?Sembra che realizzare in modo che qualsiasi utente possa eseguire qualsiasi operazione sarebbe una cattiva idea

Mio Dio, sì, lo fa!Una sorta di "attacco con iniezione di Perl"?Quasi vale la pena farlo solo per vedere cosa succede, avrei pensato.

Per le ragioni filosofiche sopra delineate penso che rinuncerò alla sfida PL/LOLCODE.Anche se sono rimasto un po' stupito nello scoprire che si trattava di un collegamento a qualcosa di esistente.

Answer 4

Dal mio punto di vista, immagino che la risposta sia "dipende".

Si sostiene che la manipolazione dei dati appartiene al livello del database, in modo che la logica aziendale non debba preoccuparsi eccessivamente di come avviene la manipolazione, sa solo che lo è.

Un altro ottimo motivo per elaborare i dati sul livello DB è se il volume dei dati da ridurre significa che la larghezza di banda della rete diventerà un problema.Una volta dovevo classificare quantità molto grandi di dati.L'elaborazione a livello di applicazione era fortemente limitata dal tempo necessario per trasferire tutti i dati attraverso la rete per l'elaborazione.

Ho quindi scritto un algoritmo di binning in PL/pgSQL e ha funzionato molto più velocemente.

Per quanto riguarda i linguaggi non attendibili, ho ascoltato un podcast di Josh Berkus (un sostenitore di postgres) che discuteva di un'applicazione di postgresql che importava dati da MySQL come parte della sua elaborazione, in modo che la comunicazione stessa fosse gestita dal server postgres.Non ricordo tutti i dettagli, penso che fosse sul FLOSS Podcast settimanale che è una discussione piuttosto interessante sulla storia di PostGRESQL e su alcune delle questioni a cui è sottoposto.

Answer 5

Le versioni non attendibili dei linguaggi procedurali consentono di accedere all'I/O sul sistema.Questo può tornare utile se hai bisogno di un trigger o qualcosa del genere per inviare un'e-mail o connetterti a un server socket per inviare una notifica popup.Ci sono tantissimi usi per questo tipo di cose e, grazie ai livelli di isolamento postgresql, puoi tranquillamente fare cose come questa.Puoi inserire punti di controllo nella funzione, quindi se la transazione fallisce l'e-mail o qualsiasi altra cosa non verrà inviata.La cosa bella di farlo è che rimuove la logica dal client e la inserisce nel server.

Answer 6

Penso che la maggior parte delle lingue aggiuntive siano offerte in modo che, se sviluppi regolarmente in quella lingua, puoi sentirti a tuo agio nello scrivere funzioni db, trigger, ecc.L'utilità di queste funzionalità è fornire un controllo sui dati il ​​più vicino possibile ai dati.

Answer 7

Un esempio di un'utile procedura memorizzata che ho scritto di recente in un linguaggio esterno che non sarebbe stato possibile in pl/sql è una versione di 'df' che consentiva ai generatori di tabelle SQL di scegliere un tablespace con il maggior spazio libero disponibile in fase di runtime.

Ho usato plperlu ed è stato relativamente semplice, anche se ho dovuto fare attenzione alla digitazione dei dati.