ข้อดีและข้อเสียของการรักษา SQL ไว้ใน Procs ที่จัดเก็บกับรหัส [ปิด]

อะไรคือข้อดี / ข้อเสียของการเก็บ SQL ไว้ในซอร์สโค้ด C # ของคุณหรือในโพรบ Procs ฉันได้คุยเรื่องนี้กับเพื่อนในโครงการโอเพนซอร์สที่เรากำลังดำเนินการอยู่ (ฟอรัม C # ASP.NET) ในขณะนี้การเข้าถึงฐานข้อมูลส่วนใหญ่ทำได้โดยการสร้าง SQL แบบอินไลน์ใน C # และเรียกไปยัง SQL Server DB ดังนั้นฉันจึงพยายามกำหนดว่าโครงการไหนดีที่สุดสำหรับโครงการนี้

จนถึงตอนนี้ฉันมี:

ข้อดีสำหรับในรหัส:

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

ข้อดีสำหรับ Procs ที่เก็บไว้:

• ประสิทธิภาพ
• ความปลอดภัย

ฉันไม่ใช่แฟนของขั้นตอนการจัดเก็บ

ขั้นตอนการจัดเก็บนั้นสามารถบำรุงรักษาได้มากขึ้นเนื่องจาก: * คุณไม่จำเป็นต้องคอมไพล์แอป C # ของคุณใหม่ทุกครั้งที่คุณต้องการเปลี่ยน SQL

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

• คุณสามารถใช้รหัส SQL ซ้ำได้

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

การทำซ้ำรหัสเป็นสิ่งที่แย่ที่สุดที่คุณสามารถทำได้เมื่อคุณพยายามสร้างแอปพลิเคชั่นที่บำรุงรักษาได้!

ตกลงซึ่งเป็นเหตุผลที่เก็บไว้ procs เป็นสิ่งที่ไม่ดี มันง่ายกว่ามากในการสร้างและย่อยสลายโค้ด (แบ่งเป็นส่วนเล็ก ๆ ) ลงในฟังก์ชั่นมากกว่า SQL ไปเป็น ... บล็อกของ SQL?

คุณมีเว็บเซิร์ฟเวอร์ 4 แห่งและแอพ windows จำนวนหนึ่งซึ่งใช้รหัส SQL เดียวกันตอนนี้คุณรู้แล้วว่ามีปัญหาเล็กน้อยกับรหัส SQl ดังนั้นคุณค่อนข้างจะ ...... เปลี่ยน proc ในที่เดียวหรือกดรหัสทั้งหมด เว็บเซิร์ฟเวอร์ติดตั้งแอปเดสก์ท็อปทั้งหมดใหม่ (Clickonce อาจช่วยได้) ในทุกช่องหน้าต่าง

เหตุใดแอพ windows ของคุณจึงเชื่อมต่อโดยตรงกับฐานข้อมูลกลาง ดูเหมือนว่าจะมีช่องโหว่ความปลอดภัยขนาดใหญ่อยู่ตรงนั้นและเป็นคอขวดเมื่อออกกฎการแคชฝั่งเซิร์ฟเวอร์ พวกเขาไม่ควรเชื่อมต่อผ่านบริการเว็บหรือคล้ายกับเว็บเซิร์ฟเวอร์ของคุณ?

ดังนั้นดัน 1 sproc ใหม่หรือ 4 webservers ใหม่

ในกรณีนี้มันเป็นเรื่องง่ายที่จะผลักดันหนึ่ง sproc ใหม่ แต่ในประสบการณ์ของผม 95% ของการเปลี่ยนแปลงการผลักดัน 'ส่งผลกระทบต่อรหัสและฐานข้อมูลไม่ได้ ถ้าคุณผลัก 20 สิ่งไปยังเว็บเซิร์ฟเวอร์ในเดือนนั้นและ 1 ไปยังฐานข้อมูลคุณจะสูญเสียอะไรมากถ้าคุณผลัก 21 สิ่งไปยังเว็บเซิร์ฟเวอร์แทนและศูนย์ไปยังฐานข้อมูล

ตรวจสอบรหัสได้ง่ายขึ้น

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

ข้อเสียเพิ่มเติม:

Storedprocs อาศัยอยู่ในฐานข้อมูลซึ่งปรากฏให้โลกภายนอกเป็นกล่องดำ สิ่งง่าย ๆ เช่นต้องการทำให้พวกเขาอยู่ในแหล่งควบคุมกลายเป็นฝันร้าย

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

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

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

การปรับฐานข้อมูลการผลิตอาจเป็นเรื่องยากอย่างยิ่งเมื่อแบบสอบถามถูกฝังอยู่ในรหัสและไม่อยู่ในจุดศูนย์กลางเดียวจัดการตำแหน่งได้ง่าย

[แก้ไข] ต่อไปนี้เป็นอีกการสนทนาในปัจจุบัน

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

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

(Pseudocode)

Function createOrder(Order yourOrder) 
Begin
  Call SP_createOrder(yourOrder)
End

ดังนั้นในตอนท้ายคุณจะได้เทียร์กลางของคุณทำงานบนคลัสเตอร์เซิร์ฟเวอร์ 4 ตัวที่ยอดเยี่ยมแต่ละตัวมี 16 ซีพียูและมันจะไม่ทำอะไรเลย! น่าขยะแขยง!

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

ข้อดีสำหรับในรหัส:

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

ที่จริงฉันคิดว่าคุณมีสิ่งนั้นย้อนกลับ IMHO, SQL ในรหัสเป็นความเจ็บปวดที่จะรักษาเพราะ:

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

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

ที่กล่าวไว้ว่าประสิทธิภาพที่เพิ่มขึ้นของ procs ที่จัดเก็บนั้นมีน้อยที่สุดเท่าที่ Stu พูดก่อนหน้าฉันและคุณไม่สามารถใส่จุดพักในกระบวนงานที่เก็บไว้ได้

CON

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

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

ข้อดี

1. ประสิทธิภาพสำหรับสิ่งที่อาจคุ้มค่า (หลีกเลี่ยงการแยกวิเคราะห์ข้อความโดยไดรเวอร์ DB / การพักผ่อนหย่อนใจแผน ฯลฯ )
2. การจัดการข้อมูลไม่ได้ฝังอยู่ในรหัส C / C ++ / C # ซึ่งหมายความว่าฉันมีรหัสระดับต่ำน้อยกว่าที่จะมองผ่าน SQL นั้นละเอียดน้อยกว่าและดูง่ายกว่าเมื่อแสดงรายการแยก
3. เนื่องจากคนแยกสามารถค้นหาและใช้รหัส SQL ได้ง่ายขึ้น
4. มันง่ายที่จะเปลี่ยนสิ่งต่าง ๆ เมื่อสคีมาเปลี่ยนแปลง - คุณเพียงแค่ต้องให้ผลลัพธ์เดียวกันกับโค้ดและมันจะทำงานได้ดี
5. ง่ายกว่าในการย้ายพอร์ตไปยังฐานข้อมูลอื่น
6. ฉันสามารถแสดงรายการการอนุญาตส่วนบุคคลในขั้นตอนการจัดเก็บและควบคุมการเข้าถึงในระดับนั้นได้เช่นกัน
7. ฉันสามารถโปรไฟล์แบบสอบถามข้อมูล / รหัสคงอยู่ของฉันแยกต่างหากจากรหัสการแปลงข้อมูลของฉัน
8. ฉันสามารถใช้เงื่อนไขที่เปลี่ยนแปลงได้ในขั้นตอนการจัดเก็บของฉันและมันจะง่ายต่อการปรับแต่งที่เว็บไซต์ของลูกค้า
9. การใช้เครื่องมืออัตโนมัติบางอย่างในการแปลงสคีมาและข้อความสั่งของฉันร่วมกันง่ายกว่าจะฝังไว้ภายในโค้ดของฉันซึ่งฉันจะต้องตามล่ามัน
10. การทำให้มั่นใจว่าแนวปฏิบัติที่ดีที่สุดสำหรับการเข้าถึงข้อมูลนั้นง่ายขึ้นเมื่อคุณมีรหัสการเข้าถึงข้อมูลทั้งหมดของคุณอยู่ในไฟล์เดียว - ฉันสามารถตรวจสอบข้อความค้นหาที่เข้าถึงตาราง nonantantant หรือใช้ระดับอนุกรมที่สูงขึ้นหรือเลือก * ในรหัส ฯลฯ .
11. มันจะง่ายต่อการค้นหาการเปลี่ยนแปลง schema / ตรรกะการเปลี่ยนแปลงข้อมูลเมื่อทั้งหมดอยู่ในไฟล์เดียว
12. การค้นหาและแทนที่การแก้ไขบน SQL จะทำได้ง่ายขึ้นเมื่ออยู่ในที่เดียวกันเช่นเปลี่ยน / เพิ่มคำสั่งแยกธุรกรรมสำหรับ procs ที่เก็บไว้ทั้งหมด
13. ฉันและผู้ชาย DBA พบว่าการมีไฟล์ SQL แยกต่างหากนั้นง่ายกว่า / สะดวกกว่าเมื่อ DBA ต้องตรวจสอบเนื้อหา SQL ของฉัน
14. สุดท้ายคุณไม่ต้องกังวลเกี่ยวกับการโจมตีด้วยการฉีด SQL เพราะสมาชิกขี้เกียจบางคนในทีมของคุณไม่ได้ใช้แบบสอบถามแบบ parametrized เมื่อใช้ sqls แบบฝัง

ข้อได้เปรียบด้านประสิทธิภาพสำหรับขั้นตอนการจัดเก็บมักจะถูกละเลย

ข้อดีเพิ่มเติมสำหรับขั้นตอนการจัดเก็บ:

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

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

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

ขั้นตอนการจัดเก็บ

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

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

ข้อดีสำหรับขั้นตอนการจัดเก็บ :

ตรวจสอบรหัสได้ง่ายขึ้น

คู่น้อยจึงทดสอบได้ง่ายขึ้น

ปรับได้ง่ายขึ้น

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

คุณสามารถป้องกันการเข้าถึงข้อมูลได้ง่ายขึ้นลบการเข้าถึงโดยตรงไปยังตารางบังคับใช้การรักษาความปลอดภัยผ่าน procs - นี่ยังช่วยให้คุณสามารถค้นหารหัสที่อัปเดตตารางได้อย่างรวดเร็ว

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

ข้อเสีย:

จัดการได้ยากสำหรับนักพัฒนา: การควบคุมเวอร์ชันของสคริปต์: ทุกคนมีฐานข้อมูลของตัวเองหรือไม่ระบบการควบคุมเวอร์ชันรวมเข้ากับฐานข้อมูลและ IDE หรือไม่

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

หนึ่งอาจโต้แย้งว่านี่เป็นการย้ายการประมวลผลบางอย่างจาก SQL ไปยังเว็บเซิร์ฟเวอร์ แต่โดยทั่วไปจะเป็นสิ่งที่ดี

สิ่งที่ยอดเยี่ยมอื่น ๆ เกี่ยวกับเทคนิคนี้คือถ้าคุณกำลังดูใน SQL profiler คุณสามารถดูคิวรีที่คุณสร้างและดีบักได้ง่ายกว่าการเห็นการเรียก proc ที่เก็บไว้โดยมีพารามิเตอร์ 20 ตัวเข้ามา

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

แฟนตัวยงของ Transact SQL การปรับคิวรีขนาดใหญ่ได้พิสูจน์แล้วว่ามีประโยชน์มากสำหรับฉัน ยังไม่ได้เขียน SQL แบบอินไลน์ใด ๆ ในเวลาประมาณ 6 ปี!

คุณแสดงรายการคะแนนโปร 2 รายการสำหรับ sprocs:

ประสิทธิภาพ - ไม่ได้จริงๆ ใน Sql 2000 หรือสูงกว่าการเพิ่มประสิทธิภาพแผนแบบสอบถามค่อนข้างดีและแคช ฉันแน่ใจว่า Oracle ฯลฯ ทำสิ่งที่คล้ายกัน ฉันไม่คิดว่าจะมีกรณีสำหรับ sprocs สำหรับการทำงานอีกต่อไป

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

นั่นเป็นแนวปฏิบัติที่ดีที่สุดสำหรับการแสดงต่อไป

Linq เป็นวิธีที่ฉันจะไปทำโครงการใหม่ทันที ดูโพสต์ที่คล้ายกันนี้

@Keith

การรักษาความปลอดภัย? ทำไม Sprocs ถึงปลอดภัยมากกว่า?

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

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

คิดแบบนี้

คุณมีเว็บเซิร์ฟเวอร์ 4 แห่งและแอพ windows จำนวนหนึ่งซึ่งใช้รหัส SQL เดียวกันตอนนี้คุณรู้แล้วว่ามีปัญหาเล็กน้อยกับรหัส SQl ดังนั้นคุณค่อนข้างจะ ...... เปลี่ยน proc ในที่เดียวหรือกดรหัสทั้งหมด เว็บเซิร์ฟเวอร์ติดตั้งแอปเดสก์ท็อปทั้งหมดใหม่ (Clickonce อาจช่วยได้) ในทุกช่องหน้าต่าง

ฉันชอบ procs ที่เก็บไว้

นอกจากนี้ยังง่ายกว่าที่จะทำการทดสอบประสิทธิภาพกับ proc วางในเคียวรีชุดวิเคราะห์สถิติ io / เวลาบน set showplan_text และ voila

ไม่จำเป็นต้องเรียกใช้ตัวสร้างโปรไฟล์เพื่อดูสิ่งที่ถูกเรียก

แค่ 2 เซ็นต์ของฉัน

ฉันชอบเก็บไว้ในรหัส (ใช้ ORM ไม่ใช่แบบอินไลน์หรือ ad-hoc) ดังนั้นพวกเขาถูกควบคุมโดยแหล่งที่มาโดยไม่ต้องจัดการกับการบันทึกไฟล์. sql

ขั้นตอนการจัดเก็บยังไม่ปลอดภัยกว่า คุณสามารถเขียนแบบสอบถามที่ไม่ดีด้วย sproc เช่นเดียวกับแบบอินไลน์ Parameterized แบบสอบถามแบบอินไลน์สามารถมีความปลอดภัยเช่นเดียวกับ sproc

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

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

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

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

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

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

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

ข้อเสียเดียวที่ฉันเห็นคือหลายภาษาไม่อนุญาตให้ส่งผ่านพารามิเตอร์ของตารางดังนั้นการส่งผ่านค่าตัวเลขที่ไม่ทราบค่าอาจเป็นเรื่องที่น่ารำคาญ อันหลังไม่ได้ทำให้ SP แย่กว่า inline SQL ในแง่นั้น)

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

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

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

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

เราใช้กระบวนงานที่เก็บไว้กับ Oracle DB ที่ฉันทำงานอยู่ตอนนี้ เรายังใช้การโค่นล้ม โพรซีเดอร์ที่เก็บไว้ทั้งหมดถูกสร้างเป็นไฟล์. pkb & .pks และบันทึกในการโค่นล้ม ฉันเคยทำ SQL แบบอินไลน์มาก่อนและมันเป็นความเจ็บปวด! ฉันชอบวิธีที่เราทำมากที่นี่ การสร้างและการทดสอบขั้นตอนการจัดเก็บใหม่นั้นทำได้ง่ายกว่าในรหัสของคุณ

เทเรซ่า

บันทึกที่เล็กลง

เล็ก ๆ น้อย ๆ อีกโปรสำหรับขั้นตอนการจัดเก็บที่ยังไม่ได้รับการกล่าวถึง: เมื่อมันมาถึงการจราจร SQL เข้าถึงข้อมูล SP-based สร้างมากการจราจรน้อย สิ่งนี้มีความสำคัญเมื่อคุณตรวจสอบปริมาณการใช้งานสำหรับการวิเคราะห์และการทำโปรไฟล์บันทึกจะมีขนาดเล็กลงและอ่านได้มาก

ฉันไม่ใช่แฟนตัวยงของขั้นตอนการจัดเก็บ แต่ฉันใช้พวกเขาในเงื่อนไขเดียว:

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

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

แต่มนุษย์พวกเขาจัดการแย่มาก ฉันหลีกเลี่ยงพวกเขาให้มากที่สุด

proc ที่เก็บไว้ของ SQL จะไม่เพิ่มประสิทธิภาพของแบบสอบถาม

เห็นได้ชัดว่าการใช้วิธีการเก็บมีข้อดีหลายประการกว่าการสร้าง SQL ในรหัส

1. การติดตั้งโค้ดและ SQL ของคุณนั้นไม่ขึ้นกับใคร
2. รหัสง่ายต่อการอ่าน
3. เขียนครั้งเดียวใช้หลายครั้ง
4. แก้ไขครั้งเดียว
5. ไม่จำเป็นต้องให้รายละเอียดภายในแก่โปรแกรมเมอร์เกี่ยวกับฐานข้อมูล ฯลฯ

วิธีการจัดเก็บมีเพิ่มเติมบำรุงรักษาเนื่องจาก:

• คุณไม่ต้องคอมไพล์แอป C # ของคุณใหม่ทุกครั้งที่คุณต้องการเปลี่ยน SQL
• คุณสามารถใช้รหัส SQL ซ้ำได้

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

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

ในความคิดของฉันประสิทธิภาพและความปลอดภัยได้รับการบวกเพิ่ม คุณยังสามารถเขียนโพรซีเดอร์ที่เก็บ SQL ที่ไม่ปลอดภัย / ไม่มีประสิทธิภาพ

ง่ายต่อการย้ายไปยังฐานข้อมูลอื่น - ไม่มีโปรแกรมไปยังพอร์ต

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

@Traprapin - sprocs มีความเสี่ยงต่อการถูกโจมตีจากการฉีด ที่ผมกล่าวว่า:

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

ที่ไปสำหรับ sprocs และ SQL แบบไดนามิก

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

@ ผู้ซื้อ - ใช่ถูกแล้ว sprocs ช่วยให้คุณควบคุมผู้ใช้แอปพลิเคชันเพื่อให้สามารถดำเนินการ sproc เท่านั้นไม่ใช่การกระทำพื้นฐาน

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

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

การฉีด SQL สามารถยังคงดำเนินการกับ sprocs เหล่านั้นหากพวกเขา inline รหัสแบบไดนามิกดังนั้นกฎทองยังคงใช้อินพุตของผู้ใช้ทั้งหมดจะต้องเป็นพารามิเตอร์

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

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

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

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

มีการกล่าวถึงคำตอบก่อนหน้านี้มากมายเกี่ยวกับประโยชน์ด้านความปลอดภัยของ procs ที่จัดเก็บ สิ่งเหล่านี้แบ่งออกเป็นสองประเภทกว้าง ๆ :

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

2) การสืบค้น SQL injection / parametrized การคัดค้านนี้เป็นปลาเฮอริ่งแดง Inline SQL - แม้แต่อินไลน์ SQL ที่สร้างขึ้นแบบไดนามิก - สามารถถูก parametrized ได้อย่างเต็มที่เหมือนกับ proc ที่เก็บไว้ใด ๆ และสามารถทำได้อย่างง่ายดายในภาษาสมัยใหม่ที่มีคุณค่า ไม่มีประโยชน์อย่างใดอย่างหนึ่งที่นี่ ("ผู้พัฒนา Lazy อาจไม่ใส่ใจกับการใช้พารามิเตอร์" ไม่ใช่การคัดค้านที่ถูกต้องหากคุณมีนักพัฒนาในทีมของคุณที่ต้องการเชื่อมข้อมูลผู้ใช้ลงใน SQL แทนการใช้พารามิเตอร์คุณต้องพยายามให้ความรู้แก่พวกเขาก่อน หากวิธีนี้ใช้ไม่ได้ผลเช่นเดียวกับที่คุณทำกับนักพัฒนาที่มีนิสัยไม่ดีอื่น ๆ ซึ่งเป็นอันตรายแสดงให้เห็น)

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

ใน DAL ของเราหากเรามีคำสั่ง SQL ที่ซับซ้อนมากโดยทั่วไปแล้วเราจะรวมไว้เป็นไฟล์ทรัพยากรและอัปเดตตามความจำเป็น (ซึ่งอาจเป็นแอสเซมบลีที่แยกต่างหากเช่นกัน

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