ทำไมฐานข้อมูลเชิงสัมพันธ์ยอมรับเฉพาะแบบสอบถาม SQL?

เท่าที่ฉันรู้ฐานข้อมูลเชิงสัมพันธ์ส่วนใหญ่ไม่ได้เสนอ API ระดับไดรเวอร์สำหรับการสืบค้นยกเว้นqueryฟังก์ชั่นที่ใช้สตริง SQL เป็นอาร์กิวเมนต์

ฉันกำลังคิดว่ามันจะง่ายกว่านี้หากมีใครทำได้:

var result = mysql.select('article', {id: 3})

สำหรับตารางที่เข้าร่วมมันจะซับซ้อนกว่าเล็กน้อย แต่ก็ยังเป็นไปได้ ตัวอย่างเช่น:

var tables = mysql.join({tables: ['article', 'category'], on: 'categoryID'});
mysql.select(tables, {'article.id': 3}, ['article.title', 'article.body', 'category.categoryID'])

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

มีเหตุผลที่เฉพาะเจาะจงหรือไม่ที่เลือกให้เฉพาะการเข้าถึงคิวรีผ่าน SQL เท่านั้น

ฐานข้อมูลไม่เพียงพอ - โดยปกติแล้วจะทำงานบนเซิร์ฟเวอร์อื่น ดังนั้นแม้ว่าคุณจะมี API ก็จะต้องส่งบางสิ่งบางอย่างข้ามสายที่แสดงถึงแบบสอบถามของคุณและการคาดการณ์ทั้งหมดของตัวกรองกลุ่มย่อยแบบสอบถามย่อยการแสดงออกเข้าร่วมฟังก์ชั่นรวม ฯลฯ สิ่งที่อาจเป็น XML หรือ JSON หรือบางส่วน รูปแบบที่เป็นกรรมสิทธิ์ แต่อาจรวมถึง SQL เพราะนั่นคือพยายามทดสอบและสนับสนุน

ทุกวันนี้เป็นเรื่องธรรมดาที่จะสร้างคำสั่ง SQL ด้วยตัวเองน้อยคนมักจะใช้ ORM แม้ว่าท้ายที่สุดสิ่งเหล่านี้จะแปลเป็นคำสั่ง SQL แต่พวกเขาอาจจัดหา API ที่คุณอยู่

เพราะ SQL มี API ทั่วไป คุณสามารถเขียนไดรเวอร์ที่สอดคล้องกับ ANSI 92 SQL ที่ส่ง SQL และแสดง API ที่คุณต้องการ เป็นโบนัสพิเศษมันจะทำงานกับฐานข้อมูล SQL เกือบทุกประเภทโดยไม่ต้องเขียนใหม่

หากทำในแบบของคุณทุกฐานข้อมูล SQL จะมี API ที่แตกต่างกัน แน่นอนว่าเราทุกคนจะได้มาตรฐานบน API ของคุณ แต่จากนั้นเราจะมี SQL อีกครั้งไม่มากก็น้อยใช่ไหม ยกเว้นว่า API ของคุณดูเหมือนจะเขียนโปรแกรมเฉพาะภาษา แต่ SQL ไม่ได้

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

ถ้า DBA ต้องการแฮงค์กับ SQL คุณต้องมีภาษาอื่นฐานข้อมูลจะมีภาระในการประมวลผลทั้งคู่

มีคุณสมบัติใหม่มากมายในฐานข้อมูลดังนั้นฉันไม่คิดว่ามันจะหยุดนิ่ง พวกเขาไม่ได้ทำสิ่งที่คุณเสนอด้วยเหตุผลบางอย่าง

SQL Server มีความสามารถในการเรียกใช้รหัส. NET จากภายในผ่านทาง SQL CLR สิ่งนี้มีประโยชน์สำหรับงานบางอย่างที่ไม่เหมาะกับโมเดลเชิงสัมพันธ์ แต่ต้องการรักษาประสิทธิภาพไว้ ฉันรู้ว่านี่ไม่ใช่สิ่งที่คุณกำลังมองหา มันเป็นตัวอย่างของฐานข้อมูลที่กำลังทำอยู่

มันจะไม่หายไปไหนเร็ว ๆ นี้ หนึ่งในฐานข้อมูลเมื่อเร็ว ๆ นี้เพื่อตีตลาดเป็นNuoDB พวกเขาเก็บ SQL, ให้กรดในขณะที่เพิ่มความสามารถในการกระจายเซิร์ฟเวอร์และเรียกใช้ในระบบคลาวด์ คุณอาจต้องการดูว่าทำไมพวกเขาถึงปัญหาทั้งหมดเพื่อส่งเสริมความต่อเนื่องของ SQL (ไม่ใช่เหตุผลเดียวของพวกเขา แต่เป็นจุดขายที่ยิ่งใหญ่)

SQL DBMS จัดเตรียมการเข้าถึงที่ดีที่สุดอย่างมากให้กับร้านค้าผ่านภาษาท้องถิ่นและอีกมากมายตามที่คุณทราบไม่มี API อื่น

การสังเกตว่าฐานข้อมูลไม่อยู่ในกระบวนการใช้ไม่ได้ในหลายกรณีและไม่เกี่ยวข้องโดยตรงจริงๆ

แม้แต่ฐานข้อมูลที่ต้องการการใช้ SQL DML ก็มักจะจัดให้มีเคอร์เซอร์ไลบรารี่เพื่อให้สามารถเข้าถึงตัวทำซ้ำในชุดผลลัพธ์และ Microsoft Access ที่รู้จักกันดีและ Btrieve SQL DBMS ทั้งคู่ยังมีอินเตอร์เฟสบันทึกโดยตรงไปยังตารางแต่ละตัวในฐานข้อมูล สำหรับการเข้าถึงที่มีประสิทธิภาพสูงมากภายใต้สถานการณ์เฉพาะ

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

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