OK, from the DBAdmin I used to work with, here are the
in reply to Topics in Perl Programming: Table-Mutation Tolerant Database Fetches with DBI
- In a select, "*" had better have count() around it.
- If you change a field to be more restrictive, you
had better be sure your code checks for insert errors.
- If you make a field less restrictive, your select
code had better be robust.
- Change the order of the fields? WHY? It's a database,
not a text file!
- If you change the name of a field or delete one,
change the name of the table. You can leave a view behind
if you don't want to fix your code.
Really that last one is the real answer. Write your
code to views, not tables.
If the tables are still in flux, what are you doing writing
production level code? Worries about posistion are naive,
views and clean selects fix that at the database level.
Your code depends on the DB, if you can't trust the DB to
behave, you are sunk, period.
The short answer to your problems is: select from views
and with field names, don't try to fix your DB mistakes
with code, forget what order your fields are in, finish
the DB design before you write final code.
You might also try factoring out the DB access into a
nice local module so you can move common actions into a
central place where you can change them just once. That way,
at least you can protect the rest of your code from the
changes by interposing a code layer.
$you = new YOU;
honk() if $you->love(perl)