March 13, 2013 at 10:08 am
fmuzul (3/13/2013)
You gave me an idea :exclamation::someone should suggest to SQLServerCentral to start some form of "competition among developers/DbAdmins". A problem of data manipulation, in a field that people can easily understand, and let people implement a solution using their preferred methods (C++, PHP, Javascript, batch files, with Stored Procedures or not, no limits to the fantasy...).
Then publish them and let people compare, which is simpler, which is faster to implement, which performs better.
It would be very easier to discuss about a real case we all know.
Maybe we could all learn something we don't know.
Bye.
Interesting idea, but all that would be shown is that one method can be found that's quicker than the others for that particular scenario.
Different methods would win in different scenarios - which is why we have different methods, no?
March 13, 2013 at 10:34 am
And if your database is used by more than 1 application? Having all the data manipulation in stored procedures means that multiple applications can use those procs without having to code the same data manipulations in multiple applications and worrying about keeping them in sync when business rules change. And what happens if you live in one of those environments where folks can get to your DB using Access or other such tools and bypass your applications. Using stored procs for all the updating functionality will ensure that the business rules for the database are followed no matter how the update is done.
I guess I come from the school that says the database is responsible for the integrity of the data and all the rules for data integrity should live in the database. That's worked really well for me so far.
Viewing 2 posts - 31 through 31 (of 31 total)
You must be logged in to reply to this topic. Login to reply