January 19, 2011 at 6:59 am
This question is more on architectural basis. We have one gui with three tabs working as a single module and we are operating fuctionality of all with single sproc. Now keeping in mind around thousands of users, would you suggest to break the functionalities to three separate sprocs or let it work that way ? The functionalities of one tab is totally different and two tabs have more or less same functionalities. Also can you tell me which one will be beneficial from performance point of view ?
January 19, 2011 at 7:10 am
No where near enough information to say anything meaningful. Expand please?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 19, 2011 at 7:18 am
My question is simple. Is it better to have single big sproc having functionalities for all the parts of a module or should i break it up into three different sprocs ? Keeping in mind the perofrmance and large number of users using same module multiple times.
January 19, 2011 at 7:20 am
Would you write a single function/procedure in C# (or whatever front-end language that you use) to do every single thing that a specific portion of the system can do?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 19, 2011 at 7:45 am
Well, it depends on a person's perspective (I feel :)). However my point is whether its good to have three different sprocs for three processes or one sproc for all if there is not much difference but compexities are there.
January 19, 2011 at 7:58 am
sql_butterfly (1/19/2011)
Well, it depends on a person's perspective (I feel :)).
Would you seriously consider writing single a C# function that did multiple different things?
However my point is whether its good to have three different sprocs for three processes or one sproc for all if there is not much difference but compexities are there.
A procedure (C#, VB, SQL) should do one thing and one thing only. It's the 'single responsibility' principal of good software design.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 20, 2011 at 6:46 am
I agree with Gail. Targeting functionality for a proc is better than trying to create a catch-all for any number of reasons.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
January 20, 2011 at 8:00 am
Understood. It means as per thumb rule, the funtionality of a sproc should be as specific as possible and we should try to normalize the sproc as well.
January 20, 2011 at 8:05 am
sql_butterfly (1/20/2011)
Understood. It means as per thumb rule, the funtionality of a sproc should be as specific as possible and we should try to normalize the sproc as well.
Just so we're clear, none of used the term "normalize" for procs. I get what you mean, and agree, but I wouldn't use that term in that way. It could lead to confusion.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
January 20, 2011 at 11:31 pm
Yeah. By normalizing the sprocs I meant just the functionality of normalization.
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply