Lord Hasan wrote:
so here i should make 4 procedure 4 these instructions
Well, it depends. Do you access them all together all the time. Or do you need to access them individually. When you display a customer order you will likely need to get a row from the orders table and several rows for each line item in the order. Rather than write two stored procedures, you can combine both SELECTs in to one stored procedure because you are always getting both bits of information at the same time.
Lord Hasan wrote:
so more than hundred procedure
Like I said, 100 stored procedures isn't that much. The system I'm currently working on has well over 300 stored procedures. I've worked on systems with less, and I've worked on systems with much more. When you write, say, C#, do you worry that you are writing thousands of methods? on dozens of classes? Probably, because there is no object orientation in the database and all stored procedures appear together does it seem more daunting. The key, I've found, is to have a good naming convention. That way you can find things easily and you will be able to work out what that stored procedure was you created last year but haven't needed to use since.
Upcoming events: * Glasgow: Introduction to AJAX (2nd May), SQL Server 2005 - XML and XML Query Plans, Mock Objects, SQL Server Reporting Services... Never write for other people. Write for yourself, because you have a passion for it. -- Marc Clifton My website