On Mon, Mar 30, 2009 at 11:04:06AM -0700, David Fetter wrote:
> On Mon, Mar 30, 2009 at 05:39:19PM +0200, A B wrote:
> > Hi,
> > In the next project I'm going to have a number of colums in my tables,
> > but I don't know how many, they change.
>
> Stop right there. You need to get some sanity into your project,
> either by changing that requirement, or by not using an RDBMS for it.
I'd agree with that sentiment as well.
It's very easy to add columns to relational databases; much harder and
more time consuming is following this through the rest of the software;
and harder still the fuzzier aspects of tying down what's actually
needed, documenting and testing it.
Databases aren't fixed in stone from the minute they're created; columns
come and go, tables come and go. The more information you have at the
beginning the better job you can do initially, but it's also very easy
to over-design. In my experience over-design normally manifests itself
in an over-complication of the design by making the database handle the
few weird exceptions as though it's the normal data. Obviously some
exceptions are useful for the database to know about, but there are some
that it really doesn't matter---determining which is which up front
isn't easy. This is where the "KISS principle" comes in; optimising
a database design so it's easy to add/remove integer columns to/from
tables doesn't sound like a good choice to be making in the long run.
If you don't know what's going on; try leaving the data you're unsure
about in a spreadsheet until you understand it better. It's much easier
that way than rewriting user interfaces every day because somebody
decides that something's changed.
--
Sam http://samason.me.uk/
