Re: Topics in Perl Programming: Table-Mutation Tolerant Database Fetches with DBI

[runrig]

When database fields are removed or switched in position, I call these destructive or positional field mutations. It is clear that Perl code based on array ref fetches will break in the face of such table mutations. On the other hand, hash ref fetches will not fail in this case.

First, switching field positions in a table is usually not a good idea, but should only be a problem when you 'select *' instead of selecting explicit fields. Some say that you should always explicitly select fields, and for efficiency, you should only be selecting the fields that you need anyway. I think selecting into a hashref is still slow, so I'd only do that if speed was not an issue.

[princepawn]

First, switching field positions in a table is usually not a good idea

I agree that it may not be a good idea but in the prototyping stages of a project anything including switching field positions can happen.

And the idea is to hope that the code itself can remain relatively invariant in the face of the design changes that can occur almost daily when a new project is underway.

[swiftone]

But if you select by fields rather than by * as he said, changing the order in the table shouldn't affect your code at all.

[Caillte]

SELECT * FROM blah ORDER BY keyword

Lets face it, most database queries pay little attention to the physical location of the data within the database...

Then again, if we were really wirried about the physical location and order of the information we were accessing would you really argue that a generic database was the best way of storing?