โดเมนขับเคลื่อนการออกแบบรูปแบบต่อต้าน SQL หรือไม่

ฉันกำลังดำน้ำในการออกแบบที่ขับเคลื่อนด้วยโดเมน (DDD) และในขณะที่ฉันไปลึกมากขึ้นในนั้นมีบางสิ่งที่ฉันไม่ได้รับ ตามที่ฉันเข้าใจแล้วประเด็นหลักคือการแยก Domain Logic (Business Logic) จาก Infrastructure (DB, File System ฯลฯ )

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

การคำนวณเหล่านี้ในโครงสร้างพื้นฐานไม่สามารถเกิดขึ้นได้เช่นกันเพราะรูปแบบ DDD ช่วยให้สามารถเปลี่ยนแปลงโครงสร้างพื้นฐานได้โดยไม่ต้องเปลี่ยน Domain Layer และรู้ว่า MongoDB ไม่มีความสามารถเช่น SQL Server ที่ไม่สามารถเกิดขึ้นได้

นั่นเป็นข้อผิดพลาดของรูปแบบ DDD หรือไม่?

วันนี้คุณมีแนวโน้มที่จะเห็นการอ่าน (คิวรี) จัดการแตกต่างจากการเขียน (คำสั่ง) ในระบบที่มีคิวรีที่ซับซ้อนตัวเคียวรีไม่น่าจะผ่านโมเดลโดเมน (ซึ่งส่วนใหญ่รับผิดชอบในการรักษาความสอดคล้องของการเขียน )

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

ตามที่ฉันเข้าใจแล้วประเด็นหลักคือการแยก Domain Logic (Business Logic) จาก Infrastructure (DB, File System ฯลฯ )

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

อย่าคิดว่า "อยู่ใน SQL" เป็นสิ่งกีดขวาง BL / DL นั่นไม่ใช่สิ่งที่มันเป็น ให้คิดว่า "นี่เป็นจุดสิ้นสุดของโดเมนภายใน" แทนสิ่งกีดขวาง

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

พิจารณาตัวอย่างของคุณ:

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

ตรงนี้เป็นสิ่งที่ควรอยู่ใน SQL และไม่ใช่การละเมิด DDD มันเป็นสิ่งที่เราทำ DDD สำหรับ ด้วยการคำนวณใน SQL นั้นกลายเป็นส่วนหนึ่งของ BL / DL สิ่งที่คุณจะทำคือการใช้มุมมองที่แยกต่างหาก / ขั้นตอนการเก็บ / สิ่งที่มีคุณและให้ธุรกิจตรรกะแยกออกจากข้อมูลชั้นเป็นที่เป็น API ภายนอกของคุณ ในความเป็นจริง data-layer ของคุณควรเป็นอีก DDD Domain Layer ที่ data-layer ของคุณมีabstractions ของตัวเองเพื่อทำงานกับ layer ของโดเมนอื่น

การคำนวณเหล่านี้ในโครงสร้างพื้นฐานไม่สามารถเกิดขึ้นได้เช่นกันเพราะรูปแบบ DDD ช่วยให้สามารถเปลี่ยนแปลงโครงสร้างพื้นฐานได้โดยไม่ต้องเปลี่ยน Domain Layer และรู้ว่า MongoDB ไม่มีความสามารถเช่น SQL Server ที่ไม่สามารถเกิดขึ้นได้

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

โปรดทราบอีกครั้งว่า DDD นั้นเกี่ยวกับการซ่อน internals ด้วย API ภายนอกที่กำหนดไว้อย่างดี ตำแหน่งที่ API เหล่านั้นเป็นคำถามที่แตกต่างอย่างสิ้นเชิงและ DDD ไม่ได้กำหนดไว้ มันก็กำหนดที่มีอยู่ของ API เหล่านี้และไม่ควรเปลี่ยนแปลง

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

ลองใช้การเปรียบเทียบกับสิ่งที่ DDD กำหนด: แก๊สกับรถยนต์ไฟฟ้า ยานพาหนะทั้งสองมีสองวิธีที่แตกต่างกันโดยสิ้นเชิงสำหรับการสร้างแรงขับ แต่พวกเขามี API เดียวกัน: เปิด / ปิดคันเร่ง / เบรกและล้อเพื่อขับเคลื่อนยานพาหนะ DDD กล่าวว่าเราควรจะสามารถเปลี่ยนเครื่องยนต์ (แก๊สหรือไฟฟ้า) ในรถของเรา ไม่ได้บอกว่าเราสามารถเปลี่ยนรถเป็นมอเตอร์ไซค์ได้และนั่นก็คือ MSSQL → MongoDB ที่มีประสิทธิภาพ

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

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

เบี่ยงเบนจากรูปแบบสถาปัตยกรรม

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

• นี่เป็นรูปแบบที่ถูกต้องหรือไม่ (หลายครั้งมันเป็น แต่บางครั้งมันก็เป็นแบบที่ไม่ดี)
• ฉันควรเบี่ยงเบนในทางเดียวหรือไม่?
• ฉันเบี่ยงเบนไปมากแค่ไหน

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

อย่างไรก็ตามหากคุณพบว่าส่วนเบี่ยงเบนสะสมของคุณมีจำนวนมากกว่า 20% ของสถาปัตยกรรมแอปพลิเคชันของคุณก็อาจเป็นเรื่องที่ไม่เหมาะสม

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

ตรรกะการจัดการชุดที่ SQL เป็นสิ่งที่ดีสามารถบูรณาการกับ DDD ไม่มีปัญหา

พูดเช่นฉันจำเป็นต้องรู้มูลค่ารวมจำนวนรวมของผลิตภัณฑ์ตามประเภท ใช้งานง่ายใน sql แต่ช้าถ้าฉันโหลดทุกผลิตภัณฑ์ลงในหน่วยความจำและเพิ่มทั้งหมด

ฉันแนะนำวัตถุโดเมนใหม่

ProductInventory
{
    ProductType
    TotalCount
    DateTimeTaken
}

และวิธีการในพื้นที่เก็บข้อมูลของฉัน

ProductRepository
{
    List<ProductInventory> TakeInventory(DateTime asOfDate) {...}
}

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

หนึ่งในวิธีที่เป็นไปได้ในการแก้ไขปัญหานี้คือการคิดถึง SQL ในภาษาแอสเซมบลี: คุณไม่ค่อยโค้ดเลย แต่ถ้าประสิทธิภาพการทำงานคุณจำเป็นต้องเข้าใจโค้ดที่ผลิตโดย C ของคุณ / C ++ / Golang / Rust คอมไพเลอร์และอาจจะเขียนตัวอย่างเล็ก ๆ ในการประกอบถ้าคุณไม่สามารถเปลี่ยนรหัสในภาษาระดับสูงของคุณในการผลิตรหัสเครื่องที่ต้องการ

ในทำนองเดียวกันในขอบเขตของฐานข้อมูลและ SQL ไลบรารี SQL ต่างๆ (บางอันก็คือORM ) เช่นSQLAlchemyและ Django ORM สำหรับ Python, LINQสำหรับ. NET, ให้ abstractions ระดับที่สูงขึ้น แต่ใช้โค้ด SQL ที่สร้างขึ้นเพื่อให้ได้ประสิทธิภาพ พวกเขายังให้การพกพาบางส่วนสำหรับฐานข้อมูลที่ใช้ซึ่งอาจมีประสิทธิภาพที่แตกต่างกันเช่นใน Postgres และ MySQL เนื่องจากการดำเนินการบางอย่างโดยใช้ SQL เฉพาะ DB ที่เหมาะสมกว่า

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

ป.ล. ฉันต้องการแสดงความคิดเห็น แต่ฉันไม่มีชื่อเสียงเพียงพอ

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

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

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

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

นั่นเป็นข้อผิดพลาดของรูปแบบ DDD หรือไม่?

ก่อนอื่นให้ฉันลบความเข้าใจผิดบางประการ

DDD ไม่ใช่รูปแบบ และมันไม่ได้กำหนดรูปแบบจริงๆ

คำนำหน้าสถานะหนังสือDDD ของ Eric Evan :

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

[ ... ]

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

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

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

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

ไม่มีอะไรเกี่ยวกับสิ่งนั้นที่เป็น pro-or anti-SQL โดยเนื้อแท้แม้ว่าผู้พัฒนา OO อาจจะดีกว่าในการแสดงแบบจำลองในภาษา OO และการแสดงออกของแนวคิดโดเมนจำนวนมากได้รับการสนับสนุนที่ดีกว่าโดย OOP แต่บางครั้งบางส่วนของแบบจำลองจะต้องแสดงในกระบวนทัศน์ที่แตกต่างกัน

สิ่งที่ฉันสงสัยคือจะเกิดอะไรขึ้นเมื่อฉันมีข้อความค้นหาที่ซับซ้อนมาก [... ]?

โดยทั่วไปการพูดมีสองสถานการณ์ที่นี่

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

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

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

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

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

คุณช่วยให้เครื่องกำเนิด PDF ฝังอยู่ในไดรเวอร์เครื่องพิมพ์หรือเพิ่มทริกเกอร์ซึ่งจะพิมพ์หน้าบันทึกสำหรับทุกคำสั่งขายที่พิมพ์ออกมาจากเครื่องพิมพ์ของเราหรือไม่?

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

ใน 70's- 90's ฐานข้อมูล SQL มีประสิทธิภาพตอนนี้? - ไม่แน่ใจว่าในบางสถานการณ์แบบสอบถามข้อมูลแบบอะซิงโครนัสจะส่งคืนข้อมูลที่ต้องการได้เร็วกว่าการรวมหลายรายการในแบบสอบถาม SQL

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

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