Stored Procs -- use for applications accessing DB's, such as VB or web pages. Create a layer between the DB structure and the applications, force all data access for these applications to use stored procedures.
Views -- use for people who write reports or need to access the data in an ad-hoc manner. Lock down the tables, give rights only to the Views and if possible still try to abstract the DB structure a little so that if it changes, the views will not need to change and existing reports/ad-hoc queries will still work.
but some people use SP's for all access to the data.
Right I'm kind of getting it but regarding report writing couldn't I still use procs instead of views? i.e Instead of using select on a view, use exec a proc. If I created procs instead of views I could still lock down the tables and grant exec permissions to the procs. Wouldn't this be faster as the procs would be pre-compiled.
If you can use SP's for everything then this is the best way to do things.
but sometimes this isn't always possible.
for example, we have users that connect to our data to run their own queries and create their reports, these people don't know how to use stored procedures, so it is easier for a view to be created, they can then query the view.
use SP's all the way if you can.
you're v.lucky if this is the case !
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.