ภาษาโพรซีเดอร์ PostgreSQL - ความแตกต่างระหว่าง PL / pgSQL และ SQL

ใครช่วยได้โปรดสรุปความแตกต่างระหว่าง:

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

และ

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

ประเด็นหลัก:

ความแตกต่างทางแนวคิด
ให้ครอบครัวที่มีปัญหาความสะดวกสบายในการใช้งาน
ประเด็นทางการเมือง

postgresql stored-procedures plpgsql

ประการแรกฟังก์ชั่น SQL (aka. query language) ไม่เกี่ยวข้องกับภาษาโพรซีเดอร์ PostgreSQL ใด ๆ ประการที่สองคุณได้พบแหล่งข้อมูลที่ดีที่สุดแล้วซึ่งสามารถค้นหาคำตอบสำหรับคำถามของคุณได้ (ยกเว้นข้อสุดท้าย - คุณคิดว่าอะไรคือ 'ปัญหาทางการเมือง')

— dezso

ฉันขอสรุปประเด็นสำคัญทั้งหมดโดยไม่จำเป็นต้องใช้เอกสารที่ฉันวาง แต่ต้องใช้การแสดงผลส่วนบุคคลด้วย ลิงค์เหล่านั้นมีไว้เพื่อให้แน่ใจว่าทุกคนเข้าใจว่าคำถามนั้นเกี่ยวกับอะไร

— Gismo Ranas

อย่าคิดว่าเป็นการจู่โจม แต่เมื่อคุณอ่านสิ่งที่คุณสามารถสรุปได้ด้วยตัวคุณเอง :) มิฉะนั้นคำถามของคุณจะค่อนข้างกว้าง แต่ให้เวลาซักหน่อยฉันจะพยายามรวบรวมความคิดเล็กน้อย

— dezso

อย่าเพิกเฉยภาษาขั้นตอนอื่น ๆ โดยเฉพาะ PL / Perl นั้นมีประโยชน์อย่างยิ่งสำหรับพื้นที่ที่ PL / PgSQL มี จำกัด PL / Pythonu ทำงานถ้าคุณชอบ Python แต่ไม่มีรูปแบบความปลอดภัยเช่น PL / Perl นอกจากนี้ยังมี PL / V8 (JavaScript) เป็นส่วนเสริม

— Craig Ringer

สวัสดี cataldo - ฉันแค่ยินดีต้อนรับคุณสู่เว็บไซต์นี้เป็นคำถามแรกของคุณที่นี่ ขอบคุณสำหรับการโพสต์และฉันหวังว่าคุณติดอยู่

— แจ็คดักลาส

ฟังก์ชัน PL / PgSQL และ SQL ธรรมดาเป็นส่วนหนึ่งของชุดเครื่องมือที่ใหญ่ขึ้นและควรดูในบริบทนั้น ฉันมักจะคิดในแง่ของระดับพลังงานที่สูงขึ้นซึ่งจับคู่โดยความซับซ้อนและต้นทุนที่สูงขึ้นซึ่งคุณควรใช้เครื่องมือที่ง่ายที่สุดที่จะทำงานได้ดี:

ใช้มุมมองที่เป็นไปได้
ในกรณีที่มุมมองไม่เหมาะสมให้ใช้ฟังก์ชัน SQL
ในกรณีที่ฟังก์ชัน SQL ไม่เหมาะสมให้ใช้ PL / PgSQL
ในกรณีที่ PL / PgSQL มีข้อ จำกัด หรือไม่ชัดเจนเพียงพอให้ใช้ PL / Perl, PL / Python, PL / V8, PL / Java หรืออะไรก็ตามที่คุณต้องการ
... และที่ใดที่ PL จะไม่ทำงานให้ใช้โปรแกรมภายนอกและอาจLISTENและNOTIFYเพื่อพูดคุยกับมัน

บ่อยครั้งที่มุมมองนั้นเพียงพอเมื่อคุณคิดว่าจำเป็นต้องใช้ฟังก์ชั่น แม้ว่าจะมีราคาแพงมากสำหรับSELECTมุมมองทั้งหมด แต่WHEREคำสั่งย่อยในแบบสอบถามที่อ้างอิงมุมมองนั้นมักจะถูกผลักลงไปในมุมมองและอาจส่งผลให้เกิดแผนแบบสอบถามที่แตกต่างกันมาก ฉันมักจะมีการปรับปรุงประสิทธิภาพขนาดใหญ่จากการแปลงฟังก์ชัน SQL เป็นมุมมอง

เวลาหลักที่คุณพบว่าคุณไม่สามารถใช้มุมมองและควรพิจารณาฟังก์ชัน SQL คือเมื่อ:

พารามิเตอร์ที่ไม่สามารถแสดงว่าเป็นWHEREคำสั่งแบบง่ายได้เช่นพารามิเตอร์ภายในWITHนิพจน์
คุณต้องการอุปสรรคด้านความปลอดภัยผ่านSECURITY DEFINERฟังก์ชั่นและsecurity_barrierมุมมองใน PostgreSQL 9.2 ขึ้นไปนั้นไม่เพียงพอสำหรับความต้องการของคุณ
คุณต้องการพารามิเตอร์ที่ไม่ถูกส่งลงในส่วนย่อยของมุมมองโดยโปรแกรมเพิ่มประสิทธิภาพและต้องการควบคุมโดยตรงมากกว่า หรือ
มี params จำนวนมากหรือมีการทำซ้ำของ params มากมายดังนั้นจึงไม่สามารถเขียนแบบสอบถามเป็นมุมมองได้

สำหรับงานเหล่านั้นส่วนใหญ่ฟังก์ชั่น SQL ธรรมดาทำงานได้ดีและมักจะอ่านง่ายกว่า PL / PgSQL ฟังก์ชั่น SQL ที่ประกาศSTABLEหรือIMMUTABLE(และยังไม่ประกาศSTRICTหรือSECURITY DEFINER) ยังสามารถ inline ลงในคำสั่งการโทร ที่ได้รับการกำจัดของค่าใช้จ่ายการเรียกใช้ฟังก์ชั่นและบางครั้งก็อาจส่งผลให้เกิดประโยชน์อย่างมากเมื่อเงื่อนไข WHERE ในฟังก์ชั่นการโทรได้รับการผลักลงในฟังก์ชั่น SQL โดยเพิ่มประสิทธิภาพ ใช้ฟังก์ชัน SQL เมื่อใดก็ตามที่เพียงพอสำหรับงาน

ฟังก์ชัน SQL เวลาหลักจะไม่ทำงานเมื่อคุณต้องการตรรกะจำนวนมาก หากการดำเนินการ / then / else ที่คุณไม่สามารถแสดงเป็นCASEคำสั่งได้นั้นจะใช้ผลการคำนวณจำนวนมากอีกครั้งการสร้างมูลค่าจากชิ้นส่วนการจัดการข้อผิดพลาด ฯลฯ PL / PgSQL มีประโยชน์อย่างมาก เลือก PL / PgSQL เมื่อคุณไม่สามารถใช้ฟังก์ชั่น SQL ไม่เช่นนั้น:

Dynamic SQL และ DDL แบบไดนามิกผ่านEXECUTEคำสั่ง
เมื่อคุณต้องการRAISEข้อผิดพลาด / คำเตือนสำหรับบันทึกหรือลูกค้า
เมื่อคุณต้องการจัดการข้อยกเว้น - คุณสามารถดักจับและจัดการข้อผิดพลาดด้วยEXCEPTIONบล็อกแทนการทำธุรกรรมทั้งหมดยุติข้อผิดพลาด
ตรรกะเงื่อนไขที่ซับซ้อนที่ไม่เหมาะสมCASE ... WHENเป็นอย่างดี
มีการใช้ค่าที่คำนวณได้จำนวนมากซึ่งคุณไม่สามารถนำไปใช้กับWITHCTE ได้
การสร้างบันทึกแบบไดนามิก
คุณต้องดำเนินการหลังจากสร้างชุดผลลัพธ์

ด้วยตารางนิพจน์ทั่วไป (CTE) โดยเฉพาะอย่างยิ่ง CTE ที่เขียนได้และWITH RECURSIVEฉันพบว่าฉันใช้ PL / PgSQL น้อยกว่าที่ฉันเคยใช้เพราะ SQL นั้นแสดงออกและทรงพลังกว่ามาก ฉันใช้มุมมองและฟังก์ชั่น SQL ธรรมดามากขึ้นตอนนี้ มันควรค่าแก่การจดจำว่าฟังก์ชัน SQL ธรรมดาสามารถมีมากกว่าหนึ่งคำสั่ง; คำสั่งสุดท้ายคือผลลัพธ์ของฟังก์ชัน

— Craig Ringer
แหล่งที่มา

พูดได้เป็นอย่างดี! (เพิ่มเติมแม้ว่าเสมือน +1 สำหรับการกล่าวขวัญ CTEs เขียนได้)

— Dezso

คำตอบนี้ยังอธิบายว่าทำไมฟังก์ชั่นบางอย่างรั้วการเพิ่มประสิทธิภาพ

— Eonil

plpgsqlเป็นภาษาขั้นตอนเต็มเปี่ยมด้วยตัวแปรการวนลูปสร้าง ฯลฯSQLฟังก์ชั่นเป็นเพียงแบบสอบถามย่อย ฟังก์ชั่น SQL หากมีการประกาศSTABLEหรือIMMUTABLEไม่ประกาศยังSTRICTมักจะสามารถinlinedลงในแบบสอบถามโทรราวกับว่ามันถูกเขียนออกมาในแต่ละอ้างอิง

— kgrittn
แหล่งที่มา