คำถามติดแท็ก stored-procedures

ฉันทำงานในโครงการหนึ่งใน บริษัท ให้คำปรึกษาด้านไอทีชั้นนำของโลกและได้รับการบอกเล่าจาก DBA ว่าวิธีปฏิบัติที่ดีที่สุดในการจัดเก็บของรัฐไม่ใช่วิธี "ปฏิบัติที่ดีที่สุด" ตรงกันข้ามกับทุกสิ่งที่ฉันเรียนรู้ ขั้นตอนการจัดเก็บจะช่วยให้คุณสามารถนำโค้ดกลับมาใช้ใหม่และการห่อหุ้ม (สองเสาหลักของการพัฒนาซอฟต์แวร์) การรักษาความปลอดภัย (คุณสามารถให้ / เพิกถอนการอนุญาตในแต่ละโปรแกรมที่เก็บไว้) ปกป้องคุณจากการโจมตีด้วยการฉีด SQL เริ่มต้นด้วย SQL Server 2008 ที่แม้แต่แบบสอบถาม SQL ทั่วไปจะถูกคอมไพล์หากมีการเรียกใช้เวลาเพียงพอ) เรากำลังพัฒนาแอพที่ซับซ้อนโดยใช้วิธีการพัฒนาซอฟต์แวร์ Agile ทุกคนคิดเหตุผลที่ดีว่าทำไมพวกเขาไม่ต้องการใช้ procs ที่เก็บไว้? ฉันเดาว่า DBAs ไม่ต้องการรักษา procs ที่เก็บไว้ แต่ดูเหมือนว่าจะมีวิธีเชิงลบมากเกินไปที่จะพิสูจน์การตัดสินใจในการออกแบบ

148 mysql  sql-server  oracle  postgres  stored-procedures 

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

41 business-logic  n-tier  layers  stored-procedures  separation-of-concerns 

ฉันทำงานที่ บริษัท ที่ใช้ขั้นตอนการจัดเก็บสำหรับการเข้าถึงข้อมูลทั้งหมดเท่านั้นซึ่งทำให้มันน่ารำคาญมากที่จะทำให้ฐานข้อมูลท้องถิ่นของเราตรงกันเนื่องจากทุกครั้งที่เราต้องเรียกใช้โปรแกรมใหม่ ฉันเคยใช้ ORM พื้นฐานบางอย่างในอดีตและฉันพบว่าประสบการณ์ดีขึ้นและสะอาดขึ้นมาก ฉันอยากจะแนะนำผู้จัดการฝ่ายพัฒนาและทีมอื่น ๆ ที่เราใช้ ORM เพื่อการพัฒนาในอนาคต (ทีมที่เหลือคุ้นเคยกับกระบวนการจัดเก็บเท่านั้นและไม่เคยใช้อะไรเลย) สถาปัตยกรรมปัจจุบันคือ. NET 3.5 ที่เขียนเหมือน. NET 1.1 โดยมี "god classes" ที่ใช้การดำเนินการแปลก ๆ ของ ActiveRecord และส่งกลับชุดข้อมูลที่ไม่ได้พิมพ์ซึ่งวนลูปในไฟล์ code-behind คลาสใช้งานดังนี้: class Foo { public bool LoadFoo() { bool blnResult = false; if (this.FooID == 0) { throw new Exception("FooID must be set …

31 c#  database  orm  stored-procedures 

หลังจากใช้ Hibernate ในโครงการส่วนใหญ่ของฉันเป็นเวลาประมาณ 8 ปีฉันได้ตกลงกับ บริษัท ที่ไม่สนับสนุนการใช้งานและต้องการให้แอปพลิเคชันโต้ตอบกับ DB ผ่านขั้นตอนการจัดเก็บเท่านั้น หลังจากทำสิ่งนี้สองสามสัปดาห์ฉันก็ไม่สามารถสร้างรูปแบบโดเมนที่หลากหลายของแอปพลิเคชันที่ฉันเริ่มสร้างได้และแอปพลิเคชันก็ดูเหมือนสคริปต์ธุรกรรมที่น่ากลัว ปัญหาบางอย่างที่ฉันพบคือ: ไม่สามารถนำทางกราฟวัตถุในขณะที่ขั้นตอนการจัดเก็บเพียงแค่โหลดข้อมูลขั้นต่ำซึ่งหมายความว่าบางครั้งเรามีวัตถุที่คล้ายกันที่มีเขตข้อมูลที่แตกต่างกัน ตัวอย่างหนึ่งคือ: เรามีขั้นตอนการจัดเก็บเพื่อดึงข้อมูลทั้งหมดจากลูกค้าและอีกวิธีหนึ่งในการดึงข้อมูลบัญชีรวมทั้งสองสามช่องจากลูกค้า ตรรกะจำนวนมากจบลงในคลาสตัวช่วยดังนั้นโค้ดจึงมีโครงสร้างมากขึ้น (โดยใช้เอนทิตีที่ใช้เป็นโครงสร้าง C แบบเก่า) โค้ดนั่งร้านน่าเบื่อมากขึ้นเนื่องจากไม่มีกรอบที่แยกชุดผลลัพธ์จากกระบวนงานที่เก็บไว้และวางไว้ในเอนทิตี คำถามของฉันคือ: มีใครอยู่ในสถานการณ์ที่คล้ายกันและไม่เห็นด้วยกับวิธีการจัดเก็บ? คุณทำอะไรลงไป? มีประโยชน์จริง ๆ ของการใช้กระบวนงานที่เก็บไว้หรือไม่ นอกเหนือจากจุดที่ไร้สาระของ "ไม่มีใครสามารถออกตารางลดลง" มีวิธีการสร้างโดเมนที่หลากหลายโดยใช้ขั้นตอนการจัดเก็บหรือไม่? ฉันรู้ว่ามีความเป็นไปได้ที่จะใช้ AOP ในการฉีด DAOs / ที่เก็บข้อมูลลงในเอนทิตีเพื่อให้สามารถนำทางกราฟวัตถุ ฉันไม่ชอบตัวเลือกนี้เนื่องจากอยู่ใกล้กับวูดู ข้อสรุป ก่อนอื่นขอบคุณทุกคำตอบของคุณ บทสรุปที่ฉันได้มาคือ ORM ไม่สามารถเปิดใช้งานการสร้างโมเดล Rich Domain (ตามที่บางคนกล่าวถึง) แต่มันทำให้การทำงานง่ายขึ้น ต่อไปนี้เป็นคำอธิบายโดยละเอียดเพิ่มเติมของข้อสรุป แต่ไม่ได้อยู่บนพื้นฐานของข้อมูลที่ยาก แอปพลิเคชันส่วนใหญ่ร้องขอและส่งข้อมูลไปยังระบบอื่น ในการทำสิ่งนี้เราสร้างสิ่งที่เป็นนามธรรมในเงื่อนไขของแบบจำลอง (เช่นเหตุการณ์ทางธุรกิจ) และโมเดลของโดเมนจะส่งหรือรับเหตุการณ์ …

21 java  design  orm  stored-procedures  domain-driven-design 

ถ้าฉันมีตรรกะทางธุรกิจทั้งหมดของฉันในรหัสและใช้ประโยชน์จาก 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 และชอบวิธีการจัดเก็บ?

19 design  sql-server  orm  business-logic  stored-procedures 

ฉันใช้ PetaPoco micro-ORM เป็นเรื่องง่ายและปลอดภัยในการทำงานกับฐานข้อมูลโดยใช้เครื่องมือ ORM แต่สิ่งเดียวที่ฉันเกลียดคือรหัสพิเศษ ฉันเคยใส่รหัสส่วนใหญ่ในฐานข้อมูลของตัวเองและใช้คุณสมบัติ RDBMS ทั้งหมดเช่น Stored Procedure, Triggers เป็นต้นซึ่งมันถูกสร้างขึ้นเพื่อจัดการที่ดีขึ้น ฉันต้องการที่จะรู้ว่าเมื่อใดที่จะไม่ใช้ ORM มากกว่าขั้นตอนการจัดเก็บ / ทริกเกอร์และในทางกลับกัน

13 orm  rdbms  stored-procedures 

ฉันเริ่มโครงการใหม่และพยายามอย่างหนักที่จะใช้ TDD เพื่อผลักดันการออกแบบ ฉันผลักดันมาหลายปีและในที่สุดก็ได้รับการอนุมัติให้ใช้เวลาเพิ่มในโครงการนี้เพื่อใช้ในขณะที่ฉันเรียนรู้วิธีการทำอย่างถูกต้อง นี่คือโมดูลใหม่เพื่อผูกเข้ากับระบบที่มีอยู่ ขณะนี้การเข้าถึงข้อมูลทั้งหมดเกิดขึ้นผ่าน webservices ซึ่งส่วนใหญ่เป็นเพียงกระดาษห่อหุ้มบาง ๆ ผ่านขั้นตอนการจัดเก็บฐานข้อมูล ข้อกำหนดหนึ่งคือสำหรับร้านค้าที่ระบุฉันส่งคืนใบสั่งซื้อทั้งหมดที่ถือว่าใช้ได้สำหรับแอปพลิเคชันนี้ ใบสั่งซื้อถือว่าสมบูรณ์ถ้าวันที่จัดส่งตรงกับช่วงที่กำหนดจากวันที่เปิดร้านค้า (สำหรับร้านค้าใหม่) ตอนนี้ฉันไม่สามารถใส่ตรรกะนี้ลงในรหัสแอปพลิเคชันได้เนื่องจากฉันจะไม่นำเงินคืน PO นับล้านเพื่อรับโหลที่ใช้กับสามารถนำไปใช้กับร้านนี้ได้เนื่องจากข้อ จำกัด ข้างต้น ฉันคิดว่าฉันสามารถส่งช่วงวันที่ไปยัง GetValidPOs proc และใช้ค่าเหล่านั้นเพื่อส่งคืน PO ที่ถูกต้อง แต่ถ้าเราเพิ่มข้อกำหนดอื่นให้กับสิ่งที่ถือว่าเป็น PO ที่ถูกต้อง และฉันจะทดสอบสิ่งนี้และตรวจสอบว่ามันยังทำงานได้อย่างไร เราไม่ได้ใช้ ORM และไม่น่าจะเกิดขึ้น และฉันไม่สามารถเรียก DB ในการทดสอบของฉันได้ ผมติดอยู่. ความคิดอื่นของฉันคือมี mocks บางตัวที่ส่งคืนข้อมูลที่ถูกต้องส่วนอื่น ๆ ที่ส่งคืนข้อมูลที่ไม่ดีและมีที่เก็บข้อมูลในตัวเครื่องเกิดข้อยกเว้นหากข้อมูลไม่ดีเกิดขึ้นและทดสอบว่าข้อผิดพลาดเกิดขึ้นหาก GetValidPOs proc ล้อเลียนที่ใช้ในการทดสอบ) มันสมเหตุสมผลหรือไม่ หรือมีวิธีที่ดีกว่า UPDATE: ฉันสามารถใช้ภาษา EF ได้ ตอนนี้ฉันเพียงแค่ต้องคิดหาวิธีการใช้และทำให้มันทดสอบได้ในขณะที่ยังสามารถพึ่งพาขั้นตอนการจัดเก็บและความยากลำบากในการมีข้อมูลกระจัดกระจายไปทั่วฐานข้อมูลหลายแห่ง

12 tdd  stored-procedures 

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

11 naming  database-development  stored-procedures