[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

OO DB design w.r.t. performance issues



Hello,

I've been thinking long and hard about how to design an OO DB such that it
ends up being scale:able. While it would be nice to be able to reat the
database objects just like any other objects when using them, it would
require manual transaction handling, and it would slow things down
considerably because of the large amount of remote method invokations.

In this case, I am working on a web-based system. The problem lies in
assembling the pages sent to the client. For example, in a list of 50 items
I don't want to make 50 remote calls do the DB. (It's an "organizer" typ web
app; folders, todo items, etc).

The two best options I've thought of are:

(1) Provide a generic interface for running Runnable objects inside the
database. This is fine in an environment (such as mine) where clients are
fully trusted. However, it ads a certain amount of overhead because more
paramters (in particular, the Runnable implementor) needs to be passed (and
hence serialized/de-serialized).

(2) Create some kind of "utility" class (known by the server) and insert an
instance of this class into the DB; with relevant references to other DB
objects. I would then create some kind of container objects for specific
purposes. Eg, I could have a method "public FolderView getFolderView(String
folderid, User user)" that interacts with DB objects inside the server and
returns a pure non-DB object container with the information relevant for
producing a folder view (list of sub folders, todos, or whichever items are
relevant).

While the second choice looses some of it's "elegance" in that application
logic is being performed inside the DB (in a non-dynamic way), I'm leaning
towards it.

What do people usually do in these cases? I'm not really happy with any of
them because both partly undermines the elegance of using an ODBMS in the
first place. But I see no other alternative.

(I've never designed an application for an ODBMS before, in case you
couldn't tell :))

Thanks,

-- 
/ Peter Schuller, InfiDyne Technologies HB

PGP userID: 0x5584BD98 or 'Peter Schuller <peter.schuller@infidyne.com>'
Key retrival: Send an E-Mail to getpgpkey@scode.infidyne.com
E-Mail: peter.schuller@infidyne.com Web: http://scode.infidyne.com