Re: Object oriented database

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. Received on Tue Nov 04 2008 - 02:25:20 CET