Re: Object databases do have a standard: classes

#11

Hi Costin,

Costin Cozianu wrote:

Quote:

How is the user_id and the group_id generated ?

Externally. It is of no concern to the model. It can be done in the
database with an auto-numbering scheme, but for example it can be done
in the application using a secured number generation.

The IDs are not substitute for object identity, they're part of the
information model. Think Unix users and groups.

Are you using a generator or do I have to read first to generate a new
id?

new javax.util.SecureRandom().nextInt()

should be enough

which might fail in a multi user enviroment and many User-records.

Quote:

How can I create a new user, a new group and add the new user to the
group?

INSERT INTO USERS Values (1,'Adrian');

And so on...

If you add a new user, a new group and this new user to the new group,
you must ensure that the id's are unique.

SecureRandom might fail (if you want to use it in a general way) ->
before you can add, you have to query.

if numbers are auto-generated at the database-server, you need first to
add the user - query its id - add the new group - query its id - add the
user to the group.

if you have a generator at the server, you need to call the generator
twice for the user and the group. than you can add all of them.

anyway you have at least one roundtrip from client to server and back.
for a standard lan this will be in the range of 0.1 - 1 ms (no matter
how fast your server is).

This is not a problem in your example with few groups and users, but if
you take your example as a generic pattern - this is a problem.

That's why in dbGonzales ObjectIDs are generated at the client, but it
is ensured, that the ids are unique system-wide.

Quote:

By the way the declarations in our database dbGonzales, analogue to
your declarations, would be:

create class User (
ThisID TObjectID;
UserName String;
);

create class Group (
ThisID TObjectID;
GroupName String;
);

create class TUserInGroup (
UserID TObjectID;
GroupID TObjectID;
);

create table Users on User;
create unique index idxUserName on Users (UserName);

create table Groups on Group;
create unique index idxGroupName on Groups (GroupName);

create table UserInGroup on TUserInGroup;
create unique index idxUser on UserInGroup (UserID, GroupID);
create unique index idxGroup on UserInGroup (GroupID, UserID);

Remarks:
1. If you miss the constraints - you are right. Up to the moment we
need to code them in language interface, but this will change in the
near future:

create class TUserInGroup (
UserID TObjectID [ReferenceClass=User];
// or stronger [ReferenceClass=User;RefereceTable=Users]
GroupID TObjectID [ReferenceClass=Group];
);

Is this restricted to Object IDs only ?

since my query engine is not completed yet and i made a fast solution
for the ObjectIDs - yes.

In general, I could use any primary-key/foreign-key pair. But this will
come later.

As long as you develop new applications its ok to live with the
ObjectID. But if you port existing applications it would be desirable to
have a general solution for primary-key/foreign-key relationships.

Quote:

But as Carl said, in your example an OODBMS cannot win (and will not
loose) because there is nothing OO specific.

Well, they loose if they make simple problems difficult. Not that
RDBMSes are winners, they're loosers too in other areas. Just different
kinds of loosers.Which looses worse is a matter of context, and very
fine level of details.

However Carl's argument that object databases save orders of magnitudes
in development time is dishonest. They might be doing that for some
problems, but not in general.

Lets make a small change:

Lets say we have n x m different types of users:

class user_1: user {
attr_1 string
}

...
class user_n: user_n-1 {
attr_n string
}

class user_n_1: user_n {
attr_n_1 string
}
....

class user_n_m: user_n_m-1 {
attr_n_m string
}

and anlogue k x l groups: group_1 .. group_k and group_k_1 .. group_k_l

Any of these user types (classes) can be added to one ore more of
these group types.
Any of these group types can contain a collection of any user type.

How do you formulate your rules in a simple and generic way with SQL ?

In a number of different ways. It depends on m and n.

Fir the purpose of this task, I'd either be using PostgreSQL which
implements table inheritance for free, or more conventionally have n
different tables, one for each type.

object orientated extensions are desirable, aren't they ?

Quote:

But for any n and m sufficiently large, I'd strongly suspect a bad
modeling (either object modeling or relational modeling). Typically a
role based HAS-A mistaken for IS-A relationship.

Agreed.

Quote:

Additionally I would come up with the following task:

Bind these user and group types to corresponding types (classes) in a
high level oo-language of your desire and do following tasks:

I don't automatically bind tables to classes. This is one of the most
serious design mistakes when programming OO applications with relational
databases.

why ?

If you mean persistance, then i agree. But if you have created objects
in your database, why don't map it to objects in your application?

Quote:

A better approach is to represent table metadata using objects.

In dbGonzales we use interface classes which represent the classes in
the database. But you can choose if you work with or without them.
Without its more like with "normal" database. With them, you can use all
the benefits of OO-programming. The overhead for using the interface
classes is zero.

Quote:

1. create a virtual method "Show" for each user class which returns
its classname and all its attr_xxx names and values in one string like:
"class: user"
"class: user_1, attr_1: value_1"
"class: user_2, attr_1: value_1, attr_2: value_2"
"class: user_2_1, attr_1: value_1, attr_2: value_2, attr_2_1: value_2_1"

2. create a virtual method "Show" for each group class which returns
its classname and all its attr_xxx names and values in one string like:
"class: group"
"class: group_1, attr_1: value_1"
"class: group_2, attr_1: value_1, attr_2: value_2"

3. Select a user by its name, call its method "Show" and walk through
all its groups and call "Show"

Create VIEW user_v2 as SELECT userid, username, "attr1: " || atr1 || "
,atr2: " || atr2 as show from user_t2

... and the likes

Create VIEW all_users AS
select * from user_v1
UNION
select * from user_v2
UNION
....

SELECT show FROM user_v1 WHERE username= ?

My mother warned me - Serious abuse of RDMS can damage your brain

But you cannot use this scheme generally - if the method has something
real to do.

best regards,

Adrian.

#12

"Adrian Veith" <adrian (AT) veith-system (DOT) de> wrote

Quote:

Hi Costin,

Costin Cozianu wrote:
By the way the declarations in our database dbGonzales, analogue to
your declarations, would be:

create class User (
ThisID TObjectID;
UserName String;
);

create class Group (
ThisID TObjectID;
GroupName String;
);

create class TUserInGroup (
UserID TObjectID;
GroupID TObjectID;
);

create table Users on User;
create unique index idxUserName on Users (UserName);

create table Groups on Group;
create unique index idxGroupName on Groups (GroupName);

create table UserInGroup on TUserInGroup;
create unique index idxUser on UserInGroup (UserID, GroupID);
create unique index idxGroup on UserInGroup (GroupID, UserID);

Remarks:
1. If you miss the constraints - you are right. Up to the moment we
need to code them in language interface, but this will change in the
near future:

create class TUserInGroup (
UserID TObjectID [ReferenceClass=User];
// or stronger [ReferenceClass=User;RefereceTable=Users]
GroupID TObjectID [ReferenceClass=Group];
);

Is this restricted to Object IDs only ?

since my query engine is not completed yet and i made a fast solution
for the ObjectIDs - yes.

In general, I could use any primary-key/foreign-key pair. But this will
come later.

As long as you develop new applications its ok to live with the
ObjectID.

Many people would disagree that its ok even when developing new
applications.

Quote:

But as Carl said, in your example an OODBMS cannot win (and will not
loose) because there is nothing OO specific.

Well, they loose if they make simple problems difficult. Not that
RDBMSes are winners, they're loosers too in other areas. Just different
kinds of loosers.Which looses worse is a matter of context, and very
fine level of details.

However Carl's argument that object databases save orders of magnitudes
in development time is dishonest. They might be doing that for some
problems, but not in general.

Lets make a small change:

Lets say we have n x m different types of users:

class user_1: user {
attr_1 string
}

...
class user_n: user_n-1 {
attr_n string
}

class user_n_1: user_n {
attr_n_1 string
}
....

class user_n_m: user_n_m-1 {
attr_n_m string
}

and anlogue k x l groups: group_1 .. group_k and group_k_1 .. group_k_l

Any of these user types (classes) can be added to one ore more of
these group types.
Any of these group types can contain a collection of any user type.

How do you formulate your rules in a simple and generic way with SQL ?

In a number of different ways. It depends on m and n.

Fir the purpose of this task, I'd either be using PostgreSQL which
implements table inheritance for free, or more conventionally have n
different tables, one for each type.

object orientated extensions are desirable, aren't they ?

No. I have no interest in "table inheritance". I want type inheritance.

Quote:

But for any n and m sufficiently large, I'd strongly suspect a bad
modeling (either object modeling or relational modeling). Typically a
role based HAS-A mistaken for IS-A relationship.

Agreed.

Additionally I would come up with the following task:

Bind these user and group types to corresponding types (classes) in a
high level oo-language of your desire and do following tasks:

I don't automatically bind tables to classes. This is one of the most
serious design mistakes when programming OO applications with relational
databases.

why ?

Because classes are types and tables are not types.

Quote:

If you mean persistance, then i agree. But if you have created objects
in your database, why don't map it to objects in your application?

"Object" is not well-defined. If you mean an identifiable time-varying value
of some class (type), then the values in tables map to objects in your
application.

#13

"Bernd Deichmann" <bernd.deichmann (AT) poet (DOT) de> wrote

Quote:

On Tue, 24 Jun 2003 18:25:25 -0400, "Bob Badour" <bbadour (AT) golden (DOT) net
wrote:

"Bernd Deichmann" <bernd.deichmann (AT) poet (DOT) de> wrote in message
news:rcogfvko7tke858j4bkph8lhd2odrud589 (AT) 4ax (DOT) com...
Hi Costin,

your challange proves absolutely nothing.

Whether a OODB or a RDBMS or whatever is the best solution for a given
task depends among others on the question how you _want_ to model your
data/classes.

A lot of people think that oo-modeling is a good idea, I agree with
them. Carl already argued that your model is very trivial and does not
show the advantages of oo-modeling, but that is not the point:
A OODB is an appropriate solution if you have objects that you want to
store.

Looking at your challange we could now discuss whether oo-modelling
makes sense or not, but I am absolutely not interested in that point.

In other words, you accept on faith that OODB is the appropriate solution
and you are not open-minded to other suggestions.

No, I am just not an oo evangelist.
I never claimed that everything should be done object oriented.
I am almost twenty years in the business now, programmed in assembler,
C, C++, Delphi, Java and so on.
I learned that object oriented modelling is a very very good
technique.

A very, very good technique for what though? As an engineering method for
writing programs, I agree it has advantages over assembler or C. I see no
reason to conclude it offers any advantages for data management, and I can
foresee improvements over the location-based object programming model even
for writing programs.

Quote:

But it is a clear overkill for just a simple user/group szenario.

I only say that if you do it object oriented you should always
consider using an OODB.

For data management? I disagree. The network model OODB products are simply
not very good for data management for all the same reason earlier network
model products were no good.

Quote:

The real-world szenarios for OO-databases start from a completely
different point:
Somebody decides to write an application and to use oo-techniques.

The real-world scenario for database management starts from observing
that
data must serve the needs of multiple applications.

There are enough real world szenarios for both of us.
Some need a central data storage in their company, some need a
database that supports the needs of their application.

History has shown that limiting data to a single application is invariably a
bad decision.

Quote:

OODBs are made to support oo applications, not command line tools.

That's a rather pointless statment. An rdbms is made to support all
applications.
But the are not the best solution in all areas. Can you agree?

RDBMSes are the best overall solution we have for all areas of data
management. Can you agree?

#14

Bob Badour wrote:

Quote:

"Adrian Veith" <adrian (AT) veith-system (DOT) de> wrote in message
since my query engine is not completed yet and i made a fast solution
for the ObjectIDs - yes.

In general, I could use any primary-key/foreign-key pair. But this will
come later.

As long as you develop new applications its ok to live with the
ObjectID.

Many people would disagree that its ok even when developing new
applications.

You must have an Object Phobia ?!

Or how can you explain, that anytime you fall over the word "object" you
start bashing.

If i had called the ObjectID surrogate key, you wouldn't have wasted
your time to post.

BTW is it an (valuable) argument, that many people would disagree ?

But one thing is sure:

If someone writes "object" -> Bob disagrees.

Quote:

Any of these user types (classes) can be added to one ore more of
these group types.
Any of these group types can contain a collection of any user type.

How do you formulate your rules in a simple and generic way with SQL ?

In a number of different ways. It depends on m and n.

Fir the purpose of this task, I'd either be using PostgreSQL which
implements table inheritance for free, or more conventionally have n
different tables, one for each type.

object orientated extensions are desirable, aren't they ?

No. I have no interest in "table inheritance". I want type inheritance.

Yeah, that would help in this problem. Could you explain why?

Quote:

Additionally I would come up with the following task:

Bind these user and group types to corresponding types (classes) in a
high level oo-language of your desire and do following tasks:

I don't automatically bind tables to classes. This is one of the most
serious design mistakes when programming OO applications with relational
databases.

why ?

Because classes are types and tables are not types.

The values of the rows of the tables in any database are typed,
according to the types of the columns.

Quote:

If you mean persistance, then i agree. But if you have created objects
in your database, why don't map it to objects in your application?

"Object" is not well-defined. If you mean an identifiable time-varying value
of some class (type), then the values in tables map to objects in your
application.

To put it correct. The properties of the objects in the application are
mapped to the corresponding columns of the tables. The property-values
reflect the values of the selected rows.

best regards,

Adrian.

#15

"Bernd Deichmann" <bernd.deichmann (AT) poet (DOT) de> wrote

Quote:

On Wed, 25 Jun 2003 15:31:00 -0400, "Bob Badour" <bbadour (AT) golden (DOT) net
wrote:

"Bernd Deichmann" <bernd.deichmann (AT) poet (DOT) de> wrote in message
news:ramifvo9gl0gph25cr8u7bsf0tuugu1rbl (AT) 4ax (DOT) com...
On Tue, 24 Jun 2003 18:25:25 -0400, "Bob Badour" <bbadour (AT) golden (DOT) net
wrote:

"Bernd Deichmann" <bernd.deichmann (AT) poet (DOT) de> wrote in message
news:rcogfvko7tke858j4bkph8lhd2odrud589 (AT) 4ax (DOT) com...
Hi Costin,

your challange proves absolutely nothing.

Whether a OODB or a RDBMS or whatever is the best solution for a
given
task depends among others on the question how you _want_ to model
your
data/classes.

A lot of people think that oo-modeling is a good idea, I agree with
them. Carl already argued that your model is very trivial and does
not
show the advantages of oo-modeling, but that is not the point:
A OODB is an appropriate solution if you have objects that you want
to
store.

Looking at your challange we could now discuss whether oo-modelling
makes sense or not, but I am absolutely not interested in that
point.

In other words, you accept on faith that OODB is the appropriate
solution
and you are not open-minded to other suggestions.

No, I am just not an oo evangelist.
I never claimed that everything should be done object oriented.
I am almost twenty years in the business now, programmed in assembler,
C, C++, Delphi, Java and so on.
I learned that object oriented modelling is a very very good
technique.

A very, very good technique for what though? As an engineering method for
writing programs, I agree it has advantages over assembler or C. I see no
reason to conclude it offers any advantages for data management, and I
can
foresee improvements over the location-based object programming model
even
for writing programs.

But it is a clear overkill for just a simple user/group szenario.

I only say that if you do it object oriented you should always
consider using an OODB.

For data management? I disagree. The network model OODB products are
simply
not very good for data management for all the same reason earlier network
model products were no good.

The real-world szenarios for OO-databases start from a completely
different point:
Somebody decides to write an application and to use oo-techniques.

The real-world scenario for database management starts from observing
that
data must serve the needs of multiple applications.

There are enough real world szenarios for both of us.
Some need a central data storage in their company, some need a
database that supports the needs of their application.

History has shown that limiting data to a single application is
invariably a
bad decision.

There is some truth in it. Therefore most OODB vendors offer addons to
open the database for other programs. FastObjects has a ODBC driver
for this purpose. It currently offers a simple mapping of extents ( =
all objects of a certain class) to tables.

Considering that your product is basically limited to 1-ary relations, I
find it very constraining, and I do not see how this provides an effective
method to manage data for multiple applications. Basically, all applications
have to contort to meet some common denominator or to swallow an
inappropriate design optimized for a different application.

Quote:

In the near future we will
offer an extended version of this interface that gives full control to
the application. The application can define the views that are
offered, can create calculated fields and can verify every data that
is written to the database. This means that the data verification
mechanisms of a class (usually the get-methods) can be used and there
is no open "backdoor" for improper data. Everything is controlled by
the object itself as it should be in a proper OO model.

In other words, everything requires someone to write some form of procedural
application for every possible update or query, and I point out that it is
generally very difficult, if not impossible, to write generic methods that
suit all applications.

Quote:

OODBs are made to support oo applications, not command line tools.

That's a rather pointless statment. An rdbms is made to support all
applications.
But the are not the best solution in all areas. Can you agree?

RDBMSes are the best overall solution we have for all areas of data
management. Can you agree?

Maybe yes, depends on your definition of data management.
Same is true for other statements you made above.
But I have the strong feeling that this definition does not have much
to do with the problems OODBs try to solve.

Oh, I would not be so sure about that. If the DB part of the name has any
real meaning and is not just hype, database management is probably required.

#16

"Adrian Veith" <adrian (AT) veith-system (DOT) de> wrote

Quote:

Bob Badour wrote:
"Adrian Veith" <adrian (AT) veith-system (DOT) de> wrote in message
since my query engine is not completed yet and i made a fast solution
for the ObjectIDs - yes.

In general, I could use any primary-key/foreign-key pair. But this will
come later.

As long as you develop new applications its ok to live with the
ObjectID.

Many people would disagree that its ok even when developing new
applications.

You must have an Object Phobia ?!

No, I have an informed opinion regarding pointers.

Quote:

Or how can you explain, that anytime you fall over the word "object" you
start bashing.

It is not "object" I object to but pointers, and the general sloppiness
surrounding the word.

Quote:

If i had called the ObjectID surrogate key, you wouldn't have wasted
your time to post.

That depends on what you said about surrogate keys. I would most definitely
have posted had you made some mindless recommendation like always using a
surrogate key. In the end, though, a natural key is nothing more than a
familiar surrogate.

OID's are inaccessible and basically useless for users as anything but
pointers.

Quote:

Any of these user types (classes) can be added to one ore more of
these group types.
Any of these group types can contain a collection of any user type.

How do you formulate your rules in a simple and generic way with SQL ?

In a number of different ways. It depends on m and n.

Fir the purpose of this task, I'd either be using PostgreSQL which
implements table inheritance for free, or more conventionally have n
different tables, one for each type.

object orientated extensions are desirable, aren't they ?

No. I have no interest in "table inheritance". I want type inheritance.

Yeah, that would help in this problem. Could you explain why?

Type inheritance is useful, and I have seen no good use of "table
inheritance".

Quote:

Additionally I would come up with the following task:

Bind these user and group types to corresponding types (classes) in a
high level oo-language of your desire and do following tasks:

I don't automatically bind tables to classes. This is one of the most
serious design mistakes when programming OO applications with
relational
databases.

why ?

Because classes are types and tables are not types.

The values of the rows of the tables in any database are typed,
according to the types of the columns.

Tuples have both a declared type and a most specific type base on the types
of the attributes. I do not see how that makes table inheritance
particularly useful. I suggest we first focus on things we know are useful
citing the "Principle of Cautious Design".

Quote:

If you mean persistance, then i agree. But if you have created objects
in your database, why don't map it to objects in your application?

"Object" is not well-defined. If you mean an identifiable time-varying
value
of some class (type), then the values in tables map to objects in your
application.

To put it correct. The properties of the objects in the application are
mapped to the corresponding columns of the tables.

I disagree regarding the "correctness" of the above. Values map to values
and types to types. You are trying to map values to composite values and
types to sets.

It makes little sense to insist on doing things the wrong way and then
complain that things don't seem to match up. That's the essense of a straw
man.

#17

<snip>

Quote:

Considering that your product is basically limited to 1-ary relations, I
find it very constraining, and I do not see how this provides an effective
method to manage data for multiple applications. Basically, all
applications
have to contort to meet some common denominator or to swallow an
inappropriate design optimized for a different application.

<snip>

Quote:

In other words, everything requires someone to write some form of
procedural
application for every possible update or query, and I point out that it is
generally very difficult, if not impossible, to write generic methods that
suit all applications.

You are correct. And perhaps this is the root of your disagreement: OODB
apps are OO apps with a persistence layer; they don't pretend to offer a
datastore that can be accessed from other applications. It's an obvious
limitation, but also a very conscious trade off: tight application binding
in exchange for lower object decomposition overhead.

Our Smalltalk application and GemStone/S database are one and the same. We
think of the objects 'living' in the database and 'moving' to the client
when it's appropriate. We do separate object responsibilities between
UI<>controller<>domain, but persistence is just there. The added cost of
having an explicit domain<>datastore layer is not worth it (we've done
both).

So, to put it another way, use the right tool for the job: if you want a
generic data storage layer that is accessible from many applications, use a
RDB. If you want to avoid the object decomposition costs of an OO<>RDB
layer and/or you want the modelling flexibility that an OODB provides, use
one.

The application needs should drive the design decision: not everything is a
nail.
--
Bob Nemec
Northwater Objects

"The pencil is mightier than the pen" Robert M. Pirsig

#18

Hi Bob,

Bob Badour wrote:

Quote:

"Adrian Veith" <adrian (AT) veith-system (DOT) de> wrote in message
news:bde7a7$jld$02$1 (AT) news (DOT) t-online.com...

Bob Badour wrote:

"Adrian Veith" <adrian (AT) veith-system (DOT) de> wrote in message

since my query engine is not completed yet and i made a fast solution
for the ObjectIDs - yes.

In general, I could use any primary-key/foreign-key pair. But this will
come later.

As long as you develop new applications its ok to live with the
ObjectID.

Many people would disagree that its ok even when developing new
applications.

You must have an Object Phobia ?!

No, I have an informed opinion regarding pointers.

Sometimes reading is not enough - understanding is better.

I was not talking about pointers, I was talking about the ObjectIDs in
our database.

The difference is:

- these ObjectIDs are value based.
- They are not bound to a specific context.
- They are bidirectional.
- They do not point, they identify (guess why they are called IDs).
- If you have natural keys, you don't need them.
- If you need a automatic generated surrogate key, you can use them
instead.
- They can be generated more quickly, because the values are generated
without roundtrip client/server.
- The algorithm that generates the values, allow the underlying
primary-key indexes to have a fill-factor of about 90% without any cost
intensive balancing methods.

= they are an optimized version of automatic generated surrogate keys -
thats all (allmost).

- Since this is their only purpose, the database knows how to handle
them, without any/little additional syntax (which is/was more a benefit
for me as programmer).
- For example, with an special operator you can use the foreign-key
field as an syntactical replacement for a join operation like:

select * from UsersAndGroups
where userId::Name = "XXX"

(this is not a big thing, but it is handy)

- Or, if they are used as foreign-keys, the database could use an
optimized access path without violating physical independance.

- All these enhancements could be used with any foreign-keys, but then i
need a special syntax - which I don't have at the moment. Thats why I
stated "As long as you develop new applications its ok to live with the
ObjectID".

Quote:

Or how can you explain, that anytime you fall over the word "object" you
start bashing.

It is not "object" I object to but pointers, and the general sloppiness
surrounding the word.

Your problem, not mine.

Quote:

If i had called the ObjectID surrogate key, you wouldn't have wasted
your time to post.

That depends on what you said about surrogate keys. I would most definitely
have posted had you made some mindless recommendation like always using a
surrogate key. In the end, though, a natural key is nothing more than a
familiar surrogate.

OID's are inaccessible and basically useless for users as anything but
pointers.

See above.

Quote:

Any of these user types (classes) can be added to one ore more of
these group types.
Any of these group types can contain a collection of any user type.

How do you formulate your rules in a simple and generic way with SQL ?

In a number of different ways. It depends on m and n.

Fir the purpose of this task, I'd either be using PostgreSQL which
implements table inheritance for free, or more conventionally have n
different tables, one for each type.

object orientated extensions are desirable, aren't they ?

No. I have no interest in "table inheritance". I want type inheritance.

Yeah, that would help in this problem. Could you explain why?

Type inheritance is useful, and I have seen no good use of "table
inheritance".

Because you haven't seen any good from "Heaven", it does not imply that
"Heaven" is not good.

But our database doesn't have table inheritance, it has typed tables and
type inheritance for these types. - The tuples of the tables can have
inherited types.

You could write rules for these types, and any table which is based on
that type inherits these rules. Since it is OO you could override these
rules if you need a special behaviour.

For example, if you have once solved the User and Group problem in a
generic way, you could reuse the User and Group classes anytime you need
a similar solution - just by enhancing the classes User and Group.

For me, generic solutions and reusing these solutions are benefits.

Quote:

Additionally I would come up with the following task:

Bind these user and group types to corresponding types (classes) in a
high level oo-language of your desire and do following tasks:

I don't automatically bind tables to classes. This is one of the most
serious design mistakes when programming OO applications with

relational

databases.

why ?

Because classes are types and tables are not types.

The values of the rows of the tables in any database are typed,
according to the types of the columns.

Tuples have both a declared type and a most specific type base on the types
of the attributes. I do not see how that makes table inheritance
particularly useful. I suggest we first focus on things we know are useful
citing the "Principle of Cautious Design".

See above.

Quote:

If you mean persistance, then i agree. But if you have created objects
in your database, why don't map it to objects in your application?

"Object" is not well-defined. If you mean an identifiable time-varying

value

of some class (type), then the values in tables map to objects in your
application.

To put it correct. The properties of the objects in the application are
mapped to the corresponding columns of the tables.

I disagree regarding the "correctness" of the above. Values map to values
and types to types. You are trying to map values to composite values and
types to sets.

read it again!

Quote:

It makes little sense to insist on doing things the wrong way and then
complain that things don't seem to match up. That's the essense of a straw
man.

I am not complaining. And the further I get with my work, things seem to
match up very well.

best regards,

Adrian.

#19

"Bernd Deichmann" <bernd.deichmann (AT) poet (DOT) de> wrote

Quote:

On Wed, 25 Jun 2003 15:41:27 -0400, "Bob Badour" <bbadour (AT) golden (DOT) net
wrote:

"Bernd Deichmann" <bernd.deichmann (AT) poet (DOT) de> wrote in message
news:8hjifvcclhhq48hod3soc38liaib17qddp (AT) 4ax (DOT) com...
On Tue, 24 Jun 2003 11:58:05 -0700, Costin Cozianu
c_cozianu (AT) hotmail (DOT) com> wrote:

Hi Bernd,

I appreciate your arguments in favor of OO databases, however I smell
quite a Red Herring, somehow.
hmmm. lets see.

Bernd Deichmann wrote:
On Tue, 24 Jun 2003 07:55:57 -0700, Costin Cozianu
c_cozianu (AT) hotmail (DOT) com> wrote:

But as Carl said, in your example an OODBMS cannot win (and will
not
loose) because there is nothing OO specific.

Well, they loose if they make simple problems difficult. Not that
RDBMSes are winners, they're loosers too in other areas. Just
different
kinds of loosers.Which looses worse is a matter of context, and very
fine level of details.

There seems to be a general misunderstanding about the concepts
of oo-databases:
Java or C++ Objects only exist in the context of an oo-application.

Or a specific language as in some specific databases ? Or a handful of
languages ? Sure, I use some kind of persistence for a specific area
of
my current project, and is *not* a relational databases.

It's just that I don't automatically equate data management with
object
persistence. When to use one versus the other is subject of occasional
troll fests.

I agree, no problem so far.
But OODBs are _made_ to support object persistence. They are based on
the perception that general purpose data management a la RDBMS is not
the best solution in many oo-szenarios.

So, you are saying that OODBMS are not for database management? That
seems
absurd. I assume then that your product is not a DBMS and is only a handy
way of manipulating an application's files. If that is the case, I
suspect

Even if you were right : already this would be an advantage compared
to RDBMS, because they are _not_ a handy way to store/retrieve
objects.

Prove it. Start by proving you understand what an RDBMS is.

Quote:

I don't care about your attempt to split hairs (a german expression,
can one say that in english too?) regarding "database management".
I am absolutely shure that you have a definition in mind that will
never fit for OODBs. But who cares. It solves problems other people
have.

The concept of "database management" is pretty clear from the name. How does
your product support manipulation? Integrity? Security? Consistency?
Recovery? Adaptation?

Quote:

you should be discussing it in a different group. Is there a
comp.object.persistence ?

This IS absurd.

So isn't it pointless to come up with an example that can easily be
implemented without object persistence and then try tro proove that
OODBs can't solve problems?
Can we agree that some other people have different szenarios that
require object persistence? I know of many very successful projects
that use FastObjects as their persistence layer. Do you think they all
are fools?

You haven't given enough information for anyone to conclude whether they
are
fools. Are they trying to use the product for data management? Or are
they
simply using it as a handy way to manipulate their application's files?

Therefore db4o, FastObjects many and other OODBs can only be used by
applications and not on the command line. That means we always have
to
write a small OO-Application (java, c++,...), no matter how small
the
problem is.

That's fine with me. But do I have to write many lines of code for
simple problem ?

Or can I just write one statement, snap some query component , and
some
display component like I can do in VB or DelPhi ?

Basically the only thing one can say is writing an oo program for
your
user/group example is more effort than writing some SQL statements.
So if you are happy with some shell scripts wrapping the SQL
statements: fine!

That's a big Red Herring.

I don't have to be happy writing only shell scripts. I can be happy
writing OO applications, shell scripts, Delphi component based
applications, Crystal Reports -- guess what -- reports, Excel
spreadsheets, run advanced statistic packages.

But you seem to imply that one has to live with only one database
for all purposes.
The typical usage of FastObjects (and most other OODBs I think) is
as a database that is tightly coupled to an application, it is
embedded into the application. From the outside view you only see the
application, not the application and a database.

So, really, one could replace it with an ascii sequential file and there
is
no identified need for data management. These products are just file
processors and not database management systems.

Oh, come on! You really left the level of serious discussion here.

Actually, I stand behind what I said. It was an accurate and informed
assessment based on your suggested use case.

Quote:

However Carl's argument that object databases save orders of
magnitudes
in development time is dishonest. They might be doing that for some
problems, but not in general.

I fully agree with Carls statement as long as we are talking about
oo-applications and persistency support. Maybe he should have made
that point clearer.

That's one big single mistake of OODB vendors. I'm a user, programmer,
architect, leader and what have you.

Why is it a mistake? They support a certain task very good and thats
it! Beleave me, I would be more than happy if OODBs would fit for all
your needs, but they are not designed to do that! They can only work
well if it is about storing objects.

But, and this is the big question, are they at least as good as other
methods for storing objects. I do not think they are good even if one can
make them work.

You may think what you like. Your postings show me that you are not
_willing_ to accept the idea that OODBs can do a good job.

I am willing to consider the idea, and I have evaluated the idea many times.
I have concluded on the basis of informed evaluations that they do a lousy
job for database management. The causes for the lousy job were
well-articulated a quarter century ago during "The Great Debate" so I do not
feel any particular compulsion to repeat them here. Anyone with an open mind can
go look them up for himself.

Quote:

Is it possible that you don't know much about them?

Nope, that's not possible. I have excruciating experience with network model
dbmses, and I have been following the OODBMS crap since I first read Won
Kim's _OO Concepts, Databases, and Applications_ in the late eighties.

Quote:

I can't imagine

That would explain a few things, and I find it very brave of you to admit
it. ;-)

#20

<snip>

Quote:

So, to put it another way, use the right tool for the job:
You don't have the right tool for the job, and you never will while you
delude yourself.

Why the insult?

Quote:

if you want a generic data storage layer that is accessible from many
applications, use
a RDB. If you want to avoid the object decomposition costs of an OO<>RDB
No such costs exist.

Well, that's where we fundamentally disagree. I've done both and the
OO<>RDB model was expensive and limiting.

I'd be happy to show some real world examples, but this thread has
degenerated into personal insults.
I'm done.
--
Bob Nemec
Northwater Objects