[development] Is "SELECT * FROM ..." ok?

[Ivan Sergio Borgonovo]

On Fri, 13 Feb 2009 01:01:55 -0600
Larry Garfield <larry at garfieldtech.com> wrote:

> So no, not a bug, but I do agree with discouraging it in most
> cases.  The only time you'd want it is if you have a table where
> you expect the columns to be dynamic, which has all sorts of other
> maintenance issues anyway.

+1

It's always a risky bargain between extensibility, maintenance,
performance and clean design.

Tables should be as small as possible.
It helps to keep a clear hierarchy of data and helps performances
because it exploit more locality of the data.
*Somehow* good design tend to produce queries that return most of the
columns.
When you extend tables defined upstream it means you don't trust
upstream design decisions (and it will bite you) or you're very very
tight with resources and you've been bitten by performance problems.

Ideally I don't want to know why Drupal core decided to put those
columns in users. I'd expect they made a general choice that help
extend the user object and keep the base user object as thin as
possible.
I don't want to mess with their decisions, their API, their
responsibility of the cost of building up a base user object,
upgrading it to newer Drupal versions...

*Dynamically* extended tables makes the cost of a service
unpredictable.

Service x add column A, B, C.
Service y add column D, E, F.
...
wooohp.

Explicitly naming columns make refactoring apparently more boring
but definitively more under control.
It promotes better coding making people more aware of what they're
doing.
It makes easier to deploy tests and it makes easier to find places
where you've to refactor.
As with set/get methods in OOP it makes easier to hide where data
are actually coming from.
It gives an order to columns making select easier to reuse correctly.
Not only it helps to spot errors, but it spots them earlier.

The first time you'll have to refactor 100 places where you had to
add a column (say you moved from name -> name + surname) it will
give you a clue there is something that doesn't work with your
design... but at least it will tell you all the 100 places you've to
refactor.

Every time you write a SELECT * it is a missed chance to use grep as
a debugging tool. This alone is worth getting rid of all the SELECT
* and even n.*
And if it is not for debugging purposes it helps to understand the
code (especially for contrib). Where does this stuff come from/is
used...? let's grep it.

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it