พารามิเตอร์โพรซีเดอร์ที่เก็บมีจำนวนมากเกินไป?

ฉันเพิ่งเริ่มเขียนกระบวนงานที่เก็บไว้ใน SQL Server 2008 และมีพารามิเตอร์มากกว่า 30 รายการ ฉันไม่เคยเขียนหนึ่งที่มีมากกว่า 10 พารามิเตอร์และนั่นทำให้ฉันคิดว่า ... ณ จุดใดมีพารามิเตอร์มากเกินไป?

สำหรับบริบท ... ขั้นตอนนี้จะต้องแทรกแถวเดียวลงในตารางเดียว ก็จะมีความคล้ายคลึงกันมาก แม้ว่าจะค่อนข้างเล็ก เวอร์ชันที่ดำเนินการUPDATEบนตารางเดียวกัน คอลัมน์ส่วนใหญ่มีขนาดค่อนข้างเล็กโดยมีการผสมผสานของ int และ strings ( varchar(200))

ปัญหาคืออะไร; ดีหรือไม่ดี การมีโพรซีเดอร์ที่มีพารามิเตอร์จำนวนมากและเกณฑ์ที่ฉันควรเริ่มพิจารณารูปแบบอื่นคืออะไร

ปัญหา? ฉันจะไม่เถียง

• ขีด จำกัด คือ 2100 พารามิเตอร์ IIRC เป็น 2100 ตั้งแต่ SQL2000 แต่ข้อผิดพลาดของเอกสารแนะนำว่าเป็น 1024
• หากตารางมี 1,000 คอลัมน์ ( ตัวอย่างเช่นการจัดเรียงคอลัมน์แบบกระจายเบาบาง Sharepoint-esque ) และคุณกำลังบังคับใช้การเข้าถึงผ่านขั้นตอนการจัดเก็บไว้โปรแกรมแทรกของคุณอาจมีพารามิเตอร์ 1,000 รายการ ไม่มีอะไรผิดปกติกับที่
• อย่าหยุดทบทวนสคีมาเมื่อคุณพบกับตารางที่มีขนาดกว้าง (ไม่ใช่ 30 ที่มีความกว้างเป็นพิเศษ) ไม่ใช่เรื่องแปลกที่จะพบตารางที่เริ่มต้นชีวิตปกติ แต่ผ่านความเกียจคร้านและ / หรือความไร้มารยาทได้ขยายเกินกว่าการรับรู้
• อย่าคิดสั้น ๆ ว่าจะผ่านชุดพารามิเตอร์เป็นรายการ CSV หรือ XML ทำให้เครื่องมือเพิ่มประสิทธิภาพการค้นหาตาบอดและประหยัดเวลาหรือความพยายามเพียงเล็กน้อย
• อย่าส่งรหัสลูกค้าเพื่อเรียกขั้นตอนด้วยพารามิเตอร์จำนวนมาก เครื่องมือสร้างรหัสเช่นแม่แบบ T4หรือCodeSmithเพื่อช่วยเหลือ

Joe Celko เป็นผู้สนับสนุนรายการพารามิเตอร์แบบยาวซึ่งเขาเขียนเกี่ยวกับรายละเอียดในบทความ สองส่วนนี้:

คำตอบที่ง่ายที่สุดคือการใช้รายการพารามิเตอร์แบบยาวเพื่อสร้างรายการและตารางที่ได้รับภายในส่วนของโพรซีเดอร์ เซิร์ฟเวอร์ SQL สามารถจัดการพารามิเตอร์ได้มากถึง 2100 พารามิเตอร์ซึ่งควรเกินพอสำหรับการใช้งานจริง SQL Server เป็น wimp จริง ๆ ในเรื่องนี้ DB2 สามารถส่งพารามิเตอร์ 32K และ Oracle สามารถมีพารามิเตอร์ 64K

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

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