|
Posted by serge on 10/19/05 19:36
Thank you all for the answers.
If I may continue adding more information as I am learning
by discussing with some of our developers in our shop.
Our developers are using .NET and I know very little .NET.
I am not even an advanced SQL person to know if what
they want to do is actually good and not bad.
Here's what they are doing. They want to use SPs calling
a single common View and in the view return ALL the columns all the
time. Maybe the biggest table we have has 50 columns maximum.
If I can summarize their points:
1- They are writing our application's SDK and they are standardizing
all the SPs by using "SELECT * from View1 WHERE a = b"
2- They will have our application use these SPs.
3- Only if we encounter performance problems they will deal with
accordingly by adding new SPs. Actually before they even select
that approach they will tackle the performance problem as a DBA
issue and not a developer issue. That is they will expect the DBAs
to deal with the performance problem by making changes on the
tables, indexes etc... before the DBAs get to do anything with the
SPs' code.
4- One of their reasons to use this approach is to guarantee that a
developer will not mess up by adding a new column to the UI and
forget to add it also to x number of SPs.
Now they seem confident that their approach is very good and does
not have any known problems now or down the road.
I am skeptical that the way they're looking at this is as simple as
they're explain it and don't have any complications down the road. I am
not an expert in performance so I couldn't even make my argument
about network traffic that is returning all columns for them to consider
as a problem.
What do you think?
Thank you
Navigation:
[Reply to this message]
|