ฉันควรใช้ขั้นตอนการจัดเก็บเมื่อใด

ถ้าฉันมีตรรกะทางธุรกิจทั้งหมดของฉันในรหัสและใช้ประโยชน์จาก Entity Framework ในสถานการณ์ใด (ถ้ามี) ฉันจะย้ายตรรกะทางธุรกิจบางอย่างไปยังขั้นตอนการจัดเก็บดีกว่าแทนที่จะเก็บไว้ในรหัสทั้งหมดหรือไม่

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

ถ้ามันสร้างความแตกต่างฉันกำลังใช้ MSSQL และ Entity Framework

นี่คือสถานการณ์ที่ฉันใช้โพรซีเดอร์ที่เก็บไว้ก่อนหน้านี้:

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

โพสต์อื่นที่ฉันได้ดูก่อนถามคำถามนี้:

• ขั้นตอนการจัดเก็บวิธีปฏิบัติที่ไม่ดีที่หนึ่งใน บริษัท ที่ปรึกษาด้านไอทีรายใหญ่ที่สุดในโลก?
• ข้อดีข้อเสียของการถือตรรกะทางธุรกิจทั้งหมดในขั้นตอนการจัดเก็บในเว็บแอปพลิเคชัน
• /programming/15142/what-are-the-pros-and-cons-to-keeping-sql-in-stored-procs-versus-code
• /dba/2450/what-are-the-arguments-against-or-for-putting-application-logic-in-the-database/2452#2452
• เมื่อใดที่จะไม่ใช้ ORM และชอบวิธีการจัดเก็บ?

คุณมีสถานการณ์ที่ดีอย่างสมบูรณ์สองสามอย่างแล้ว

มีเหตุผลอื่นอีกมากมายเช่นกัน EF ดีมากที่ CRUD และการรายงานตรงไปตรงมา อย่างไรก็ตามบางครั้ง EF ก็ไม่ใช่เครื่องมือที่สมบูรณ์แบบ เหตุผลอื่น ๆ (สถานการณ์) เพื่อพิจารณาการใช้กระบวนงานที่เก็บไว้ร่วมกับ Entity Framework จะรวมถึง:

• คุณมีหน่วยงานที่ซับซ้อนซึ่งอาจเกี่ยวข้องกับตารางจำนวนมากที่ไม่สามารถห่อหุ้มธุรกรรมได้อย่างง่ายดายโดยใช้คุณสมบัติของ EF
• ฐานข้อมูลของคุณเล่นได้ไม่ดีกับ EF เพราะล้มเหลวในการใช้ประโยชน์จากความสมบูรณ์ของการอ้างอิงที่เปิดเผย (ข้อ จำกัด คีย์ต่างประเทศ) นี่เป็นสถานการณ์ที่ไม่ดีที่จะค้นหาตัวเอง แต่บางครั้งก็มีสถานการณ์ที่เหมาะสมเช่นฐานข้อมูลที่ใช้สำหรับกระบวนการ ETL
• คุณต้องทำงานกับข้อมูลที่ข้ามขอบเขตของเซิร์ฟเวอร์กับเซิร์ฟเวอร์ที่เชื่อมโยง
• คุณมีสถานการณ์การดึงข้อมูลที่ซับซ้อนมากซึ่งจำเป็นต้องมี SQL "metal metal" เพื่อให้แน่ใจว่ามีประสิทธิภาพเพียงพอ ตัวอย่างเช่นคุณมีการรวมที่ซับซ้อนที่ต้องการคำแนะนำแบบสอบถามเพื่อให้ทำงานได้ดีในสถานการณ์เฉพาะของคุณ
• แอปพลิเคชันของคุณไม่มีสิทธิ์ CRUD เต็มรูปแบบบนโต๊ะ แต่แอปพลิเคชันของคุณสามารถได้รับอนุญาตให้ทำงานภายใต้บริบทความปลอดภัยที่เซิร์ฟเวอร์ของคุณเชื่อถือ (ข้อมูลประจำตัวแอปพลิเคชันแทนที่จะเป็นข้อมูลเฉพาะตัวของผู้ใช้) สิ่งนี้อาจเกิดขึ้นในสถานการณ์ที่ DBAs จำกัด การเข้าถึงตารางไปยัง procs ที่จัดเก็บไว้เท่านั้นเพราะจะทำให้พวกเขาสามารถควบคุมได้อย่างละเอียดว่าใครสามารถทำอะไรได้บ้าง

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

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

ถ้ามันสร้างความแตกต่างฉันกำลังใช้ MSSQL และ Entity Framework

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

ถ้าฉันรับสองประเด็นสำคัญของคุณ:

รายงานที่ซับซ้อนซึ่งใช้เวลาไม่กี่นาทีในการเรียกใช้ (นี่คือหน้าเว็บในแอปพลิเคชัน) ฉันพบว่าฉันสามารถเขียน SQL ที่มีประสิทธิภาพมากขึ้น (ใช้เวลาเพียงไม่กี่วินาทีในการเรียกใช้) กว่าที่ LINQ จัดหาให้

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

ปัญหาของคุณได้รับการแก้ไขอย่างเห็นได้ชัดกับSQL ถ้าแบบสอบถามที่ได้รับการจัดเก็บและควบคุมรุ่นในหมวด codebase คุณ - ตามตัวอย่างของคุณ - อย่างน้อยไม่แตกต่างกัน

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

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

ดังนั้นไม่มีอะไรให้ดูที่นี่

ดูบางจุดที่คนอื่นทำ:

คุณมีหน่วยงานที่ซับซ้อนซึ่งอาจเกี่ยวข้องกับตารางจำนวนมากที่ไม่สามารถห่อหุ้มธุรกรรมได้อย่างง่ายดายโดยใช้คุณสมบัติของ EF

แต่SQLสามารถทำได้ ไม่มีเวทมนตร์เกี่ยวข้องที่นี่

ฐานข้อมูลของคุณเล่นได้ไม่ดีกับ EF

อีกครั้ง: ใช้EFเมื่อเหมาะสม

คุณต้องทำงานกับข้อมูลที่ข้ามขอบเขตของเซิร์ฟเวอร์กับเซิร์ฟเวอร์ที่เชื่อมโยง

ฉันไม่เห็นวิธีการจัดเก็บช่วย ดังนั้นฉันไม่สามารถเห็นข้อดีของขั้นตอนการจัดเก็บ; แต่บางทีอาจมีบางคนให้ความกระจ่างในเรื่องนั้น

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

อีกครั้ง: "ขอบเขตของEF "

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

ตกลง. ฉันไปด้วยบางที

จนถึงจุดครึ่งเดียวที่ทำในความโปรดปรานของขั้นตอนการจัดเก็บ

อาจมีข้อควรพิจารณาเกี่ยวกับประสิทธิภาพการทำงานซึ่งเป็นประโยชน์ต่อกระบวนการจัดเก็บ

1) การจัดเก็บเคียวรีมีข้อดีของการเรียกไปยังโพรซีเดอร์ที่เก็บแบบง่ายซึ่งสรุปความซับซ้อน เนื่องจากตัววางแผนคิวรีรู้จักการสืบค้นจึงเป็น "การเพิ่มประสิทธิภาพ" ที่ง่ายขึ้น แต่การบันทึกจะอยู่กับตัวสร้างคิวรีที่ซับซ้อนในปัจจุบัน _minimal

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

2) อย่างไรก็ตามมันถูกถกเถียงกันในการจัดเก็บแบบสอบถามที่ซับซ้อนในฐานข้อมูล มีสองสิ่งที่ควรพิจารณา:

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

b) หากแบบสอบถามใช้เวลานานทำไมต้องรำคาญกับความเร็วขนาดเล็กที่ชนะของกระบวนงานที่เก็บไว้

TL; DR

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

แต่ในอีกแง่หนึ่ง: ฉันไม่สามารถจินตนาการถึงกรณีการใช้งานที่เหมาะสมซึ่งพูดอย่างมืออาชีพ

ฉันควรใช้ขั้นตอนการจัดเก็บเมื่อใด

คำตอบที่ถูกต้องคือเมื่อใดก็ตามที่คุณต้องการ แต่มีตัวเลือกอื่น ๆ

สำหรับกรณีเฉพาะของคุณเนื่องจากคุณใช้เฟรมเวิร์กเอนทิตี้ของหนึ่งควรพิจารณาใช้กระบวนงานที่เก็บไว้เมื่อเฟรมเวิร์กเอนทิตี้ล้มเหลวในการตอบสนองความต้องการหรือข้อกังวล

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

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

ดังนั้นฉันจะไม่ย้ายอะไรไปยังกระบวนงานที่เก็บไว้เว้นแต่ว่ากรอบงานที่ใช้ไม่สามารถตอบสนองความต้องการได้

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

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

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

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

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

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

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

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

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

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

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

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

ฉันคิดว่ามีสามประเด็นที่นี่

1. ตรรกะทางธุรกิจใน SQL ไม่ถูกต้อง แม้ว่ามันจะทำงานเร็วขึ้นเป็นรายบุคคล แต่ก็ไม่ได้ปรับขนาด

2. ควรใช้ SPROC แบบดั้งเดิมสำหรับการเข้าถึงข้อมูลทั้งหมดเป็นเลเยอร์นามธรรม การเปิดใช้งาน DBA เพื่อแนะนำประสิทธิภาพหรือการเปลี่ยนแปลงข้อมูลอื่น ๆ โดยไม่กระทบต่อแอปพลิเคชันที่ต้องบริโภค

3. EF ไม่เล่นกับ sprocs คุณจะสูญเสียคุณสมบัติ "ดี" และกำไรเพิ่มขึ้นจำนวนมากโดยเปลี่ยนจากการสร้างคิวรีแบบไดนามิกของ Linq

ดังนั้นคำแนะนำโดยรวมของฉันก็คือ

• ใช้ SPROCs สำหรับแบบสอบถาม SQL ทั้งหมด

• อย่าวางตรรกะทางธุรกิจหรือลูปใด ๆ ไว้ในนั้น

• อย่าใช้ EF