SQL มีความสำคัญหรือไม่ถ้าฉันรู้ว่ากรอบ ORM นั้นดี? [ปิด]

50

ฉันไม่มีประสบการณ์ร้ายแรงใน SQL และฉันก็เกลียดที่จะเขียน SQL แทน LINQ ฉันมีความสุขมากกับ ORM

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

sql orm entity-framework

— ใคร ๆ
แหล่งที่มา

14

ฉันรู้สึกแก่. SQL ได้รับการสรุปที่ไกลพอที่คุณสามารถถามคำถามนี้อย่างจริงจัง

— ทำเครื่องหมาย

11

@ Mark: บางทีคุณสามารถถามคำถามอย่างจริงจังได้ แต่คำตอบยังคงเหมือนเดิม

— อดัมโรบินสัน

30

การรู้เลขคณิตยังคงมีความสำคัญหากฉันสามารถใช้เครื่องคิดเลขได้?

— Steven A. Lowe

4

NHibernate ที่ไม่มีความรู้เกี่ยวกับ SQL Profiler และวิธีการที่จะใช้ประโยชน์จาก JOIN นั้นเป็นประสิทธิภาพการทำงานที่เกิดขึ้นกับเซิร์ฟเวอร์ฐานข้อมูลของคุณ

— Chris S

2

คุณจำเป็นต้องรู้ HTML ไหมถ้าคุณสามารถใช้ Dreamweaver ได้?

— Tulains Córdova

63

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

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

แบบสอบถามแบบเรียกซ้ำและ / หรือลำดับชั้น
พารามิเตอร์ทางเลือก (โดยเฉพาะการแปลให้เป็นเพรดิเคตพิสัย)
ชนิดข้อมูลที่ผู้ใช้กำหนด
ประเภทเฉพาะแพลตฟอร์ม (ลำดับชั้น SQL และ TVPs, อาร์เรย์ของ Oracle และตารางที่ซ้อนกันเป็นต้น)
ชุดแทรก / อัพเดต / upserts / ลบ
คำแนะนำดัชนี
คำแนะนำการล็อค (โดยเฉพาะการล็อคการอัพเดทและการอ่านที่สกปรก)
การจัดการข้อผิดพลาด
Outer joins - ผลลัพธ์ของพวกเขากำหนดแผนที่ได้ไม่ดีกับโมเดล OOP ORM จำนวนมากมีภาษาคิวรีของตัวเอง แต่คล้ายกับรู้ SQL
การทำให้เป็นโมดูลผ่านกระบวนการที่เก็บไว้และ UDF โดยเฉพาะอย่างยิ่ง Inline UDF และ CROSS ใช้การสืบค้น
การใช้ OUTPUT / RETURNING สำหรับการจัดเตรียมข้อมูลลงในหลายตาราง
แบบสอบถามเพจจิ้งที่มีประสิทธิภาพ
แบบสอบถามตามฟังก์ชั่นหน้าต่าง (rownum, Rank, Partitions)

รายการเหล่านี้ยังคงดำเนินต่อไป - สิ่งเหล่านี้มากมายเป็นสิ่งที่สามเณร DBA ไม่เคยทำและนักพัฒนามือใหม่ไม่เคยได้ยินมาก่อน - แต่มันมีความสำคัญมากในแอพขนาดใหญ่

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

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

ฉันเห็นด้วยกับคะแนนส่วนใหญ่ของคุณ แต่เกี่ยวกับการรวมภายนอก: ใช่พวกเขาทำแผนที่ได้ไม่ดีใน OOP แต่ฉันคิดว่า OOP ที่เทียบเท่า (เช่นGroupJoinใน LINQ) นั้นดีกว่ามาก

— svick

@svick: มันมีประโยชน์ แต่ก็ไม่เหมือนกัน GroupJoinลองลอกเลียนแบบด้านนอกเต็มรูปแบบเข้าร่วมด้วย

— Aaronaught

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

— svick

@svick: ขอบคุณสำหรับเคล็ดลับ เกลียดที่จะดึงอันดับ แต่หลังจากที่หายไปนานหนึ่งปีฉันยังคงเป็นหนึ่งในผู้ให้ข้อมูลอันดับต้น ๆ สำหรับทั้งSQLและLinqใน Stack Overflow ดังนั้นฉันค่อนข้างแน่ใจว่าฉันเข้าใจความแตกต่างของวิธีการ การเข้าร่วมเต็มรูปแบบนั้นหายาก แต่บางครั้งพวกเขาก็เป็นสิ่งที่คุณต้องการจริง ๆ และไม่มีอนาล็อกใน Linq มันค่อนข้างยุ่งและไม่มีประสิทธิภาพในการรับชุดผลลัพธ์เดียวกันโดยไม่คำนึงว่ามันมีโครงสร้างอย่างไร

— Aaronaught

ดูเหมือนว่าเราจะเห็นด้วย ในกรณีส่วนใหญ่คุณไม่ต้องการเข้าร่วมภายนอก แต่เมื่อคุณทำมันยากที่จะแปลเป็น LINQ

— svick

90

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

— OtávioDécio
แหล่งที่มา

6

จริง คุณต้องรู้ตัวอย่างเช่นผลกระทบของคำแถลงการเข้าร่วมที่แตกต่างกันและผลกระทบที่มีต่อประสิทธิภาพ

— Chiron

15

+1 ไม่มีอาหารกลางวันฟรี! มีคำถามทั้งหมดโดยทั่วไปถามว่าไม่รู้คืออะไร?

— benzado

7

@benzado: ไม่ว่าฉันคิดว่ามันสมควรสำหรับ SQL แต่คุณต้องเลือกความไม่รู้ในบางสิ่ง; มีวิธีมากเกินไปที่จะรู้ว่าพวกมันทั้งหมด ดังนั้นฉันคิดว่ามันโอเคที่จะถามว่า "X ไม่จำเป็นเลยถ้าฉันรู้ว่า Y ดีจริง ๆ หรือถ้าฉันทำ Z?"

— Craig Walker

2

@ Craig ฉันเห็นด้วยว่ามีการเรียนรู้มากเกินไป แต่โปรแกรมเมอร์ควรมีความรู้พื้นฐานเกี่ยวกับระดับด้านล่างที่เขาทำงานอยู่

— benzado

2

ฐานข้อมูล @Craig Walker เป็นสิ่งสำคัญอย่างยิ่งสำหรับแอปพลิเคชันทางธุรกิจส่วนใหญ่ที่ไม่ได้มีอยู่

— HLGEM

25

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

— เควินไคลน์
แหล่งที่มา

14

ทักษะ SQL เป็นสิ่งที่ต้องมีความสามารถทางด้านไอทีในทุกวันนี้ LINQ เป็นเทคโนโลยีของ Microsoft เท่านั้น การใช้งาน SQL นั้นเหนือกว่าการพัฒนาเว็บและไคลเอนต์ / เซิร์ฟเวอร์แอปพลิเคชัน คุณไม่สามารถสร้างแบบจำลองฐานข้อมูลและทำ ETL ถ้าคุณไม่เก่งกับ SQL คุณอาจไม่จำเป็นต้องใช้ภาษาหลัก SQL ที่ใช้ใน ORACLE และ SQL Server สำหรับผลิตภัณฑ์ Data Warehous แต่คุณควรรู้จัก SQL มาตรฐาน ข้อมูลเบื้องต้นเกี่ยวกับ SQL นั้นง่ายมีวัสดุมากมายให้คุณเริ่มต้น

— ไม่มีโอกาส
แหล่งที่มา

1

ใครก็ตามที่รู้ว่า LINQ ทำงานอย่างไรจะสามารถเรียนรู้ SQL พื้นฐานในหนึ่งวัน นี่เป็นข้อโต้แย้งที่แย่มากสำหรับการเรียนรู้ SQL

— Boris Yankov

6

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

หากคุณปฏิเสธที่จะเรียนรู้ SQL คุณจะไม่มีธุรกิจใด ๆ ที่สัมผัสฐานข้อมูล SQL ไม่ว่าจะมีหรือไม่มี ORM และคุณควรหางานประเภทอื่น

— Marnen Laibow-Koser
แหล่งที่มา

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

— Thomas Bonini

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

— Marnen Laibow-Koser

3

+1: "ถ้าคุณปฏิเสธที่จะเรียนรู้ SQL คุณจะไม่มีธุรกิจใด ๆ ที่สัมผัสฐานข้อมูล SQL ไม่ว่าจะมีหรือไม่มี ORM และคุณควรหางานประเภทอื่น"

— เวกเตอร์

2

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

— HLGEM

1

+1 สำหรับ "เครื่องมือ (สำหรับสิ่งที่เป็นนามธรรมที่คุณรู้จัก) ไม่ใช่ไม้ค้ำ"

— sholsinger

4

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

แต่...

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

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

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

แค่สองชิ้นของฉัน

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

4

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

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

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

3

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

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

3

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

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

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

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

— Charalambos Paschalides
แหล่งที่มา

3

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

— HLGEM

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

— Tulains Córdova

1

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

— Charalambos Paschalides

2

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

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

ใครต้องการโต้ตอบกับฐานข้อมูลผ่านแอปพลิเคชันที่เขา / เธอกำลังสร้างเท่านั้น

— Tulains Córdova

2

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

1

คำตอบของคำถามประเภทนี้ทั้งหมด ("ฉันจำเป็นต้องรู้ X หรือไม่?") คือ "เรียนรู้มันในครั้งแรกที่คุณต้องการถ้าคุณต้องการมัน"

สิ่งสำคัญคือต้องไม่ตกหลุมพรางในการทำสิ่งต่าง ๆ ให้มีประสิทธิภาพน้อยลงเพราะคุณไม่รู้หรือไม่เต็มใจที่จะเรียนรู้วิธีที่มีประสิทธิภาพในการทำสิ่งนั้น

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

คุณแก้ไขข้อผิดพลาดและตอนนี้คุณต้องอัปเดต PostCount สำหรับผู้ใช้ทั้งหมด คุณจะทำอย่างไรมันได้หรือไม่?

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

เนื่องจากสถานการณ์เหล่านี้เป็นเรื่องธรรมดาฉันกลัวว่าคุณจะตกหลุมพรางที่อธิบายข้างต้น!

— โทมัสโบนินี
แหล่งที่มา

2

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

— benzado

2

อีกครั้ง "เรียนรู้มันเป็นครั้งแรกที่คุณต้องการมัน": ro-che.info/ccc/11.html

— MatrixFrog

1

ใช่คุณยังต้องการ SQL

อย่าข้ามไปสู่ข้อสันนิษฐานว่าบางสิ่ง "เก่า" นั้นไม่สมควรที่จะพิจารณา เทคโนโลยีที่เรียกว่า "มรดก" นั้นเป็นเทคโนโลยีที่ยังคงอยู่หลังจากที่ผ่านการทดสอบตามเวลามาแล้ว เราไม่เรียกคอมพิวเตอร์ว่า "มรดก" ของคอมพิวเตอร์วังพวกเขาล้มเหลวและหายไป

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

ไดโนเสาร์กินเวลาบนโลกนี้นานกว่ามนุษย์เราอยู่รอบ ๆ และถ้าคุณอ่าน Jurasic Park (ใช่หนังสือดีกว่าภาพยนตร์) จากนั้นฉันถามคุณคุณต้องการเผชิญ velociraptors hyper-clever ฉลาดมากหรือ T-Rex dogged ที่ไม่เคยยอมแพ้? อย่าถูกกัดโดยการประเมิน "ไดโนเสาร์" ;-)

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

0

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

เมื่อเราไปถึงจุดที่จัดการกับชุดข้อมูลขนาดใหญ่จะใช้เวลา 3 มิลลิวินาทีเมื่อทำด้วยมือและ 100 มิลลิวินาทีเมื่อคุณปล่อยให้เลเยอร์สิ่งที่เป็นนามธรรมทำเพื่อคุณโดยทั้งหมดให้เลเยอร์นามธรรมจัดการกับคุณเพราะคุณอาจ ช้ากว่า 30 เท่า แต่คุณยังคงเร็วพอสำหรับแอปพลิเคชั่นส่วนใหญ่ ความเป็นจริงของสถานการณ์เป็นอย่างไรเมื่อคุณมองหาโซลูชันที่ได้รับการปรับปรุงด้วยมือซึ่งคุณมีเวลาตอบสนอง 200 ms และเมื่อเลเยอร์นามธรรมจัดการกับมันสำหรับคุณอัลกอริทึมจะใช้เวลา 'เพียงแค่' ถึง 10 ครั้งในการแสดง 2 วินาทีล่าช้าและจากนั้นคุณสนใจสิ่งต่างๆมากมายไม่ว่าจะเป็นไปอย่างรวดเร็วและช้า การเห็นว่าโซลูชันฐานข้อมูลเชิงสัมพันธ์นั้นมีขนาดไม่ดีนักฉันไม่คิดว่าจะแก้ไขได้ภายในสองหรือสามปี ซึ่งหมายความว่าคุณจะต้องลงไปหาโลหะเปลือยสักพักเมื่อมันมาถึงฐานข้อมูลขนาดใหญ่หรือแอปพลิเคชันของคุณจะช้ามากมันไม่สามารถสู้กับคู่แข่งได้

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