ทำไมไม่รัก SQL? [ปิด]

116

เมื่อเร็ว ๆ นี้ฉันได้ยินมามากแล้วว่า SQL เป็นภาษาที่แย่มากและดูเหมือนว่าทุกเฟรมเวิร์กภายใต้ดวงอาทิตย์จะมาพร้อมกับเลเยอร์นามธรรมของฐานข้อมูล

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

อะไรทำให้ SQL แย่มากและทำไมเลเยอร์นามธรรมของฐานข้อมูลจึงมีค่า

sql  frameworks 
— Travis
แหล่งที่มา
11
สิ่งที่เกี่ยวกับความปลอดภัยประเภท?
— จอห์นนี่
3
ชั้นนามธรรมเหล่านี้กำหนดเป้าหมายไปที่ใครกันแน่? SQL ไม่ใช่ภาษาที่ทุกคนเก่งดังนั้นพวกเขาจึงอาจมุ่งเป้าไปที่โปรแกรมเมอร์ระดับปานกลาง SQL นั้นไม่ใช่ภาษาที่ดีสำหรับผู้ที่ไม่ใช่โปรแกรมเมอร์
— David Thornley
27
@ David: กำหนดภาษา (คอมพิวเตอร์) ที่ "ดีสำหรับผู้ที่ไม่ใช่โปรแกรมเมอร์" IMHO ที่ไม่ใช่โปรแกรมเมอร์ควรอยู่ห่างจากภาษาโปรแกรม (และในความหมายที่กว้างขึ้นของคำ SQL)
— DevSolar
15
คำตอบทั้งหมดควรเป็น wiki ด้วย มันเป็นเรื่องบ้ามากที่คำถามและคำตอบเหล่านี้ได้รับคะแนนโหวตมากมาย ฉันคิดว่านี่เป็นฟอรัมทางเทคนิค? คุณสามารถแก้ปัญหาของใครบางคนได้โดยการให้โค้ดที่เขียนยากและได้รับคะแนนโหวตหนึ่งหรือสองคะแนน แต่ตอบคำถามแบบนี้และรับคะแนนโหวตมากมาย นั่นเป็นเรื่องง่อยจริงๆถ้าคุณถามฉัน
— กม ธ .
6
@KM: ปัญหาในการโหวตคือขึ้นอยู่กับจำนวนคนอ่านคำตอบ ฉันตอบคำถามเกี่ยวกับ NHibernate และ Rhino Mocks ซึ่งใช้เวลาพอสมควรในการตอบถูกและได้รับการตอบรับ แต่ไม่ได้รับการโหวตเพียงครั้งเดียว หากคุณตอบคำถามเกี่ยวกับ C # คุณจะได้รับคะแนนโหวตมากมาย การโหวตไม่ยุติธรรม แนะนำบางอย่างใน meta.stckoverflow ถ้าคุณรู้อะไรดีกว่า
— Stefan Steinegger

คำตอบ:

132

นี่เป็นส่วนหนึ่งของอัตนัย นี่คือความคิดเห็นของฉัน:

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

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

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

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

แต่มันเป็นเรื่องจริง - ไม่มีทางเลือกอื่นที่เป็นไปได้ ดังนั้นเราทุกคนจะใช้ SQL ในอีกไม่กี่ปีข้างหน้า

— Stefan Steinegger
แหล่งที่มา
31
"เพียงระบุสิ่งที่คุณต้องการ - เราจะจัดส่งโดยเร็วที่สุด" วิธีการที่เปิดเผยนั้นยอดเยี่ยมและมันทันสมัยจริงๆ (คิดว่า LINQ) เป็นเรื่องจริงในบางครั้งคุณต้องปรับแต่งเพื่อความเร็วและทางเลือกขั้นตอนสำหรับ SQL อาจมีประโยชน์ แต่ฉันยังคงใช้ SQL แบบเปิดเผยเกือบตลอดเวลาเพื่อความเรียบง่าย
— MarkJ
4
MarkJ: ฉันจำได้ว่าฉันเรียงลำดับคำสั่ง WHERE ใหม่เพื่อเพิ่มประสิทธิภาพการสืบค้นใน oracle พวกเขาแก้ไขจากล่างขึ้นบน ... แย่มาก
— Stefan Steinegger
16
ฉันเห็นด้วยอย่างสมบูรณ์ คนไอทีหลงใหลในเครื่องมือที่ไม่ใช่ขั้นตอน มันจะง่ายกว่านี้ไหมถ้าคุณบอกคอมพิวเตอร์ว่าคุณต้องการอะไรและคิดว่าจะทำอย่างไร! ใช่ถ้าคอมพิวเตอร์ฉลาดพอที่จะทำเช่นนั้นจริงๆ แต่มันไม่ใช่ ฉันอยากจะบอกว่ารถของฉัน "พาฉันไปหายาย" แล้วมันจะขับไปที่นั่น แต่มันไม่เป็นเช่นนั้นฉันจึงไม่เพียงแค่ปล่อยพวงมาลัยและแสร้งทำเป็นว่าจะได้ผล สักวันหนึ่งเทคโนโลยีจะมาถึงที่นั่นหรือบางทีนั่นอาจเป็นความฝันที่เป็นไปไม่ได้ แต่วันนี้ไม่มีแล้ว (ต่อ ... )
— เจ
12
Touch? คำตอบของคุณอธิบายถึงความผิดหวังในช่วงแรกของฉันกับ SQL ได้อย่างสมบูรณ์ ฉันเขียนโค้ดขั้นตอนจำนวนมากเพราะฉันไม่ไว้วางใจให้ SQL สร้างแผนการดำเนินการที่มีประสิทธิภาพ เมื่อฉันคุ้นเคยกับ SQL มากขึ้นฉันก็ค้นพบว่าจริงๆแล้วมันค่อนข้างดีในการปรับให้เหมาะสมและ SQL ที่เขียนอย่างถูกต้องมักจะทำงานได้เร็วกว่าโค้ดขั้นตอนของฉัน
— Kluge
5
@Jay และผู้สงสัย SQL อื่น ๆ ปัญหาในประสบการณ์ของฉันคือการใช้ SQL อย่างมีประสิทธิภาพคุณต้องสามารถคิดในรูปแบบของชุดและไม่ใช่ขั้นตอน - ซึ่งเป็นวิธีที่โปรแกรมเมอร์ส่วนใหญ่ได้รับการสอนให้คิด การใช้ SQL อย่างมีประสิทธิภาพนั้นไม่ใช่เรื่องยากและอยู่ใกล้แค่เอื้อมของ coder ที่มีความสามารถใด ๆ (เช่นเดียวกับใครก็ตามที่อ่าน SO!) แต่จำเป็นต้องใช้ความพยายามในการข้ามไปสู่การคิดตามตรรกะที่ตั้งไว้และส่วนใหญ่แล้วผู้คนก็ไม่ได้ใช้ ไม่ต้องกังวล (และฉันกำลังแก้ไขโปรแกรมที่ coder ดั้งเดิมทำทุกอย่างโดยใช้เคอร์เซอร์ด้วยเหตุผลนี้อย่างแม่นยำ)
— Cruachan
58

นอกเหนือจากทุกอย่างที่ได้รับการกล่าวว่าเทคโนโลยีไม่ได้จะไม่ดีที่จะทำให้ชั้น abstraction ที่มีคุณค่า

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

SQL ดีมาก ชั้น Abstraction ทับทำให้ยิ่งใหญ่ขึ้น!

— มิเกลเวนทูรา
แหล่งที่มา
6
ทางการทูตมาก! (และจริงเพื่อบู๊ต!)
— Joseph Ferris
2
ปัญหาคือการผกผันที่เป็นนามธรรม SQL ในฐานข้อมูลเชิงสัมพันธ์คือสภาพแวดล้อมการประกาศตามชุด มีความเป็นนามธรรมในระดับที่สูงกว่าการเขียนโปรแกรมเชิงวัตถุเชิงวัตถุหรือไม่
— Steven Huwig
2
อาจจะเป็นเช่นนั้นสตีเวน แต่ในแง่ของแอปพลิเคชั่นมันทำหน้าที่ระดับต่ำ (แม้ว่าจะทำในระดับที่สูงมากก็ตาม) ไม่ว่าคุณจะทำการเปลี่ยนแปลงที่บ้าคลั่งในระดับฐานข้อมูลในตอนท้ายของวันมันก็เป็นตัวรับและเซ็ตเตอร์ที่ได้รับการยกย่อง หรือคุณอาจมองในทางตรงข้ามเพราะมันเป็นระดับที่สูงเกินไปที่จะผสมกับแอปพลิเคชันและต้องแยกและพิจารณาแยกกัน ไม่ว่าในกรณีใดการเก็บ SQL ไว้นอกรหัสแอปพลิเคชันหลักมีประโยชน์อย่างมากในแง่ของความสามารถในการอ่านและการปรับโครงสร้างใหม่
— เผยแพร่
53

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

แม้ว่าฉันเห็นด้วยว่า SQL ดีกว่าชั้นนามธรรมส่วนใหญ่ที่นั่น ไม่ใช่ความผิดของ SQL ที่ใช้กับสิ่งที่ไม่ได้ออกแบบมาสำหรับ

— Joonas Pulakka
แหล่งที่มา
19
ฉันไม่เข้าใจว่าความเข้ากันไม่ได้ของภาษาถิ่นของ SQL สามารถเป็น "จุด" ขนาดใหญ่เมื่อเทียบกับ SQL ได้อย่างไร เหมือนกับการบอกว่า C เป็นเรื่องไร้สาระเพราะคุณไม่สามารถคอมไพล์ + รันซอร์สเดียวกันใน Linux distros ที่แตกต่างกันได้ ถ้าหากเป็น IF ที่ยิ่งใหญ่ บริษัท ของคุณตัดสินใจที่จะเปลี่ยนผู้ให้บริการฐานข้อมูลเป็นเหตุการณ์ที่เกิดขึ้นได้ยากและยิ่งใหญ่ที่มีส่วนที่เคลื่อนไหวได้มากกว่าการเขียน SQL ใหม่บางส่วน
— Jeff Meatball Yang
7
ไม่ใช่ประเด็นเทียบกับ SQL แต่เป็นจุดสำหรับเลเยอร์นามธรรม เช่นเดียวกับคุณไม่สามารถรวบรวม + เรียกใช้รหัส C เดียวกันได้ทุกที่ แต่เป็นประเด็นสำหรับภาษาที่ไม่แยแสแพลตฟอร์มอื่น ๆ แต่มันไม่ได้ทำให้ SQL หรือ C เป็น "อึ": เลเยอร์ที่เป็นนามธรรมจะทำงานด้านบนสุดของเลเยอร์ที่ลึกกว่า
— Joonas Pulakka
8
@ เจฟฟ์: ใน C งานทั่วไปเป็นส่วนหนึ่งของมาตรฐาน ใน SQL เป็นไปไม่ได้ที่จะแบ่งหน้าชุดผลลัพธ์โดยไม่เข้าสู่ SQL เฉพาะผู้ขาย
— Powerlord
4
โอ้และเกี่ยวกับความหายากของการสลับผู้ขายฐานข้อมูล: คุณกำลังพูดถึงอะไร? ความหายากของ บริษัท ที่เปลี่ยนระบบปฏิบัติการทำให้โซลูชันข้ามแพลตฟอร์มไม่เกี่ยวข้องหรือไม่? คุณไม่ทราบมาก่อนเสมอว่าผลิตภัณฑ์ของคุณกำลังจะถูกใช้งานดังนั้นจึงเป็นการดีกว่าที่จะทำผิดพลาดกับโซลูชันทั่วไป
— Joonas Pulakka
3
@Joonas: ฉันเดาว่าฉันตั้งใจจะบอกว่าภาษา SQL นั้นไม่ใช่ปัญหา - คำถามถามว่าอะไรทำให้ SQL แย่มากและปฏิกิริยาเริ่มต้นของฉันก็เหมือนกับของคุณคือมันไม่ใช่ แต่ฉันอยากจะเถียงว่าการรองรับภาษาถิ่นที่แตกต่างกันนั้นไม่ใช่ประเด็นของ ORM จริงๆ - เรามีให้แม้ว่าเราจะมีภาษามาตรฐานเพียงภาษาเดียวก็ตาม - ฉันคิดว่ามันมากกว่านั้นที่เราต้องการวิธีแก้ไขข้อมูลที่เป็นมาตรฐานให้เป็นแบบจำลอง OO
— Jeff Meatball Yang
36

SQL ได้รับ badmouthed จากหลายแหล่ง:

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

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

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

หากพวกเขาจริงจังกับการวิพากษ์วิจารณ์ SQL พวกเขาก็จะกลับมาใช้ความพยายามเช่น Tutorial D และ Dataphor

— Steven Huwig
แหล่งที่มา
7
เกี่ยวกับประเด็นแรกเกี่ยวกับโปรแกรมเมอร์ที่ไม่พอใจกับอะไรเลยนอกจากภาษาที่จำเป็น มันจะน่าสนใจในอีกไม่กี่ปีข้างหน้าเพื่อดูว่าการกลับมาของการเขียนโปรแกรมเชิงฟังก์ชันทำให้เกิดความแตกต่างหรือไม่ ในขณะนี้มีการโฆษณามากกว่าภาษาเช่น Haskell, F # และ Scala ทำให้นักพัฒนามีประสิทธิผลมากขึ้น การคิดแบบ "คณิตศาสตร์" สำหรับโปรแกรมเมอร์นี้มีความคล้ายคลึงกับความรู้เกี่ยวกับพีชคณิตเชิงสัมพันธ์และแคลคูลัสเชิงสัมพันธ์ทูเพิลที่ SQL กำหนดไว้ล่วงหน้า อาจจะมีการฟื้นตัวของการคิดตามชุด SQL ดั้งเดิมในเวลา!
— Trevor Tippins
ฉันควรชี้แจงว่าฉันหมายถึง "โปรแกรมเมอร์เหล่านั้นไม่พอใจกับอะไรเลยนอกจากการเขียนโปรแกรมที่จำเป็น" ไม่ใช่ว่าโปรแกรมเมอร์ทุกคนไม่สบายใจกับมัน
— Steven Huwig
+1 กล่าวได้ดี และในฐานะคนที่ใช้เวลาสองสามปีแรกในฐานะนักเขียนโค้ดมืออาชีพในฐานข้อมูลก่อนสัมพันธ์ฉันพบว่ามันน่าทึ่งตรงที่ใคร ๆ ก็อยากกลับไปยุคนั้นยกเว้นงานเฉพาะทาง วันที่ใช้ในการเขียนโค้ดข้ามโครงสร้างต้นไม้ DL / 1 น่าจะเพียงพอที่จะโน้มน้าวใจใครก็ได้
— Cruachan
ปัญหาคือมีโปรแกรมเมอร์ที่ถูกบังคับหลายคนซึ่งอยากจะหาโค้ดที่ไม่น่าเชื่อถือสักสองสามร้อยบรรทัดแทนที่จะคิดถึงสิ่งต่าง ๆ เป็นเวลาประมาณหนึ่งชั่วโมง
— Steven Huwig
คุณไม่ควรคิดเรื่องต่างๆเป็นเวลาหนึ่งชั่วโมงเพื่อเขียนหรือทำความเข้าใจโค้ดสองสามบรรทัด ระยะเวลา
— Andrew
23

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

— Trevor Tippins
แหล่งที่มา
16

SQL ได้รับการออกแบบมาสำหรับการจัดการและการสืบค้นข้อมูลจาก SET มักใช้ในการทำมากขึ้นและกรณีที่มีขอบทำให้เกิดความยุ่งยากในบางครั้ง

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

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

— Mark Schultheiss
แหล่งที่มา
11

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

SQL ได้รับการออกแบบมาสำหรับพีชคณิตเชิงสัมพันธ์ซึ่งเป็นสิ่งที่ควรใช้

— Nikolay R
แหล่งที่มา
2
สิ่งที่น่าเสียดายคือมันเป็นเรื่องที่น่าดึงดูดมากที่จะติดรหัสขั้นตอนง่ายๆลงในขั้นตอนการจัดเก็บ และใช้งานได้ดี จนกว่าจะมีใครบางคนต้องการรักษา / เพิ่มข้อยกเว้นบางอย่าง ฯลฯ ...
— Brian Knoblauch
5
-1 ผิดพลาดตรงประเด็น SQL ได้รับการออกแบบให้ตั้งตามและนั่นคือพลังของมัน การคิดตามขั้นตอนหมายความว่าคุณกำลังคิดผิด
— Cruachan
1
ไขควงตัวนี้ห่วย! มันยากมากที่จะทำเล็บด้วยมัน
— Casey Rodarmor
9

เมื่อเร็ว ๆ นี้ฉันได้ยินมามากแล้วว่า SQL เป็นภาษาที่แย่มากและดูเหมือนว่าทุกเฟรมเวิร์กภายใต้ดวงอาทิตย์จะมาพร้อมกับเลเยอร์นามธรรมของฐานข้อมูล

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

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

…เหตุผลที่ฉันเพิ่งอธิบายไปข้างต้น

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

SQLตามคำนิยามมีอะไรในชั้นฐานข้อมูลที่ไม่ได้อยู่ใน

อะไรทำให้SQLแย่มากและทำไมเลเยอร์นามธรรมของฐานข้อมูลจึงมีค่า

SQL เป็นภาษาที่ดี แต่ต้องใช้สมองในการทำงานกับมัน

ในทางทฤษฎีSQLมีการประกาศนั่นคือคุณประกาศสิ่งที่คุณต้องการได้รับและเครื่องยนต์จัดเตรียมให้เร็วที่สุดเท่าที่จะเป็นไปได้

ในทางปฏิบัติมีหลายวิธีในการกำหนดแบบสอบถามที่ถูกต้อง (นั่นคือแบบสอบถามที่ให้ผลลัพธ์ที่ถูกต้อง)

เครื่องมือเพิ่มประสิทธิภาพสามารถสร้างปราสาทเลโก้โดยใช้อัลกอริทึมที่กำหนดไว้ล่วงหน้า (ใช่มันมีหลายอย่าง) แต่ไม่สามารถสร้างอัลกอริทึมใหม่ได้ ยังต้องใช้SQLนักพัฒนาในการช่วยเหลือพวกเขา

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

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

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

จะเป็นการดีหากผู้ขายให้การเข้าถึงฟังก์ชันระดับต่ำบางอย่างเช่น "รับช่วงดัชนี" "รับแถวโดยrowid" ฯลฯ เช่นเดียวกับCคอมไพเลอร์ให้คุณฝังแอสเซมบลีลงในภาษาได้ทันที

เมื่อเร็ว ๆ นี้ฉันเขียนบทความเกี่ยวกับเรื่องนี้ในบล็อกของฉัน:

— Quassnoi
แหล่งที่มา
7

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

ฉันมองว่า SQL เป็นภาษาที่มีประสิทธิภาพสูงซึ่งไม่มีการใช้โค้ดซ้ำหรือการบำรุงรักษา / การปรับโครงสร้างเป็นลำดับความสำคัญ

การประมวลผลที่รวดเร็วปานสายฟ้าแลบจึงเป็นสิ่งสำคัญ และเป็นที่ยอมรับ คุณเพียงแค่ต้องระวังการแลกเปลี่ยนซึ่งสำหรับฉันเป็นเรื่องสำคัญ

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

— Brian MacKay
แหล่งที่มา
7

ฉันจะบอกว่าเลเยอร์นามธรรมของฐานข้อมูลที่มาพร้อมกับเฟรมเวิร์กเป็นสิ่งที่ดีเพราะมันช่วยแก้ปัญหาที่สำคัญสองอย่าง:

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

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

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

— Dereleased
แหล่งที่มา
6

SQL นั้นยอดเยี่ยมสำหรับงานบางประเภทโดยเฉพาะอย่างยิ่งการจัดการและการดึงชุดข้อมูล

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

  • Encapsulation : กลไกการห่อหุ้มของ SQL นั้นหยาบ เมื่อคุณเขียนโค้ด SQL คุณต้องรู้ทุกอย่างเกี่ยวกับการนำข้อมูลของคุณไปใช้ สิ่งนี้จะ จำกัด จำนวนนามธรรมที่คุณสามารถทำได้

  • Polymorphism : หากคุณต้องการดำเนินการแบบเดียวกันบนตารางต่างๆคุณจะต้องเขียนโค้ดสองครั้ง (เราสามารถบรรเทาสิ่งนี้ได้ด้วยการใช้มุมมองเชิงจินตนาการ)

  • การควบคุมการมองเห็น : ไม่มีกลไก SQL มาตรฐานในการซ่อนชิ้นส่วนของโค้ดจากกันและกันหรือจัดกลุ่มเป็นหน่วยตรรกะดังนั้นทุกตารางขั้นตอนและอื่น ๆ จึงสามารถเข้าถึงได้จากทุกตารางแม้ว่าจะไม่เป็นที่ต้องการก็ตาม

  • ModularityและVersioning

ในที่สุดการเข้ารหัสการดำเนินการ CRUD ด้วยตนเองใน SQL (และการเขียนโค้ดเพื่อเชื่อมต่อกับแอปพลิเคชันอื่น ๆ ) นั้นซ้ำซากและเกิดข้อผิดพลาดได้ง่าย

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

— Jeff Sternal
แหล่งที่มา
สคีมาสำหรับการควบคุมการมองเห็นเป็นอย่างไร
— Three Value Logic
5

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

แน่นอนว่าบางครั้งสำหรับสิ่งที่ซับซ้อน SQL นั้นใช้งานง่ายกว่าและมีประสิทธิภาพมากกว่าดังนั้นจึงเป็นการดีที่จะจัดการกับเทคโนโลยีทั้งสองประเภท

— ปีเตอร์เบลีย์
แหล่งที่มา
5

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

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

— โทมัส
แหล่งที่มา
4

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

— tvanfosson
แหล่งที่มา
2
จริง แต่คุณไม่จำเป็นต้องมี ORM สำหรับสิ่งนี้
— finnw
2
การใช้การสืบค้นแบบ parametrized เป็นเรื่องเล็กน้อยเมื่อเขียน SQL โดยตรงหากคุณมีเลเยอร์อินเทอร์เฟซฐานข้อมูลที่เหมาะสม (เช่นที่รองรับตัวยึดตำแหน่ง) $dbh->do("DELETE FROM my_table WHERE some_value = ?", undef, $target_value); ที่นั่น เสร็จสิ้น
— Dave Sherohman
ฉันไม่เคยบอกว่าคุณไม่สามารถเขียนแบบสอบถามที่กำหนดพารามิเตอร์ด้วย RAW SQL ฉันบอกว่าการใช้ SQL ดิบมีความเสี่ยงมากกว่าเนื่องจากคุณต้องติดตั้งด้วยตัวเอง ฉันเคยเห็นหลายกรณีของรหัส SQL ดิบที่แบบสอบถามไม่ได้กำหนดพารามิเตอร์ ORM ให้สิทธิประโยชน์นี้โดยอัตโนมัติ
— tvanfosson
2
จริงอยู่ แต่การหลีกเลี่ยงการฉีด SQL นั้นง่ายมากแม้จะไม่ได้เตรียมงบ ทุกโครงการที่ฉันทำฉันเขียนฟังก์ชันง่ายๆที่ใส่เครื่องหมายคำพูดรอบสตริงและหลีกเลี่ยงเครื่องหมายคำพูดที่ฝังไว้อย่างถูกต้อง ใช้เวลาเขียนประมาณสิบห้านาทีแม้ว่าฉันจะไม่ได้คัดลอกมาจากโปรเจ็กต์ก่อนหน้าก็ตาม จากนั้นฉันจะใช้มันสำหรับทุกตัวอักษรที่ฉันฝังในแบบสอบถาม สิ่งที่ทำให้มึนงงสำหรับฉันคือโปรแกรมเมอร์ไม่ทำสิ่งนี้! อย่าใช้เวลาสิบห้านาทีเพื่อหลีกเลี่ยงการจงใจหรือ - อาจเป็นเรื่องธรรมดามากขึ้น - การฉีด SQL โดยบังเอิญ! ทำไมจะไม่ล่ะ?!
— เจ
3
Jay "ฟังก์ชั่นง่ายๆที่ใส่เครื่องหมายคำพูดรอบสตริงและหลีกเลี่ยงเครื่องหมายคำพูดที่ฝังไว้อย่างเหมาะสม" โดยคำนึงถึงชุดอักขระปัจจุบันที่ใช้บนเซิร์ฟเวอร์หรือไม่
— ygrek
4

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

ธุรกิจเลเยอร์นามธรรมเป็นเพียงการแยกแยะความแตกต่างระหว่าง Object Oriented code และ Table - Set based code เช่น SQL ชอบคุยกัน โดยปกติจะส่งผลให้มีการเขียนแผ่นหม้อไอน้ำจำนวนมากและรหัสการเปลี่ยนแปลงที่น่าเบื่อระหว่างทั้งสอง ORM ทำสิ่งนี้โดยอัตโนมัติและช่วยประหยัดเวลาสำหรับผู้ที่ไม่พอใจทางธุรกิจ

— Quibblesome
แหล่งที่มา
4

สำหรับโปรแกรมเมอร์ SQL ที่มีประสบการณ์ด้านที่ไม่ดีคือ

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

สำหรับคนอื่น ๆ เหตุผลก็คือ

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

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

[อัพเดตเมื่อวันที่ 26.06.10] เร็ว ๆ นี้ผมทำงานร่วมกับโมดูล Django ออม นี่เป็นเพียงกรอบงาน SQL ที่คุ้มค่าที่ฉันเคยเห็น และสิ่งนี้ทำให้การทำงานกับสิ่งต่างๆมากมาย การรวมที่ซับซ้อนนั้นยากกว่าเล็กน้อย

— culebrón
แหล่งที่มา
3

SQL ไม่ใช่ภาษาที่แย่มาก แต่ก็เล่นได้ไม่ดีกับคนอื่น ๆ ในบางครั้ง

ตัวอย่างเช่นหากคุณมีระบบที่ต้องการแสดงเอนทิตีทั้งหมดเป็นอ็อบเจ็กต์ในภาษา OO หรือภาษาอื่นการรวมสิ่งนี้กับ SQL โดยไม่มีเลเยอร์นามธรรมใด ๆ อาจเป็นเรื่องยุ่งยาก ไม่มีวิธีง่ายๆในการแมปแบบสอบถาม SQL ที่ซับซ้อนเข้ากับ OO-world เพื่อลดความตึงเครียดระหว่างโลกเหล่านั้นจะมีการแทรกชั้นนามธรรมเพิ่มเติม (ตัวอย่างเช่น OR-Mapper)

— โจอาคิมซาวเออร์
แหล่งที่มา
เหตุใด SQL จึงเป็นความผิดพลาดที่ภาษา OO ไม่ได้แมปกับมัน เมื่อคุณใช้บริการให้ปฏิบัติตามอินเทอร์เฟซหรือไม่ใช้บริการ
— กม ธ .
2
ไม่มีใครบอกว่าเป็นความผิดพลาดของ SQL ภาษากลางของ DB-access คือ SQL ภาษากลางของตรรกะทางธุรกิจเป็นภาษาที่ใช้ OO สองคนนั้นไม่เข้ากันอย่างสมบูรณ์แบบหากปราศจากความช่วยเหลือ ไม่มี "ข้อบกพร่อง" หรือ "ปัญหา" ที่นี่มีเพียงข้อกำหนดบางอย่าง ("ทำให้ตรงกัน") และวิธีแก้ปัญหาที่ได้รับการยอมรับอย่างกว้างขวาง ("ใช้ OR-Mapper")
— Joachim Sauer
Joachim Sauer กล่าวว่าSQL ไม่ใช่ภาษาที่แย่ แต่ก็เล่นได้ไม่ดีกับคนอื่น สำหรับฉันดูเหมือนว่ามีคนบอกว่าเป็นความผิดพลาดของ SQL
— KM
1
@KM: คุณบอกว่าภาษาฝรั่งเศสและภาษาเยอรมันเป็นภาษาที่ไม่ดีหรือไม่? พวกเขาเล่นภาษาอังกฤษได้ไม่ดีเลย
— David Thornley
3

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

อีกสาเหตุหนึ่งที่ SQL ถูกเกลียดเป็นเพราะฐานข้อมูลเชิงสัมพันธ์

CAPทฤษฎีบทกลายเป็นที่นิยม:

คุณต้องการเป้าหมายอะไรจากระบบข้อมูลที่ใช้ร่วมกัน

  • ความสม่ำเสมอที่แข็งแกร่ง: ลูกค้าทั้งหมดเห็นมุมมองเดียวกันแม้จะมีการอัปเดต
  • ความพร้อมใช้งานสูง: ลูกค้าทั้งหมดสามารถค้นหาข้อมูลจำลองได้แม้ในกรณีที่เกิดความล้มเหลว
  • Partition-tolerance: คุณสมบัติของระบบจะคงไว้แม้ว่าระบบจะถูกแบ่งพาร์ติชันก็ตาม

ทฤษฎีบทระบุว่าคุณสามารถมีคุณสมบัติ CAP เพียงสองในสามคุณสมบัติพร้อมกันได้เสมอ

ที่อยู่ฐานข้อมูลเชิงสัมพันธ์ความสม่ำเสมอที่แข็งแกร่งและความอดทนของพาร์ติชัน

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

หากฐานข้อมูลเชิงสัมพันธ์ถูกปฏิเสธ SQL จะถูกปฏิเสธด้วย

— Nicolas Dorier
แหล่งที่มา
3

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

ทฤษฎีของฉันคือ SQL ถูกคิดค้นโดยกลุ่มนักเล่นสกีสีน้ำเงินหอคอยงาช้าง โครงสร้างที่ไม่ใช่ขั้นตอนทั้งหมด ฟังดูดี: บอกฉันว่าคุณต้องการอะไรมากกว่าที่คุณต้องการจะทำอย่างไร แต่ในทางปฏิบัติมักจะง่ายกว่าเพียงแค่ให้ขั้นตอน บ่อยครั้งสิ่งนี้ดูเหมือนพยายามให้คำแนะนำในการบำรุงรักษารถยนต์โดยอธิบายว่ารถควรทำงานอย่างไรเมื่อคุณทำเสร็จแล้ว ใช่คุณสามารถพูดได้ว่า "ฉันต้องการให้รถคันนี้ได้รับ 30 ไมล์ต่อแกลลอนอีกครั้งและวิ่งด้วยเสียงฮัมเพลงแบบนี้ ... อืมม ... และ ฯลฯ " แต่มันจะไม่ง่ายกว่าสำหรับทุกคน แค่พูดว่า "เปลี่ยนหัวเทียนใหม่"? และแม้ว่าคุณจะหาวิธีแสดงข้อความค้นหาที่ซับซ้อนในรูปแบบที่ไม่ใช่ขั้นตอนได้ แต่เครื่องมือฐานข้อมูลก็มักจะมีแผนการดำเนินการที่ไม่มีประสิทธิภาพมากเพื่อไปที่นั่น

และการจัดการโมฆะทำให้ฉันแทบคลั่ง! ใช่ในทางทฤษฎีแล้วมันต้องฟังดูดีมากเมื่อมีคนพูดว่า "เฮ้ถ้าโมฆะหมายถึงไม่ทราบดังนั้นการเพิ่มค่าที่ไม่รู้จักให้กับค่าที่ทราบควรให้ค่าที่ไม่รู้จักท้ายที่สุดตามนิยามแล้วเราไม่รู้ว่าค่าที่ไม่รู้จักคืออะไร ." ในทางทฤษฎีเป็นความจริงอย่างแน่นอน ในทางปฏิบัติหากเรามีลูกค้า 10,000 รายและเรารู้แน่ชัดว่าเงิน 9,999 เป็นหนี้เราอยู่เท่าไหร่ แต่มีคำถามบางอย่างเกี่ยวกับจำนวนเงินที่ค้างชำระและผู้บริหารกล่าวว่า "บัญชีลูกหนี้ทั้งหมดของเราคืออะไร" ใช่ถูกต้องตามหลักคณิตศาสตร์ คำตอบคือ "ฉันไม่รู้" แต่คำตอบที่ใช้ได้จริงคือ "เราคำนวณ $ 4,327,287.42 แต่มีบัญชีหนึ่งที่เป็นปัญหาดังนั้นตัวเลขจึงไม่แน่นอน" ฉันแน่ใจว่าฝ่ายบริหารค่อนข้างจะเข้าใกล้ถ้าไม่ใช่ตัวเลขที่แน่นอนมากกว่าการจ้องมองที่ว่างเปล่า

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

— คนโง่
แหล่งที่มา
3
แนวคิดฐานข้อมูลเชิงสัมพันธ์ทั้งหมดเป็นผลมาจากหอคอยงาช้างสีฟ้า ฐานข้อมูลเชิงสัมพันธ์ในช่วงต้นมีประสิทธิภาพที่น่ากลัวเมื่อเทียบกับฐานข้อมูลแบบลำดับชั้นในปัจจุบันและใช้เวลานานในการสร้าง พลังของสิ่งที่เป็นนามธรรมนั้นทำให้ฐานข้อมูลลำดับชั้นเป็นสิ่งที่ผ่านมาแล้ว (ไม่ใช่ว่ายังไม่มีฐานข้อมูล IMS และ CODASYL อยู่) มันต้องได้ผลดีมาก
— David Thornley
1
แต่ฝ่ายบริหารจะไม่เห็นตัวเลข "ปิดถ้าไม่ใช่จำนวนที่แน่นอน" - พวกเขาจะเห็นตัวเลขผิด บางทีลูกค้าขั้นสุดท้ายนั้นอาจเป็นหนี้เงินจำนวนมาก จากนั้นผู้บริหารจะไม่พอใจมากเกี่ยวกับตัวเลขที่ไม่ถูกต้อง
— HTTP 410
RoadWarrior: ใช่เป็นไปได้ว่าคุณมีลูกค้า 10,000 รายซึ่งแต่ละรายเป็นหนี้คุณ 10 เหรียญและลูกค้า 1 รายที่เป็นหนี้คุณ 10 ล้านเหรียญ แต่ถ้าเป็นเช่นนั้นใครก็ตามที่ขอรายงาน AR น่าจะรู้จักชื่อลูกค้าคนนั้นเป็นอย่างดีและรู้ดีว่าเกิดอะไรขึ้นกับพวกเขา โอเคฉันแน่ใจว่ามีบางครั้งที่ไม่มีคำตอบใดดีไปกว่าคำตอบที่ไม่น่าเชื่อถือจนไร้ความหมาย แต่นั่นคือประเด็นของฉัน: SQL ได้รับการออกแบบโดยคำนึงถึงทฤษฎีเช่นนั้นนั่นคือการดันทุรัง "อะไรที่น้อยกว่าความสมบูรณ์แบบก็ไร้ค่า" ...
— Jay
... ในชีวิตจริง 95% ของเวลาคำตอบโดยประมาณดีกว่าการจ้องมองเปล่า ๆ เมื่อฉันดูสมุดเช็คของฉันฉันรู้ว่ามีความเป็นไปได้ค่อนข้างมากที่ฉันทำเลขคณิตผิดพลาดหรือลืมเขียนในเช็ค ยอดคงเหลืออาจเป็นค่าประมาณ แต่ถึงกระนั้นถ้าฉันรู้ว่าฉันมี "ประมาณ 1,000 ดอลลาร์" ฉันจะไม่มีความมั่นใจในการเขียนเช็คในราคา $ 50 และฉันจะรู้ว่าการเขียนเช็คในราคา 10,000 ดอลลาร์จะไร้ผล
— เจ
ฉันดำเนินธุรกิจและไม่เคย 10K เทียบกับ 1 IMX มันคล้ายกับ 20 ที่ไม่รู้จักสำหรับทุกๆ 100 คนที่รู้จัก (หลักการพาเรโต) และบางคนใน 20 คนนั้นเป็นหนี้เราเป็นเงินจำนวนมากซึ่งเป็นสาเหตุที่ทำให้จำนวนเงินที่แท้จริงขัดแย้งกัน อีกครั้งนี่คือหลักการพาเรโต
— HTTP 410
3

•ผู้ขายทุกรายขยายไวยากรณ์ SQL เพื่อให้เหมาะกับความต้องการของตน ดังนั้นถ้าคุณไม่ทำสิ่งที่ค่อนข้างง่ายโค้ด SQL ของคุณจะไม่สามารถพกพาได้

•ไวยากรณ์ของ SQL ไม่ได้ตั้งฉากกัน เช่นselect, insert, update,และdeleteข้อความทั้งหมดมีโครงสร้างทางเทคนิคที่แตกต่างกันอย่างสิ้นเชิง

— David R Tribble
แหล่งที่มา
1
มันทำให้ไวยากรณ์ไม่ตั้งฉากได้อย่างไร?
— Amok
1
ภาษาอาจได้รับการออกแบบเพื่อให้ข้อความที่จำเป็นทั้งหมดเหล่านี้มีไวยากรณ์ที่ใช้กันทั่วไปมากขึ้นโดยเฉพาะระหว่างinsertและupdateการดำเนินการซึ่งมีความหมายเหมือนกันเกือบทั้งหมด แต่มีความแตกต่างกันทางวากยสัมพันธ์อย่างสิ้นเชิง
— David R Tribble
2

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

— MusiGenesis
แหล่งที่มา
2
ฉันไม่เข้าใจว่าความเข้ากันไม่ได้ของภาษาถิ่นของ SQL สามารถเป็น "จุด" ขนาดใหญ่เมื่อเทียบกับ SQL ได้อย่างไร เหมือนกับการบอกว่า C เป็นเรื่องไร้สาระเพราะคุณไม่สามารถคอมไพล์ + รันซอร์สเดียวกันใน Linux distros ที่แตกต่างกันได้
— Jeff Meatball Yang
1
@ เจฟฟ์: ฉันไม่คิดว่ามันจะเป็นประเด็นใหญ่เมื่อเทียบกับ SQL จริงๆแล้ว นั่นเป็นเหตุผลที่ฉันพูดว่า "ฉันเห็นด้วยกับคะแนนของคุณ" และใส่เครื่องหมายคำพูด "แย่มาก" ฉันชอบ SQL มากกว่าชั้นข้อมูลนามธรรมตัวเองถึงแม้ว่าฉันสิ่งที่ดีใจเหมือน NHibernate อยู่เพราะพวกเขากำลังมากดีกว่าอึบ้านที่ปลูกที่ใช้แพร่หลาย
— MusiGenesis
1
จริง - ฉันใช้เลเยอร์นามธรรมด้วย - ฉันเดาว่าฉันตั้งใจจะบอกว่าสำหรับฉันภาษา SQL ไม่ใช่ปัญหา - เป็นการแปลงข้อมูลที่ทำให้เป็นมาตรฐานเป็นวัตถุซึ่งเป็นเหตุผลว่าทำไมเลเยอร์นามธรรมจึงมีประโยชน์
— Jeff Meatball Yang
2

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

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

— ovolko
แหล่งที่มา
การจัดการกับอินสแตนซ์ของวัตถุในหน่วยความจำนั้นค่อนข้างแตกต่างจากข้อมูลที่เก็บไว้ในฐานข้อมูล มีความเจ็บปวดมากขึ้นในการแก้ไขการออกแบบที่ไม่ดีและอาจมีรูปแบบที่แตกต่างกันมากในประสิทธิภาพโดยอิงจาก "สิ่งเล็กน้อย"
— KM
2

หากคุณไม่ได้ใช้ SQL มากเกินไปฉันคิดว่าปัญหาใหญ่คือการขาดเครื่องมือสำหรับนักพัฒนาที่ดี

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

— เจฟลูกชิ้นยาง
แหล่งที่มา
2

ด่วนเขียน SQL ให้ฉันเพื่อแบ่งหน้าชุดข้อมูลที่ทำงานใน MySQL, Oracle, MSSQL, PostgreSQL และ DB2

โอ้ใช่แล้ว SQL มาตรฐานไม่ได้กำหนดตัวดำเนินการใด ๆ เพื่อ จำกัด จำนวนผลลัพธ์ที่กลับมาและแถวที่จะเริ่มต้นที่

— Powerlord
แหล่งที่มา
5
เหตุใดคุณจึงพยายามกำหนดเป้าหมายสภาพแวดล้อมเหล่านั้นทั้งหมดด้วยรหัสของคุณ เขียนรหัส C สำหรับเธรดที่ทำงานใน Mac OS 9, Windows NT, OS / 2 Warp และ Solaris
— Steven Huwig
2
@Steven Huwig: ฉันอาจจะใช้เลเยอร์นามธรรมเพื่อทำเพื่อฉัน ... ซึ่งเป็นสิ่งที่คำถามถาม
— Powerlord
@Steven: ฉันบังเอิญใช้เฟรมเวิร์กและเลเยอร์นามธรรมสำหรับบางสิ่งที่ฉันต้องเป็นอิสระจากแพลตฟอร์ม อย่างไรก็ตามความเป็นอิสระของฐานข้อมูลมีความสำคัญมากกว่าในกรณีส่วนใหญ่ แม้ว่าคุณจะส่งมอบซอฟต์แวร์ของคุณเพื่อทำงานบน Windows เท่านั้น แต่เมื่อคุณขายให้กับ บริษัท ใหญ่ ๆ แล้วคุณจะพบกับทุกสิ่งตั้งแต่ "เราชอบ OSS คุณสนับสนุน MySQL" ไปจนถึง "เราใช้ Oracle | MSSQL | อะไรก็ตาม มาตรฐานองค์กรคุณสนับสนุนหรือไม่ ".
— Fredrik
2

ไม่มีความรักสำหรับ SQL เนื่องจาก SQL ไม่ดีในด้านไวยากรณ์ความหมายและการใช้งานในปัจจุบัน ฉันจะอธิบาย:

  • ไวยากรณ์ของมันคือเศษกระสุนโคบอลคำวิจารณ์ของโคโบลทั้งหมดใช้ที่นี่ (ในระดับที่น้อยกว่าเพื่อความยุติธรรม) การพยายามเป็นภาษาที่เป็นธรรมชาติโดยไม่ต้องพยายามตีความภาษาธรรมชาติจะสร้างไวยากรณ์ตามอำเภอใจ (เป็น DROP TABLE หรือ DROP, UPDATE TABLE, UPDATE หรือ UPDATE IN, DELETE หรือ DELETE FROM ... ) มันเติม?)
  • ความหมายยังมีข้อบกพร่องอย่างลึกซึ้ง Date อธิบายรายละเอียดได้มาก แต่ก็เพียงพอแล้วที่จะสังเกตว่าตรรกะบูลีนที่มีค่าสามค่าไม่พอดีกับพีชคณิตเชิงสัมพันธ์โดยที่แถวสามารถเป็นหรือไม่เป็นส่วนหนึ่งของตารางเท่านั้น
  • การมีภาษาการเขียนโปรแกรมเป็นอินเทอร์เฟซหลัก (และมักจะเท่านั้น) ไปยังฐานข้อมูลได้รับการพิสูจน์แล้วว่าเป็นทางเลือกที่ไม่ดีจริงๆและได้สร้างข้อบกพร่องด้านความปลอดภัยประเภทใหม่
— stupito
แหล่งที่มา
1

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

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

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

ปัญหาใหญ่ที่สุดที่ฉันมีกับ SQL ก็เหมือนกับภาษา "มาตรฐาน" อื่น ๆ มีมาตรฐานจริงน้อยมาก ฉันเกือบจะอยากเรียนภาษาใหม่ระหว่าง Sybase และ MySQL เพื่อที่ฉันจะได้ไม่สับสนทั้งสองแบบ

— NateDSaint
แหล่งที่มา
คุณสามารถช่วยตัวเองจากความเจ็บปวดนั้นได้โดยไม่ต้องใช้ MySQL ;)
— Steven Huwig
1

แม้ว่า SQL จะทำให้งานสำเร็จ แต่ก็มีปัญหาอย่างแน่นอน ...

  • ก็พยายามที่จะไปพร้อม ๆ กันเป็นระดับสูงและระดับต่ำที่เป็นนามธรรมและที่ ...แปลก บางทีมันควรจะเป็นสองมาตรฐานขึ้นไปในระดับที่แตกต่างกัน
  • มันเป็นความล้มเหลวอย่างมากตามมาตรฐานมันคือความล้มเหลวขนาดใหญ่เป็นมาตรฐานมีหลายสิ่งผิดพลาดเมื่อมาตรฐานใด ๆ ทำให้เกิดการเปลี่ยนแปลงในทุกสิ่งขอให้นำไปใช้งานมากเกินไปถามน้อยเกินไปหรือด้วยเหตุผลบางประการไม่บรรลุเป้าหมายทางสังคมบางส่วนในการจูงใจให้ผู้ขายและผู้ปฏิบัติงานสร้างการใช้งานร่วมกันที่สอดคล้องกันอย่างเคร่งครัด คุณไม่สามารถพูดได้อย่างแน่นอนว่า SQL ได้ทำสิ่งนั้นแล้ว ดูมาตรฐานอื่น ๆ และสังเกตว่าความสำเร็จหรือความล้มเหลวของมาตรฐานเป็นปัจจัยของความร่วมมือที่เป็นประโยชน์อย่างชัดเจน:
    • RS-232 ( ไม่ดีไม่ระบุไว้เกือบเพียงพอแม้ว่าพินใดที่ส่งและพินใดที่ได้รับก็เป็นทางเลือกเธอสามารถปฏิบัติตามได้ แต่ก็ยังไม่บรรลุผลใด ๆ โอกาสในการทำงานร่วมกันที่ประสบความสำเร็จ: ต่ำมากจนกระทั่ง IBM PC สร้างมาตรฐานที่มีประโยชน์โดยพฤตินัย .)
    • จุดลอยตัว IEEE 754-1985 ( ไม่ดีเกินเอื้อม: ไม่ใช่ซูเปอร์คอมพิวเตอร์หรือเวิร์กสเตชันทางวิทยาศาสตร์หรือไมโครโปรเซสเซอร์ RISC ตัวเดียวที่เคยนำมาใช้แม้ว่าในที่สุดหลังจาก 20 ปีเราก็สามารถใช้งานได้อย่างดีใน HW อย่างน้อยที่สุดโลกก็เติบโตขึ้นในที่สุด)
    • C89, C99, PCI, USB, Java ( ดีไม่ว่าจะเป็นมาตรฐานหรือข้อมูลจำเพาะพวกเขาประสบความสำเร็จในการกระตุ้นให้เกิดการปฏิบัติตามกฎระเบียบอย่างเคร่งครัดจากเกือบทุกคนและการปฏิบัติตามข้อกำหนดนั้นส่งผลให้การทำงานร่วมกันประสบความสำเร็จ)
  • มันจะไม่ถูกเลือกสำหรับ arguably ฐานข้อมูลที่มีความสำคัญมากที่สุดในโลก แม้ว่านี่จะเป็นจุดข้อมูลมากกว่าเหตุผล แต่ความจริงที่ว่า Google Bigtable ไม่ใช่ SQL และการไม่สัมพันธ์กันก็เป็นการต่อต้านความสำเร็จของ SQL
— DigitalRoss
แหล่งที่มา
0

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

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

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

— โจเซฟเฟอร์ริส
แหล่งที่มา
1
Downvoter - สนใจที่จะอธิบายว่าทำไมหรือเพียงแค่คลิกปุ่มลงสำหรับทุกสิ่งที่คุณไม่เห็นด้วย?
— Joseph Ferris
0

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

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

— Adriaan
แหล่งที่มา
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.