Milan Babuskov wrote:

> Mike Dewhirst wrote:
>> Database refactoring has been of great interest to me for long time.
>> Largely because I have never been able to foresee requirements far
>> enough ahead to ever get the design right first time.
>>
>> This link is an essay (five minute read) by Martin Fowler on the topic.
>>
>> http://www.martinfowler.com/articles/evodb.html
>>
>> Does anyone in this group know of the availability of scripts/tools
>> described in the essay for Firebird projects?
>
> You can use FlameRobin's loggin feature to collect .sql scripts of DDL
> and DML changes while developing. It has fine-grained control over the
> logging process (DML/DDL, use multiple or single file, log SET TERM for
> isql usage, etc.)

I downloaded FlameRobin a year or two ago but didn't put much effort
into it. Since then I have not had time to think about RDBMS or even
play with Firebird. Now I must get back into it and I'll have another look.

> In contrast to what Fowler proposes, I rather keep all the changes
> (incremental sql scripts) in common source-code control repository
> (Subversion in my case) as a bunch of small plain-text files - each
> containing a single DDL or DML change.

I think that's exactly what Fowler is advocating in terms of versioning.
It is certainly exactly what I want to do.

> I have developed few PHP scripts:

You should try Python :)

> - to run those .sql scripts to update the database to given version.
> - to manage those script files (move version number, rename, etc.)

I think that is extremely valuable. Would you care to open source them?
The design goals for such scripts would be exactly what I'm looking for.

> Given the fact that scripts are stored in central Subversion repository,
> there is no need for "master" database, and also no need for all those
> mechanisms to keep developers informed about changes. You just use
> standard update/commit/diff/etc. commands against Subversion to get all
> the information.

Quoting from Fowler's article ... "We automatically update everyone on
the project whenever a change is made to the database master. The same
refactoring script that updates the master automatically updates
everyone's databases. When we've described this, people are usually
concerned that automatically updating developers databases underneath
them will cause a problem, but we found it worked just fine."

This tells me that anyone can update the master after writing the
refactoring script, testing in the sandbox and committing the script. As
soon as everyone updates from the repository, everyone's database is
automatically updated and their tests and code either passes or fails
and problems get fixed quickly.

Personally, I like the idea of a "master" or reference database. It lets
me blow mine away and get a known good replacement complete with test
data. Maybe the master gets updated last? Like working on a branch and
finally merging to the trunk? Not sure.

Regards

Mike

>