On Thu, May 06, 2004 at 01:21:28PM -0500, Puneet Kishor wrote: > they are as real a database as one wants them to be. Sure, they don't > support ACID compliance, but I am not sure if they are created by
Ugh, that particular argument is one I should not have started. My apologies to all, and let's just let that one lie. > I have recently created a pretty useful app for a client using > Perl/DBI, DBD-ODBC and Access. Given how fluid the design was > throughout the development, I simply could not have done so with > SQLite because of the lack of an ALTER command. What makes you so dependent on "alter table" in your development? I've done a lot of data modeling work in Oracle, but have only rarely used "alter table" by choice. When I did use it, it was generally carefully tested upgrade scripts which I needed to apply to an existing instance already in Production. When loading test data into a Development instance, I would generally prefer to do that completely from scratch - run all my create scripts, then separately load data in. No alters involved. Hm, however, a different scenario is if you are copying data from Production to a Dev instance for development or testing purposes. In that case, dumping/exporting Production and loading everything right back verbatim into Dev is certainly the easiest way to go, and once you have that in Dev, you ARE going to want to use a lot of "alters"... Is that the situation you find yourself in? I.e., you are not developing something new from scratch, but are making extensive changes to an already system already in heavy Production use? The "export out of Prod, import into Dev", method has many advantages, especially for testing. Its drawback is that it's easy to quickly lose all ability to create your data model from scratch... Unfortunately there seems to be no way to have the best of both worlds. Either you put the extra effort into maintaining SEPARATE create scripts and upgrade scripts, or you lose the ability to do one or the other at all. -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
