ยังคงมีความจำเป็นในการเขียน SQL หรือไม่?

ด้วยเครื่องมือ ORM จำนวนมากสำหรับภาษาที่ทันสมัยส่วนใหญ่ยังมีกรณีการใช้งานสำหรับการเขียนและดำเนินการ SQL ในโปรแกรมในภาษา / สภาพแวดล้อมที่สนับสนุนพวกเขาหรือไม่? ถ้าเป็นเช่นนั้นทำไม

เพื่อความชัดเจน:ฉันไม่ได้ถามว่าโปรแกรมเมอร์จำเป็นต้องรู้จัก SQL หรือไม่ถ้าฉันควรมีเครื่องมือ SQL บนเดสก์ท็อปของฉัน ฉันถามโดยเฉพาะว่าทำไมฉันถึงมีมันในรหัส (หรือ config หรืออะไรก็ตาม) เมื่อเทียบกับ ORM

• คุณเขียน SQL เพื่อสืบค้นข้อมูลได้สะดวกกว่าที่คุณเขียนรหัสขั้นตอน
• ORM ของคุณในขณะที่สวยงามมองดูสร้าง SQL ช้าอย่างน่ากลัวในบางพื้นที่ที่สำคัญ
• คุณต้องใช้ประโยชน์จากฟังก์ชั่นที่ RDBMS เปิดเผยซึ่งไม่สามารถ / ไม่สามารถใช้งานได้ผ่าน ORM ของคุณ
• ทุกครั้งที่คุณพิมพ์SELECT * FROM...พระเจ้าจะฆ่าลูกแมว และคุณเกลียดลูกแมว
• คุณไม่ได้ใช้ ORM, OOP หรือภาษาสมัยใหม่

การเขียน SQL ที่ซับซ้อน

ออมเป็นสิ่งที่ดีสำหรับสิ่งพื้นฐาน อย่างไรก็ตามสำหรับสถานการณ์ที่ซับซ้อนคุณจะต้องเขียน SQL

ดังนั้นในระยะสั้นมีความต้องการ SQL อย่างแน่นอนและจะยังคงเป็นเช่นนั้นเสมอ

• เข้าชม
• ทริกเกอร์
• ข้อ จำกัด
• แพ็คเกจ (SSIS, DTS, ฯลฯ )
• ทุกเวลาที่คุณต้องการควบคุมการไหลของการดำเนินการอย่างแม่นยำ

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

แน่นอนว่า:

• โดยทั่วไป ORM แค็ปซูลมาก แต่ในที่สุดคุณควรรู้ว่าเกิดอะไรขึ้นเบื้องหลัง นี่เป็นสิ่งสำคัญสำหรับประสิทธิภาพและความยืดหยุ่น แม้ว่าในแอปพลิเคชั่นฉันไม่ได้เขียน SQL จำนวนมาก แต่ฉันรู้คร่าวๆว่า SQL หรือ DDL นั้นเป็นอย่างไร
• SQL โดยตรงมักจะดีในการเขียนแบบสอบถามแบบอ่านอย่างเดียว ง่ายกว่าการกำหนดในภาษาคิวรี ORM และคุณยังสามารถ จำกัด ชุดผลลัพธ์ (เช่น 'select id จาก ..... ')
• ออมควรไม่ให้คุณออกจาก SQL เลย ฉันใช้ SQL เป็นจำนวนมากสำหรับคิวรีแบบเฉพาะกิจบน DB-client (เช่น mysql-client) มันช่วยให้คุณมีอินเตอร์เฟซเครื่องแบบและฟังก์ชันการจัดกลุ่มที่ดีมาก

ORMs เกิดขึ้นเนื่องจากความไม่ตรงกันของอิมพีแดนซ์ระหว่างการปรับใช้ฐานข้อมูลเชิงสัมพันธ์ร่วมกับคุณสมบัติภาษา OO ของเรา พวกเขาเป็นเพียงสะพาน แต่คนส่วนใหญ่ปฏิบัติ SQL เช่น Limburger ชีสในตู้เย็น

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

ในทางปฏิบัติฉันไม่เคยเห็นโครงการ pure-ORM ที่ไม่ต้องการ SQL อย่างน้อยเพื่อค้นหาฐานข้อมูลสำหรับการตรวจสอบขั้นสุดท้าย

ORMs เป็นเครื่องมือในกล่องเครื่องมือโปรแกรมเมอร์ พวกเขามีปัญหาของตัวเอง ตัวอย่างบางส่วนคือ:

• ไม่สามารถควบคุม sql
• ประสบกับปัญหา n + 1

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

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

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

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

บางครั้งลูกค้าต้องการเพียงแค่การสืบค้นที่รวดเร็วและง่ายดายในการส่งคืนข้อมูลสำหรับรายงานการส่งออก datadump และอื่น ๆ และต้องการรอให้โปรแกรมทั้งหมดได้รับการพัฒนา

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

นอกจากนี้เมื่อใช้ฐานข้อมูลเช่น Oracle ด้วยภาษาขั้นตอนที่สมบูรณ์และทรงพลังคุณสามารถทำอะไรได้มากมายโดยไม่ต้องใช้ "โปรแกรม" PL / SQL บน Oracle ในมือขวานั้นรวดเร็วและมีประสิทธิภาพมาก

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

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

ใช่คุณสามารถหลีกเลี่ยงการเขียน SQL แต่คุณจะเขียน HQL แทน (หรือ Linq หรือ DQL ... )!

อย่างจริงจังฉันเป็นแฟนตัวยงของ ORMs และฉันคิดว่าบางคนอาจหลีกเลี่ยงการใช้ SQL บริสุทธิ์เป็นส่วนใหญ่ แต่เราต้องจำไว้ว่า ORM เป็นเพียงหนึ่งในสิ่งที่เป็นนามธรรมและนามธรรมที่ยิ่งใหญ่ทั้งหมดรั่วไหล ...

(แต่เกี่ยวกับปัญหา N + 1: สิ่งนี้เกี่ยวข้องกับการโหลดแบบสันหลังยาวและเครื่องมือ ORM ส่วนใหญ่มีวิธีขอโหลดแบบกระตือรือร้นจึงหลีกเลี่ยงปัญหานั้นได้)

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

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

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

เวลาที่เหลือคุณอาจไม่ต้องการ SQL สำหรับเนื้อหา CRUD ของคุณ แต่มีจำนวนมากใน SQL มากกว่าแบบง่าย SELECT, INSERT, UPDATE และแบบสอบถาม JOIN พื้นฐาน คุณสามารถทำสิ่งที่ฉลาดมากกับมันและแม้ว่าคุณอาจไม่ได้ใช้มันบ่อยครั้งมันมีประโยชน์ที่จะรู้ว่าพวกเขาคืออะไร

มากขึ้นฉันคิดว่าเราจะพบตัวเองในโลกโพสต์ SQL อย่างไรก็ตามบริการคลาวด์ส่วนใหญ่ใช้ที่จัดเก็บตารางที่ไม่ใช่ sql และสำหรับงานประเภท CRUD ที่เรียบง่ายพลังเต็มรูปแบบของ SQL นั้นไม่จำเป็น แต่นั่นไม่ได้หมายความว่าจะไม่มีคุณค่าในการทำความเข้าใจ

และแน่นอนว่าต้องมีคนรู้มากพอที่จะเขียนระบบ ORM ที่ดีกว่าถ้าคนปัจจุบันยังไม่มาก มันจะช่วยพวกเขาหากพวกเขารู้จัก SQL ...

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

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

ความซับซ้อนและปริมาณของ SQL ที่ฉันเขียนนั้นไม่เพียงพอที่จะเชื่อมโยงกับกรอบงาน ORM ได้อย่างสมเหตุสมผล

(ฉันเขียน SQL อาจเดือนละครั้งถ้า)

ฉันเจอกับกองกำลังขนาดใหญ่หลายแห่งกับ DBA ที่กลัว devs โดยใช้เครื่องมือ ORM

พวกเขาเป็น DBA ที่เกี่ยวข้องกับการปรับแต่งและประสิทธิภาพ

และใช่แล้วเครื่องมือ ORM สามารถจัดการให้ทำสิ่งนี้ได้ แต่ฉันเคยเห็นสถานที่ที่พวกเขาจะยอมรับเฉพาะกระบวนงานที่เก็บไว้ (SQL Server) และจะถามคุณเกี่ยวกับสิ่งที่คุณทำ

นอกจากนี้เครื่องมือ ORM ยังสามารถถูกทารุณกรรมและสร้าง Sql ที่แย่ได้เช่นเดียวกับการเขียน Sql ด้วยตัวคุณเอง

Onegie - DDL และการย้ายฐานข้อมูล บางครั้งคุณจำเป็นต้องต่อประสานสิ่งนั้นเพื่ออัปเดตสิ่งต่าง ๆ โดยไม่ทำลายข้อมูลที่มีอยู่