|
|
Posted by Erland Sommarskog on 02/15/06 01:12
Shwetabh (shwetabhgoel@gmail.com) writes:
> But the problem is that this database has to be accessed by a third
> party application which will need to access the required data using
> Partnum as keyword. In such scenario, it becomes neccessary to use
> select * from ... to get the row. How can I help it in such a case?
Why would have you to use SELECT *?
The problem with SELECT * is that it causes a maintenance problem.
You add a colunm, maybe in the middle. Oops, the client did handle
column numbers, and now gets confused. You remove a column, but the
query does not break. But client does.
You should never include more columns in your queries than are are
actually needed. Believe me. I work with a database that has a long
history, and since this still is very much a vital product, we change
the data model to support new features. One problem I often face is
whether a certain column can be dropped or redefined. I can make a
search in which stored procedures it is used, but often I end up in
some general procedure where data goes into the client, or even worse
are exposed in a general API. In many cases, it does not seem to make
sense, and it smells that someone added all columns while he was
at it.
> Also, will it be inefficient to use select * from .. if we have to
> retrieve just 1
> record or is it inefficient if more records have to be retrieved?
The ineffeciency lies in the fact that you may bring bytes over the
wire that no one cares about. There is also a cost for expanding the
* into column names, but that cost is like to be negligible in many
cases.
--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
Navigation:
[Reply to this message]
|