Explicit Column Discussion

(moved from MergingOoAndRelational)

Often an application (or database query) requests an entire record from a database table, even if only some of the columns are going to be used. Some programmers believe this is a bad practice; others disagree.

Advantages of requesting the entire record: Advantages of specifying just the fields that are going to be used: Context / Scalability: Work-arounds:
It can greatly simplify interface code.

How? I can't think of any host language APIs I've worked with that would be affected one way or the other. The fields you need, you mention. The others, you don't.
Long lists of attribute or column names are a yellow-alert CodeSmell related to TooManyParameters.

Agree, as a general principle. However, the number of fields needed by the code running the query is whatever it is; this seems orthogonal to the choice of retrieving more fields than necessary from a query.

If the DBA knows that it is safe to delete a field, the DBA can delete the field without changing the queries.

And how would a DBA "know" this? You have to search through code anyway to find references to such a field. If you find references to a field only in the code, but not in the query itself, you have to study the code enough to backtrack to the query supplying the field -- if in fact the hit was a legitimate reference to the field.

If a query mentions the field explicitly, it will almost always be easier to find the field reference, and recognize it as such quickly and without doubt. (The only exception to this is in code that dynamically builds query strings.) You can then work forward from there to the code that uses the query's results.

This also relates to: The field names are not scattered throughout the SQL code. I find this to be an advantage when refactoring schema, rather than a disadvantage -- particularly if field names have been chosen carefully.

View edit of December 25, 2004 or FindPage with title or text search