PostgreSQL işlem dilleri - PL / pgSQL ve SQL arasındaki farklar

Herkes arasındaki farkları özetleyebilir mi:

http://www.postgresql.org/docs/9.1/static/xfunc-sql.html

ve

http://www.postgresql.org/docs/9.1/static/plpgsql.html

?

Ana noktaları:

• kavramsal farklılıklar
• sorunlu bir aile verildiğinde, kullanım kolaylığı
• politik meseleler

PL / PgSQL ve düz SQL işlevlerinin her ikisi de daha büyük bir araç kümesinin parçasıdır ve bu bağlamda görüntülenmelidir. Bunu, işi iyi yapacak en basit aracı kullanmanız gereken artan karmaşıklık ve maliyetle eşleşen artan bir güç ölçeği olarak düşünme eğilimindeyim:

• Mümkün olduğunca görünümleri kullanın
• Bir görünüm uygun değilse, bir SQL işlevi kullanın
• Bir SQL işlevi uygun değilse PL / PgSQL kullanın.
• PL / PgSQL çok sınırlı veya yeterince etkileyici değilse, PL / Perl, PL / Python, PL / V8, PL / Java veya tercihiniz ne olursa olsun
• ... ve hiçbir PL'nin işi yapmayacağı yerlerde, harici bir program kullanın ve muhtemelen LISTENve NOTIFYonunla konuşmak için.

Bir fonksiyonun gerekli olduğunu düşündüğünüzde sıklıkla bir görünüm yeterlidir. SELECTTüm görünüm için son derece pahalı olsa da WHERE, sorgudaki görünüme başvuran maddeler genellikle görünüme itilir ve çok farklı sorgu planlarına neden olabilir. Genellikle SQL işlevlerini görünümlere dönüştürmekten büyük performans geliştirmeleri yaptım.

Bulduğunuz ana zaman bir görünümü kullanamazsınız ve bir SQL işlevini şu durumlarda dikkate almalısınız:

• WHEREBir WITHifadedeki bir parametre gibi, basit tümceler olarak ifade edilemeyen parametrelere ihtiyaç vardır
• Bir SECURITY DEFINERişlev aracılığıyla bir güvenlik bariyeri istiyorsunuz ve security_barrierPostgreSQL 9.2 ve üzerindeki görünümler ihtiyaçlarınız için yeterli değil;
• Optimize edici tarafından bir görünümün alt maddelerine aktarılmayan ve daha doğrudan kontrol etmek isteyen parametrelere ihtiyacınız vardır; veya
• Çok sayıda parametre var veya parametrelerin çok sayıda tekrarı var, bu nedenle sorguyu bir görünüm olarak yazmak pratik değildir.

Bu görevlerin çoğu için düz bir SQL işlevi iyi çalışır ve PL / PgSQL'den daha kolay okunur. SQL fonksiyonları ilan STABLEveya IMMUTABLE(ve ayrıca ilan STRICTveya SECURITY DEFINER) ayrıca çağıran deyimi içine satır içine yerleştirilmiş olabilir. Bu, işlev çağrısı yükünden kurtulur ve bazen, çağrı işlevindeki bir WHERE koşulu, optimize edici tarafından SQL işlevine itildiğinde büyük performans avantajlarına neden olabilir. Görev için yeterli olduklarında SQL işlevlerini kullanın.

SQL işlevlerinin işi yapmayacağı ana zaman, çok fazla mantığa ihtiyaç duyduğunuz zamandır. Eğer CASEifadeler olarak ifade edemeyeceğiniz / then / else işlemleri , hesaplanan sonuçların yeniden kullanımı, parçalardan değerler oluşturma, hata işleme, vb. SQL işlevlerini kullanamıyorsanız veya bunlar için uygun olmadığında PL / PgSQL'i seçin, örneğin:

• Aracılığıyla Dinamik SQL ve dinamik DDL EXECUTEdeyimi
• RAISEGünlükler veya istemci için hatalar / uyarılar istediğinizde
• İstisna işlemeye ihtiyacınız olduğunda - EXCEPTIONtüm işlemin hatada sona erdirilmesi yerine hataları bloklarla yakalayabilir ve işleyebilirsiniz
• CASE ... WHENÇok iyi uymayan karmaşık koşullu mantık
• Uygun olamayacağınız hesaplanmış değerlerin WITHve CTE'lerin yeniden kullanımı
• Dinamik kayıtlar oluşturma
• Sonuç kümesini oluşturduktan sonra bir eylem gerçekleştirmeniz gerekir

Ortak tablo ifadeleri (CTE'ler), özellikle yazılabilir CTE'ler ve WITH RECURSIVEPL / PgSQL'i kullandığımdan çok daha az kullandığımı görüyorum çünkü SQL çok daha etkileyici ve güçlü. Şimdi görünümleri ve düz SQL işlevlerini çok daha fazla kullanıyorum. Düz SQL işlevlerinin birden fazla ifade içerebileceğini hatırlamakta fayda var; son ifade işlevin sonucudur.

plpgsqldeğişkenler, döngü yapıları, vb. ile tam teşekküllü bir prosedür dilidir. Bir SQLişlev basitçe bir alt sorgudur. O ilanı halinde bir SQL fonksiyonu, STABLEya IMMUTABLEda bildirilmemiş STRICT, genellikle edilebilir inlined her referans üzerinde yazılı sanki, arama sorgusuna.