เมื่อใดที่จะไม่ใช้ ORM และชอบวิธีการจัดเก็บ?

13

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

ฉันต้องการที่จะรู้ว่าเมื่อใดที่จะไม่ใช้ ORM มากกว่าขั้นตอนการจัดเก็บ / ทริกเกอร์และในทางกลับกัน

orm rdbms stored-procedures

— RPK
แหล่งที่มา

6

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

— โจอาคิมซาวเออ

16

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

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

ใน DotNet ห้ามใช้โพรซีเดอร์ที่เก็บไว้หาก:

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

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

บางคนชอบการใช้ Stored Procedure มากกว่า SQL ในรหัสด้วยเหตุผลที่แตกต่างกันเช่นความปลอดภัย (เช่นเพื่อป้องกันการฉีด SQL) และความเร็วที่อ้างสิทธิ์ อย่างไรก็ตามนี่เป็นปัญหาที่ค่อนข้างถกเถียงและต้องการการสนทนาอย่างละเอียด

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

— ไม่มีโอกาส
แหล่งที่มา

2

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

— Arseni Mourzenko

@MainMa ขอบคุณสำหรับความคิดเห็นของคุณ ความเข้าใจของฉันคือการใช้ SP หนึ่งสามารถลดความเสี่ยงของการฉีด SQL โดยการใช้กระบวนงานที่เก็บพารามิเตอร์กับพารามิเตอร์ฝังตัวตามที่บทความนี้แนะนำ: palpapers.plynt.com/issues/2006Jun/inject-stored-procedures

— NoChance

2

ขั้นตอนการจัดเก็บไม่มีผลกระทบต่อความเสี่ยงต่อการโจมตีของ sql injection ตำนานเก่าแก่ตายยาก

— Rig

@Rig 1 ขอขอบคุณสำหรับความคิดเห็นของคุณฉันต้องการเรียนรู้เพิ่มเติมเกี่ยวกับสิ่งที่คุณคิด ความเข้าใจของฉันมาจากข้อความนี้ (อย่างน้อย): "คุณสามารถขัดขวางการโจมตีการฉีด SQL Server โดยใช้กระบวนงานที่เก็บไว้และคำสั่งที่กำหนดพารามิเตอร์หลีกเลี่ยง SQL แบบไดนามิกและการ จำกัด สิทธิ์ผู้ใช้ทั้งหมด" ที่ปรากฏในmsdn.microsoft.com/en-us/library/bb669057.aspx

— NoChance

@EmmadKareem พารามิเตอร์ sql เป็นขั้นตอนใหญ่ในการทำให้ปลอดภัย ฉันคิดว่าผู้ชายคนนี้ทำให้คดีที่สมเหตุสมผลpalpapers.plynt.com/issues/2006 มิถุนายน / เดือน - การจัดเก็บ - ขั้นตอน การค้นหามันจะ "การฉีด SQL กระบวนงานที่เก็บไว้" จะเปิดดูจำนวนมาก เป็นการดีที่จะทำให้การป้อนข้อมูลของคุณถูกสุขลักษณะและแพลตฟอร์มจำนวนมากก็มีวิธีการที่ดีพอสมควร

— Rig

13

ORMs มักจะคิดว่าฐานข้อมูลที่มีอยู่ที่จะให้บริการออม แต่โดยปกติแล้วฐานข้อมูลจะให้บริการแก่ บริษัท ซึ่งอาจมีแอพเป็นร้อย ๆ ร้อยที่เขียนในหลายภาษา

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

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

ระวังอินเตอร์เฟสบรรทัดคำสั่ง dbms หากคุณใช้ DAL "ที่ไม่ยอมรับ"

— ไมค์ Sherrill 'Cat Recall'
แหล่งที่มา

4

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

— jfrankcarr

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

— Flater

-1

แบบสอบถามอย่างง่าย -> ORM

แบบสอบถามที่ซับซ้อน -> ขั้นตอนการจัดเก็บ

— darknight
แหล่งที่มา

3

คอมเพล็กซ์แยกออกจาก Query แบบง่ายที่ไหน

— อิสระ

-2

Trigger ควรใช้เป็นค่าคงที่ของบันทึกหรือประกอบด้วยกฎเกณฑ์ทางธุรกิจที่สำคัญ IMHO

ปัญหาของ orms:

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

— Yuriy Vikulov
แหล่งที่มา

-5

ไม่เห็นด้วย การสืบค้น ORM ง่ายกว่าถ้าคุณรู้จัก ORM ดีกว่าการรู้จัก SQL ORM ส่งผลให้มีรหัสมากขึ้นยากที่จะรักษา IMO บุคคลที่ได้รับประโยชน์จาก ORM เท่านั้นคือผู้ถือหุ้นของ บริษัท ที่ขาย ORM (เช่น Microsoft)

— ผี
แหล่งที่มา

1

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

— ริ้น