OO Databases and Database Refactoring

Roland Tanglao -Aha! That's what I don't like about relational databases. Static schemas that are impossible to change which makes it alot more difficult to do iterative development!

I've never used an OO database, but as far as I know, refactoring with a OO database is as hard as refactoring with relational databases.

Suppose you have an internet forum app, and you defined a 'Message' class with the following structure:

   Subject,  Date,  UserName,  UserEmail,  Body

Then you decide that you really want to have a User class, so you have a user registration page, etc. So, you have two classes, a Message one :

Subject, Date, Body, User (where user is the other class)

And a User one:

Name, Email

Now, you need to change the structure of the database somehow, and then create User objects with the data that was originally in the Message objects. Then you need to change all the code that used Message.Name to use Message.User.Name (or write an accessor in the Message class to access the UserName).

In relational databases, it involves the same kind of work. Perhaps dealing with DDL statements is more difficult that just changing the classes' structure, but is not much more difficult.

Using DeKlarit, you won't need to write the code that changes the database schema, you won't need to write the code that does the data migration, and you won't need to change the code that uses the 'Message' class, as it will still have the UserName in it.

So, a tool like DeKlarit would be really useful even for OO databases, or, perhaps, OO databases have this stuff built in and I don't know about it...