|
Posted by Erland Sommarskog on 10/20/05 00:56
serge (sergea@nospam.ehmail.com) writes:
> 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 were in that shop, it would come to blows, if they were to insist
on this.
We have just too many stored procedures of that kind in our system. They
don't do SELECT *, but they return too many column. And there is a serious
maintenance problem with this. Not all data models are perfect, and every
once in a while you find columns that no longer are in use. Or you suspect
are not in use. Or that may be in use, but you want to change how it is
used. To be able to do this, I need to track down all references to
the column, and if the column is selected from some general procedure,
and into the application - or even worse in some external interface, it's
hard to tell.
> 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.
Yes, in the short run, this saves some time. In 4-5 years timeframe,
they are causing an ever-growing burden of legacy problems.
--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp
[Back to original message]
|