On Tue, Feb 13, 2001 at 06:40:30AM -0800, Brent R. Matzelle wrote:
> You might also try dumping the database, dropping and
> re-creating the database, and then hacking the dump to add,
> delete, alter columns. That way the original structure should
> remain intact.
I find that the dump output is a pain to work with. Information that
was concise when first defined ("id_stuff serial primary key") appears
in least common denominator form as separate indexes, sequences,
constraints, etc. And if I'm deleting a column, do I have to write
Perl scripts or the like to strip out the obsolete column data from
the "COPY ... FROM" sections? What a PITA.
A key strategy in Extreme Programming is to make the
system-under-development as amenable to change as possible (while
satisfying current requirements as simply as possible -- an obvious
tension). Some projects may have the luxury of defining the schema
"on paper" once and for all, no changes ever. I've just never seen
such a project in over 20 years professional programming experience.
I'm not advocating _hacking_ a schema into shape, but I do want to
_evolve_ my systems as needed to satisfy my customers' evolving
business needs (and our joint understanding of such).
> I have been in the same situation as you many times where users
> request alterations that can seriously screw up your original
> structure. However, it is your responsibility to inform them
> that any change, no matter how small can require a lot of
> development time.
Or we can improve our tools so that changes aren't so painful to
undertake. PostgreSQL is a damn fine piece of work, and there are
ways that it too could evolve to make it an even more powerful tool
for doing what our customers need done, rather than just what is
convenient for us to do.
[I just got dizzy and fell off my high horse. Oww...]
--
Fred Yankowski fred@OntoSys.com tel: +1.630.879.1312
Principal Consultant www.OntoSys.com fax: +1.630.879.1370
OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA