Updated: 25/03/2003; 11:27:03 p.m..
Andres Aguiar's Weblog
Right here, right now
        

Martes, 15 de Octubre de 2002

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...

 


2:09:24 PM    comment []

Sam Gentile quoted my post about the Pet Shop application with a title that is a little unfair to the MSDN guys that just copied the Sun's J2EE database structure ;)

One of the most interesting issues in PetShop's database design is that there are several tables with the same primary key. Even if there could be some cases where you want to do that, that's usually a bad design, and it's probably caused by the naive mapping between objects and database tables that OO programmers usually do, which is mapping each class to a table.

EJB applications usually have a table for each Entity Bean, and as they had several entity beans that model parts of the 'User', they ended with 3 tables with the UserId as a primary key.

By the way, the article is now on HTML.


1:53:45 PM    comment []

© Copyright 2003 Andres Aguiar.
 
October 2002
Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    
Sep   Nov



Click here to visit the Radio UserLand website.

Subscribe to "Andres Aguiar's Weblog" in Radio UserLand.

Click to see the XML version of this web page.

Click here to send an email to the editor of this weblog.