-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Shahbaz Javeed wrote:
| I've always considered a table definition to be an unordered hash so
| the concept of putting something in the "middle of a table" from that
| view doesn't seem to have a point.
|
| Just my $0.02
I already wrote my motivation, and I'll do again.
In our development environment we have a .sql file
for each table, view, function. The schema creation
is Makefile driven and the development three is
divided in packages / projects. Each project and
packages are composed by various components.
I try to organize the table definition grouping the
homogeneous field together:
Suppose that this is the definition of a table:
CREATE TABLE foo (a1 INTEGER,
~ a2 VARCHAR,
~ ...
~ an FLOAT,
~ b1 ....
~ ...
~ bn ...
);
some time ( fortunately not so often ) you need to add
a field to that table that for homogeneity is a(n+1).
Some time is also not possible to split foo in two tables
for various reasons:
~ - is not possible define multitable constraint, of course
~ is possible with triggers but is more work: a function
~ trigger to maintain and test.
~ - is not possible to define a multitable index and no
~ work around for this, in my knowledge at least.
What we do actually is put that field at the end and not in
his logical place, this because before to apply the new schema
in production I do a diff between the production schema and the
development schema. You can argue that is the diff tool that must
be fixed however is hard to work with a table in production that
is dumped/displayed by various tools: pgaccess, dbvisualizer,
pgadminII/III, enterprise architect, visio,... in a different
way your development table.
This is why in our coding rule we have- New fields must be added at the end.
Regards
Gaetano Mendola
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBOt717UpzwH2SGd4RAuuZAJwKkDVpwgRNI0vQJ4TC7qllQjH5XgCgmrKv
kqwKVVO3ha+FUsQHggyfyvU=
=z9y4
-----END PGP SIGNATURE-----
