ส่วนขยายของการดักจับ SQL

ตามImmermanคลาสความซับซ้อนที่เกี่ยวข้องกับการสืบค้นSQLนั้นเป็นคลาสของการสืบค้นที่ปลอดภัยใน (แบบสอบถามที่มีคำสั่งซื้อครั้งแรก (กล่าวอีกนัยหนึ่งแบบสอบถาม SQL ทั้งหมดมีความซับซ้อนในและปัญหาทั้งหมดในสามารถแสดงเป็นแบบสอบถาม SQL ได้)$\mathsf{Q(FO(COUNT))}$$\mathsf{Q(FO(COUNT))}$$\mathsf{Q(FO(COUNT))}$

จากผลลัพธ์นี้จากมุมมองทางทฤษฎีมีปัญหาที่น่าสนใจมากมายที่สามารถแก้ไขได้อย่างมีประสิทธิภาพ แต่ไม่สามารถแสดงออกได้ใน SQL ดังนั้นส่วนเสริมของ SQL ที่ยังคงมีประสิทธิภาพน่าสนใจ ดังนั้นนี่คือคำถามของฉัน:

มีส่วนขยายของ SQL (ถูกนำไปใช้และใช้ในอุตสาหกรรม ) หรือไม่ซึ่งรวบรวม$\mathsf{P}$ (เช่นสามารถแสดงข้อความค้นหาที่คำนวณได้แบบพหุนามทั้งหมดและไม่มีผู้อื่น)?

ฉันต้องการภาษาสืบค้นฐานข้อมูลที่มีเงื่อนไขทั้งสามข้อ มันเป็นเรื่องง่ายที่จะกำหนดส่วนขยายที่จะขยาย SQL และจะจับ{P} แต่คำถามของฉันคือถ้าภาษาดังกล่าวเหมาะสมจากมุมมองของภาคปฏิบัติดังนั้นฉันต้องการภาษาที่ใช้ในทางปฏิบัติ หากไม่ใช่กรณีนี้และไม่มีภาษาดังกล่าวฉันอยากทราบว่ามีเหตุผลที่ทำให้ภาษาดังกล่าวไม่น่าสนใจจากมุมมองเชิงปฏิบัติหรือไม่? ตัวอย่างเช่นคำถามที่เพิ่มขึ้นในทางปฏิบัติมักจะง่ายพอที่ไม่จำเป็นต้องใช้ภาษาดังกล่าวหรือไม่?$\mathsf{P}$

สำหรับคำถามหลักของคุณฉันขอแนะนำการสำรวจสั้น ๆนี้โดย Martin Grohe

คำถามที่จำเป็นในการปฏิบัติมักง่ายพอที่ไม่จำเป็นต้องใช้ภาษาที่แข็งแกร่งกว่านี้หรือไม่?

ฉันจะบอกว่านี่ใช้เวลาส่วนใหญ่เนื่องจากจำนวนส่วนขยายที่เพิ่มเข้ามาในภาษาคิวรีทั่วไป (การปิดสกรรมกริยาตัวดำเนินการทางคณิตศาสตร์การนับ ฯลฯ ) นี่มาจากมุมมองของใครบางคนที่ทำงานในฐานะนักพัฒนาอิสระของเว็บไซต์ที่ค่อนข้างง่ายและแอพพลิเคชั่นอื่น ๆ ดังนั้นฉันไม่แน่ใจเกี่ยวกับการใช้งานจริงของ SQL ในอุตสาหกรรมขนาดใหญ่ / ฐานข้อมูลขนาดใหญ่

ในบางกรณีอาจจำเป็นต้องใช้ภาษาที่มีประสิทธิภาพมากกว่านี้เดาของฉันคือผู้พัฒนาซอฟต์แวร์จะจัดการกับพวกเขาโดยใช้ภาษาที่พวกเขาเขียนแอปพลิเคชันไม่ใช่แบบสอบถาม (เช่น C ++ หรือ java)

อย่างแรกพลังการแสดงออกของ SQL นั้นชัดเจนน้อยกว่าที่คิดไว้ คุณลักษณะการรวมการจัดกลุ่มและการคำนวณทางคณิตศาสตร์ของ SQL นั้นมีผลกระทบเล็กน้อย ก่อนหน้านี้ดูเหมือนว่าเป็นไปได้โดยการเข้ารหัสของผู้ประกอบการพีชคณิตโดยใช้คุณสมบัติเหล่านี้บางคนจริง ๆ แล้วสามารถแสดงความสามารถในการเข้าถึงใน SQL ปรากฎว่านี่ไม่ใช่กรณีของSQL-92ซึ่งก็คือ "local"

• Leonid Libkin พลังการแสดงออกของ SQL , TCS 296 (3), 379–404 ดอย: 10.1016 / S0304-3975 (02) 00736-3 ( พิมพ์ล่วงหน้า )

ซึ่งหมายความว่าจำเป็นต้องมีส่วนขยายสำหรับ SQL-92 ในการจับ PTIME และอีกอันที่อนุญาตให้ภาษาที่เป็นผลลัพธ์เป็น "non-local"

อย่างไรก็ตามการอนุญาตโครงสร้างที่ได้รับคำสั่งและด้วยเลขคณิต จำกัด ที่เหมือนจริงการพิสูจน์ว่า SQL-92 ไม่สามารถแสดงความสามารถในการเข้าถึงได้นั้นแปลว่าที่เหมือนกันและมีแนวโน้มว่าจะค่อนข้างยาก (มันอาจจะเป็นที่ถกเถียงกันอยู่ว่าการจัดเรียงเชิงเส้นตามธรรมชาตินั้นมีอยู่เสมอในประเภทข้อมูลใน SQL-92 และดังนั้นจึงสามารถสันนิษฐานได้ว่ามีการสั่งซื้อโครงสร้างพื้นฐาน)$\text{TC}^0 \subsetneq \text{NLOGSPACE}$

จากนั้นภูมิทัศน์เปลี่ยนไปอีกครั้งเนื่องจาก SQL: 1999 (SQL3) รวมการเรียกซ้ำ ดังนั้น SQL: 1999 ดูเหมือนว่าอย่างน้อยที่สุดจะแสดงออกได้ว่าเป็นตรรกะจุดคงที่ที่มีการนับ (แม้ว่าฉันคิดว่ารายละเอียดอาจจะค่อนข้างยุ่งยากอีกครั้งรวมถึงปัญหาของการสั่งซื้อ) ไม่ว่าการสร้างใหม่จะทำให้ตรรกะมีความหมายมากกว่าที่จำเป็นในการจับภาพ PTIME หรือไม่ฉันไม่รู้และจำเป็นต้องมีการศึกษาบางอย่างเพื่อสร้างสิ่งนี้ ในระหว่างนี้มีการแก้ไขเพิ่มเติมในปี 2546 , 2549 , 2551และ2554(เป็นเอกสาร ISO มีเพียงฉบับร่างเท่านั้นที่สามารถใช้ได้อย่างอิสระ) การแก้ไขเหล่านี้ได้เพิ่มฟีเจอร์ใหม่ทั้งหมดรวมถึงการอนุญาตให้ XQuery เป็น "ส่วน" ของการสืบค้น SQL ฉันเดาว่า "SQL" ตอนนี้มีความหมายมากกว่าที่จะจับ PTIME แต่การเข้ารหัสที่จำเป็นต้องทำอาจจำเป็นต้องใช้แบบสอบถามที่มีขนาดใหญ่และค่อนข้างไม่เป็นธรรมชาติซึ่งอาจไม่ได้รับการสนับสนุนในระบบจริง

ดังนั้นฉันคิดว่ามีหลักฐานว่าไม่มีส่วนต่อขยายของ SQL ที่จับ PTIME ได้อย่างแม่นยำตอบคำถามของคุณอย่างคลุมเครือ กล่าวโดยสรุปส่วนขยายอุตสาหกรรมค่อนข้างมีพลังและอาจมี PTIME ที่เกินกำหนดแล้ว หากเป็นจริงที่ SQL: 1999 มีประสิทธิภาพเพียงพอที่จะจับอย่างน้อย PTIME แล้วก็ยังไม่ชัดเจนว่า "SQL" หมายถึงอะไรจริงๆในคำถามของคุณเนื่องจากจะต้องกำหนด "SQL" เพื่อหมายถึงรุ่นก่อนหน้าของ SQL: 1999

$\text{P} \ne \text{NP}$

• Martin Grohe, การค้นหาตรรกะเพื่อจับภาพ PTIME , LICS 2008, 267–271 ดอย: 10.1109 / LICS.2008.11 ( พิมพ์ล่วงหน้า )

$P$$P$$P$$P$$P$

$P = NP$$P = NP$$P$$P$$NPC$

$P \ne NP$

$P = NP$

แม้ว่ามันอาจจะไม่ได้มีอยู่เพื่อจุดประสงค์ที่แท้จริง แต่ก็มีอยู่จริงและสามารถสร้างขึ้นได้และนำไปปฏิบัติได้ คุณสามารถกำหนดภาษานั้นด้วยสิ่งที่สามารถจำลองทัวริงเครื่องจนถึงจำนวนขั้นตอนที่กำหนด IE สามารถแก้ไขปัญหาP-Completeได้ อย่างไรก็ตามหากคุณสร้างสิ่งนี้มันเกือบจะเป็นทัวริงที่สมบูรณ์ยกเว้นข้อ จำกัด "ที่กำหนดจำนวนขั้นตอน" ที่ไม่เป็นเอกภาพซึ่งในภาษาที่คล้ายกับ SQL จะเป็นวิธีที่แปลกมากในการ จำกัด การสืบค้นที่ปลอดภัยเท่านั้น คุณสามารถทำสิ่งนี้ได้หากขั้นตอนเป็นบันทึกของบางตาราง แต่สิ่งนี้ก็ดูไม่คุ้มค่าสำหรับการใช้งานจริง