What's the big deal? Why use them as opposed to coding the procedures in your app?
Printable View
What's the big deal? Why use them as opposed to coding the procedures in your app?
Depending on what you're doing, they can be faster and lighter on resources. They're most useful if you combine multiple tables into a single data pull- makes it so you only have to make a single call to your database. If you do everything in your app, say through LINQ to SQL, you're actually pulling all of the data over and then sorting it on your application's side instead of letting the server handle it.
Okay, in that case, it seems only useful for conserving resources (speed). However, if you have a small database (not like CitiGroup, or something), it doesn't seem then that stored procs are helpful in a material way.
I thought there was a possibility that they helped in some other way, but if not, I will not plan to use them.
It depends on the architecture. If you are using a local database, it probably doesn't much matter.
If you are working on the enterprise level, you might want the interface layer between the client (app or service) and the database that stored procedures provide.
If you perform all the crud operations behind sprocs, then you may have the flexibility of changing the schema without having to recompile the client code.