[thelist] Rusty PHP questions...

[Luther, Ron]

Joel D Canfield noted:

> 1. One best practice is to never use SELECT * - could someone explain 
> why, and tell me when this is okay if ever? Right now I am doing this:

>>my primary argument is future needs: listing all the columns makes it 
>>really easy to change from 'select * ' to 'select * except for column 
>>13' which you can't do. it's also self-documenting. right there in
your 
>>code you've got all the column names, when you come back in six weeks 
>>to adjust something.


Hi Tom,

Let me build on Joel's good example.  I think many people view 'select
*' as lazy 
or as fast but somehow less than best practice -- but they don't see any
real 
harm to it, right?  What could it hurt?   ;-)

My guess is that this is probably because they may have 'ownership' of
the entire 
data chain from creation to manipulation to loading and reporting.  They
know 
everything about the data flow and approve or personally make any
changes that 
happen.  They have full control.  That's nice.  But that's not always
the case.

Sometimes you are not the only developer working off that data store.
Sometimes 
you are not the only person or the only group who can affect a change to
the 
table structure.  That is the case where 'select *' gets scary, and why
it's a 
good idea to give up the practice now.  It doesn't "scale" to working on
bigger 
projects with bigger teams ... for potentially bigger money ;-).

* Now, right off the bat, if your design depended on a fixed number of
columns 
or on a specific field structure (e.g. "name" is field # 3 or the total
number 
of fields is divisible by four) then any structural table change has the
potential 
to completely flummox your design and break your app ... And pretty much
generally 
trash years of cumulative work.  Fun Stuff!

* Granted, fields are often added at the end of the table, which can
still wreck 
your design, but usually not as badly.  But rework is always fun, right?

So let's look at a different issue.

* Those newly added db fields may contain confidential information that
should 
not be made available to the audience you are 'select *'-ing to.
Consider an 
extra-net application made available to your suppliers and large
customers.  If 
some dba in another part of the company thinks adding supplier credit
ratings to 
this table is a good idea, then _your_ [select * --> display *]
application 
(perhaps written years before the table change) may suddenly expose the
company 
to legal liabilities ... which is not a conversation you want to be on
the receiving 
end of!

There are a lot of areas; HR applications, Payroll applications, Finance
applications 
where it may turn out to be MUCH more than merely a bad idea to 'select
*'.

It's safest to explicitly call out the fields you intend to use.  [More
readable and 
better documentation too!]  Select * is more than just lazy - it can get
you and the 
company into hot water.


HTH,
RonL.