Re: Object oriented database

On Nov 3, 8:25 pm, David BL <davi...@xxxxxxxxxxxx> wrote:
On Nov 4, 8:17 am, mrto...@xxxxxxxxxx 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.
.

Relevant Pages

  • Re: Databinding - Best Practice (object-oriented)
    ... >> decent database theory introductory book. ... >relational model throughout your application severely restricts the ... >inheritance, interfaces). ... IMO a good OO language must have relational features and a good ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Re: Databinding - Best Practice (object-oriented)
    ... >> decent database theory introductory book. ... >relational model throughout your application severely restricts the ... >inheritance, interfaces). ... IMO a good OO language must have relational features and a good ...
    (microsoft.public.dotnet.framework.windowsforms.databinding)
  • Re: Data Layer architecture
    ... > the first week of>> any serious database course). ... rules were described to be inside the RDBMS, ... is not a theory which states anything about business ... > The Relational Model is nothing but a direct application of set theory ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: WWW/Internet 2009: 2nd CFP until 21 September
    ... afterwards focussed on the application of the relational model to the ... organization of data banks for large scale sharing of data. ... by a single application inside which the database is to be embedded. ... lack of transaction control wasn't really the reason reservation systems ...
    (comp.databases.theory)
  • Re: Table Design Question
    ... > requires more than two probes, no matter how large the database. ... > acceptable (in the relational model) to have an Identity attribute to ... the gap in the sequence is not filled in and the sequence ... > vin CHARNOT NULL REFERENCES Motorpool); ...
    (microsoft.public.sqlserver.programming)