“ อย่าทำรหัสอะไรที่คุณสามารถทำให้เซิร์ฟเวอร์ SQL ทำงานได้ดีสำหรับคุณ” - นี่เป็นสูตรสำหรับการออกแบบที่ไม่ดีหรือไม่?

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

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

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

ในคำพูดของคนธรรมดา:

สิ่งเหล่านี้เป็นสิ่งที่SQL ทำขึ้นมาและเชื่อหรือไม่ว่าฉันได้เห็นในโค้ดแล้ว:

• เข้าร่วม - codewise มันต้องการการจัดการอาร์เรย์ที่ซับซ้อน
• ข้อมูลการกรอง (ที่ไหน) - เข้ารหัสมันต้องการการแทรกและการลบรายการในรายการอย่างมาก
• การเลือกคอลัมน์ - เข้ารหัสมันต้องการรายการที่หนักหน่วงหรือการจัดการอาเรย์
• ฟังก์ชั่นรวม - codewise มันต้องการอาร์เรย์เพื่อเก็บค่าและกรณีสวิตช์ที่ซับซ้อน
• ความสมบูรณ์ของ foreign key - ประมวลผลว่าต้องการคิวรีก่อนที่จะแทรกและถือว่าไม่มีใครใช้ข้อมูลภายนอกแอพ
• ความสมบูรณ์ของคีย์หลัก - เข้ารหัสมันต้องการคำสั่งก่อนที่จะแทรกและถือว่าไม่มีใครใช้ข้อมูลภายนอกแอพ

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

ฉันจะใช้ถ้อยคำใหม่เพื่อ "ไม่เคยทำในรหัสสิ่งที่ SQL Server สามารถทำเพื่อคุณได้ดี "

สิ่งต่าง ๆ เช่นการจัดการสตริง regex ทำงานและฉันจะไม่ทำใน SQL Server (ยกเว้น SQL CLR)

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

ไม่เคยทำในรหัสสิ่งที่คุณจะได้รับเซิร์ฟเวอร์ SQL ที่จะทำอย่างดีสำหรับคุณ(เน้นเป็นของฉัน)

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

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

ลองพิจารณาตัวอย่างเหล่านี้:

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

ในระยะสั้นก็จะมีความถูกต้องที่จะกล่าวว่า: "ไม่เคยดำเนินการการดำเนินงานเฉพาะฐานข้อมูลในฐานรหัสของคุณ" ที่พวกเขามีการแก้ไขที่ดีขึ้นในฐานข้อมูลของคุณ

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

นอกจากนี้ยังมีทางเลือกโครงการของฐานข้อมูลมีบทบาทสำคัญ การมี RDBMS (MS SQL, Oracle และอื่น ๆ ) นั้นแตกต่างจากฐานข้อมูล NoSQL เช่น RavenDB

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

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

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

ฉันคิดว่ามันจะเป็นการออกแบบที่ไม่ดีที่จะไม่ใช้ฐานข้อมูลสำหรับสิ่งที่มันมีไว้สำหรับ ฉันไม่เคยเห็นฐานข้อมูลใด ๆ ที่มีการบังคับใช้กฎภายนอกฐานข้อมูลที่มีข้อมูลที่ดี และฉันได้ดูฐานข้อมูลหลายร้อยแห่ง

ดังนั้นสิ่งที่ต้องทำในฐานข้อมูล:

• การตรวจสอบ (แอปพลิเคชันเท่านั้นการตรวจสอบจะไม่ติดตามการเปลี่ยนแปลงทั้งหมดในฐานข้อมูลและทำให้ไม่มีค่า)

• ข้อ จำกัด ด้านข้อมูลรวมถึงค่าเริ่มต้นข้อ จำกัด คีย์ต่างประเทศและกฎซึ่งจะต้องนำไปใช้กับข้อมูลทั้งหมดเสมอ ข้อมูลทั้งหมดไม่ได้เปลี่ยนแปลงหรือถูกแทรกผ่านแอปพลิเคชันเสมอมีการแก้ไขข้อมูลแบบครั้งเดียวโดยเฉพาะชุดข้อมูลขนาดใหญ่ที่ไม่มีประโยชน์ในการทำบันทึกครั้งละหนึ่งรายการ (โปรดอัปเดต 100,000 ระเบียนเหล่านี้ที่ไม่ตรงกันเป็นสถานะ 1 เมื่อควร เป็น 2 เนื่องจากข้อผิดพลาดของรหัสแอปพลิเคชันหรือโปรดอัปเดตระเบียนทั้งหมดจากไคลเอนต์ A ไปยังไคลเอนต์ B เนื่องจาก บริษัท B ซื้อ บริษัท A) และการนำเข้าข้อมูลและแอปพลิเคชันอื่น ๆ ซึ่งอาจแตะฐานข้อมูลเดียวกัน

• เข้าร่วมและการกรองข้อที่ (เพื่อลดจำนวนของระเบียนที่ส่งผ่านเครือข่าย)

"การเพิ่มประสิทธิภาพก่อนวัยอันควรเป็นรากฐานของความชั่วร้ายทั้งหมด (ส่วนใหญ่แล้ว) ในการเขียนโปรแกรมคอมพิวเตอร์" - Donald Knuth

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

ในขณะที่ความเชื่อมั่นในบรรทัดหัวเรื่องนั้นน่าชื่นชมและมีความแม่นยำจนถึงจุดหนึ่ง (ความดีของการกรองการฉายการจัดกลุ่ม ฯลฯควรมีจำนวนผู้ป่วยล้นหลามในฐานข้อมูล) คำจำกัดความของ "ดี" อาจอยู่ใน ใบสั่ง. งานที่ SQL Server สามารถดำเนินการด้วยประสิทธิภาพระดับสูงนั้นมีมากมาย แต่งานที่คุณสามารถสาธิตได้ว่า SQL Server ทำอย่างถูกต้องในลักษณะที่แยกได้ทำซ้ำได้น้อยมาก SQL Management Studio เป็นฐานข้อมูลที่ยอดเยี่ยม IDE (โดยเฉพาะอย่างยิ่งตัวเลือกอื่น ๆ ที่ฉันเคยทำงานด้วยเช่นคางคก) แต่มันมีข้อ จำกัด อันดับแรกคือสิ่งที่คุณใช้ในการทำสิ่งนั้น ฐานข้อมูลด้านล่าง) เป็นคำจำกัดความว่า "ผลข้างเคียง" (การเปลี่ยนสถานะที่อยู่นอกโดเมนของพื้นที่หน่วยความจำของกระบวนการของคุณ) นอกจากนี้โค้ดขั้นตอนภายใน SQL Server เป็นเพียงตอนนี้ด้วย IDEs และเครื่องมือล่าสุดสามารถวัดวิธีที่รหัสที่มีการจัดการสามารถใช้ตัวชี้วัดความครอบคลุมและการวิเคราะห์เส้นทาง (เพื่อให้คุณสามารถแสดงให้เห็นว่า , Y และ Z และการทดสอบ X ออกแบบมาเพื่อทำให้สภาพเป็นจริงและดำเนินการครึ่งหนึ่งในขณะที่ Y และ Z ดำเนินการ "อื่น" . ในทางกลับกันสมมติว่าคุณมีการทดสอบที่สามารถตั้งค่าฐานข้อมูลด้วยสถานะเริ่มต้นเฉพาะเรียกใช้งานโค้ดโพรซีเดอร์ฐานข้อมูลผ่านการดำเนินการบางอย่างและยืนยันผลลัพธ์ที่คาดหวัง

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

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

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

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

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

แน่นอนว่าคุณได้โกนทิ้งไป 2 วินาที อย่างไรก็ตามคุณค่อนข้างเสีย 100% ของ (อย่างน้อย) ซีพียูหนึ่งคอร์บนเซิร์ฟเวอร์ฐานข้อมูลของคุณเป็นเวลา 10 วินาทีหรือคุณเสียเวลาไปกับการที่เว็บเซิร์ฟเวอร์ของคุณหรือไม่

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

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

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

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

เพียงแค่ $ 0.02 ของฉัน

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

รหัสหลัก, รหัสต่างประเทศและข้อ จำกัด (ไม่เป็นโมฆะ) สามารถบังคับใช้โดยรหัส ข้อ จำกัด คือตรรกะทางธุรกิจ พวกเขาควรจะถูกปล่อยออกจากฐานข้อมูลเนื่องจากพวกเขาทำซ้ำรหัสอะไรสามารถทำได้?

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

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

คุณคิดว่า "เลเยอร์" เป็นตัวแบ่งทางกายภาพโดยเซิร์ฟเวอร์หรือแยกทางตรรกะหรือไม่? การใช้ตรรกะบนเซิร์ฟเวอร์ใด ๆ ในทางทฤษฎีอาจยังตกอยู่ภายใต้ตรรกะของเลเยอร์ตรรกะ คุณอาจจัดการแยกโดยรวบรวมเป็น DLL ที่แตกต่างกันแทนที่จะแยกเซิร์ฟเวอร์โดยเฉพาะ สิ่งนี้สามารถเพิ่มเวลาตอบสนองได้อย่างมาก (แต่เสียสละผลงาน) ในขณะที่ยังคงมีข้อกังวลอยู่ แยก DLL ได้ในภายหลังสามารถย้ายไปยังเซิร์ฟเวอร์อื่น ๆ โดยไม่ต้องสร้างใหม่เพื่อเพิ่มปริมาณงาน (ที่ต้นทุนของเวลาตอบสนอง)

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

ดังนั้นมันจึงเป็นสำนวนการออกแบบที่ดีหรือเป็นกฎง่ายๆ ไม่มีจำนวนของประสิทธิภาพที่จะช่วยในระบบที่มีข้อมูลที่เสียหาย

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

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

มีบางสิ่งที่ต้องจำ:

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

"การเพิ่มประสิทธิภาพก่อนวัยอันควรเป็นรากฐานของความชั่วร้ายทั้งหมด" - Donald Knuth

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

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