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/ -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
