Re: Object oriented database

On Nov 3, 8:25 pm, David BL <davi..._at_iinet.net.au> wrote:
> On Nov 4, 8:17 am, mrto..._at_tpg.com.au wrote:
>
>
>
> > This was more response than I actually thought I my post would get
> > (first time posting to newsgroups) :-).
>
> > I do apologise if my post falls outside the scope of this group as I
> > might have been looking for a more pragmatic discussion, although the
> > theory interests me.
>
> > My first objective is to create something that fits within the
> > framework of existing programming languages, making it as easy as
> > possible for programmers to use. As I see it, there is enough in
> > common between C++, Java and C# for example to be able to create a
> > common object model.
>
> > Seeing from some posts I might have used the term "object model"
> > wrongly, but I have defined it as the set of classes used by one
> > application. I am not looking to create a "data warehouse" style
> > database that would be used by a wide range of applications, but
> > rather a database / distribution system that is tightly linked with
> > one or just a few applications. The reasoning being that there are a
> > lot of applications that need to store complex data that doesn't have
> > much meaning outside the application itself. From experience, I have
> > seen so many applications that use a relation database just because
> > that happens to be the only or the easiest available choice.
>
> If you're going to make Finite State Machines (i.e. objects) persist
> then I recommend you at least consider the following barriers:
>
> * The difficulty of allowing schema evolution of persistent FSMs
>
> * The need for finding consistent cuts when persisting FSMs
>
> * The contradictory nature of transactions and orthogonal
> persistence
>
> Persisting values instead of FSMs is /much/ easier.

I think there are cases for OODBs, just like there are cases for RDBMSs. Sometimes your data is easily expressed as tables and relations, but OODBs also see uses when the relational model does not apply as much. I would love to have some of the databases services available independent of the relational model when I felt it was an appropriate thing to do, and most RDBMs's would probably be able to fufill these purposes, its just that it would be extra work to use the relational model in some cases.

What I actually have ended up doing in a few cases typically some homegrown solution to avoid RDBMs's added expense and effort but to get some of the transaction logging and recovery just by sheer homegrown coding. What we need are some more transaction oriented systems with better programming support rather than just always with the RDBMs stuff.

Lets face it, right now the premier RDBMS environment is SQL. This is sort of a sad state of affairs folks, this is in no way or form a modern language with scoping, code reuse, or any other sort of endearing quality. While many commercial and open source databases bring in more modern language support in some areas, we're essentially saddled with SQL's flat and sad namespace and at least in my case, ducktyped anonymous column naming just to get the same sort of flexibility any decent pick system gives you by default.

RDBMS purists tend to always want the relational algebra, without considering that some folk sometimes just might want regular arithmetic instead. Received on Thu Nov 06 2008 - 02:09:29 CET