Re: Object databases do have a standard: classes

#1

Costin Cozianu wrote:

Quote:

In case you had any doubts what would be a SQL solution here you have it:

CREATE TABLE Users
( user_id INTEGER NOT NULL PRIMARY KEY,
username VARCHAR NOT NULL,
CONSTRAINT groups_uq UNIQUE (username));

CREATE TABLE Groups
(group_id INTEGER NOT NULL PRIMARY KEY,
group_name VARCHAR ,
CONSTRAINT groups_uq UNIQUE (group_name));

CREATE TABLE r_users_groups (
user_id INTEGER NOT NULL ,
group_id INTEGER NOT NULL,
CONSTRAINT r_users_groups_pk PRIMARY KEY (user_id, group_id),
CONSTRAINT r_users_groups_fk1 FOREIGN KEY (user_id) REFERENCES users
ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT r_users_groups_fk2 FOREIGN KEY (group_id) REFERENCES
groups ON DELETE CASCADE ON UPDATE CASCADE
)

CREATE INDEX r_user_groups_idx1 ON r_user_groups (group_id);

Since my SQL knowledge seems a little bit outdated, I am curious to know
which of the above statements fullfill the following rules:

1. verify if a user belongs to a group
2. list all the users in a group
3. list all the groups for a user
4. add a user
5. add a group
6. add a user to a group

How is the user_id and the group_id generated ?
Are you using a generator or do I have to read first to generate a new id?
How can I create a new user, a new group and add the new user to the group?

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];
);

2. ThisID is a reserved attribute name for Object Identity (= primary
key). ThisID is automatically managed by the DBMS, therefor we do not
need an index for it.

But as Carl said, in your example an OODBMS cannot win (and will not
loose) because there is nothing OO specific. 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 ?

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:

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"

4. Select a group by its name, call its method "Show" and walk through
all its users and call "Show"

best regards,

Adrian.

#2

Costin Cozianu wrote:

Quote:

After a long history of trolling on comp.databases.theory and
comp.databases.object this is by far the worst bullshit you can spin in
one post.

Personal insults are not my level of discussion so I guess
we can end the thread at this point.

Quote:

Whenever I want to do any of the operation memntioned in the challenge
it takes me exactly 1 SQL statement. To "bind it" in Java, I'd only have
to something like
MyApp.dbConnection.execute( statement )

With this approach you are not programming OO.
You are only using Java as your shell for SQL.

Quote:

- You need to load objects from SQL.

Not really.

If you don't care about creating an object representation of
your data, I am absolutely sure you are posting to the wrong
newsgroup.

The relational SQL approach tries to "look at all data at the
same time from the top with one statement".

Object orientation works the other way around:
"Look at the smallest representations and try to solve small
problems, one at a time."

The more complex problems get, the more you benefit from using
object orientation. Your simple challenge clearly is easier to
implement with SQL statements and I already wrote that in my
previous posting.

Here are some more complex problems:

(1) Deep class hierarchies

Quote:

http://groups.google.com/groups?as_u...) t-online.com

(2) Balancing trees
(Hey, you can finally find some of my code that works.)

Quote:

http://groups.google.com/groups?as_u...) t-online.com

(3) Storing a complex class structure

Quote:

http://groups.google.com/groups?as_u...) t-online.com

Feel free to provide SQL solutions.

Here is an example, what can happen when you try to map a complex
OO problem to SQL:

Quote:

http://groups.google.com/groups?as_u...) t-online.com

Some of your other answers to my posting are just blunt insults
and in many cases you are simply wrong. I don't have the time for
"Yes, I am right" discussions.

Quote:

I am sure, there are about 20 more points. I bet Scott Ambler has
listed them somewhere in his papers. I am not an expert at O-R
mapping since I think it's a pain.

That's all very much BS. Scott Ambler doesn't have a clue what a
relational database is, and apparently you don't have any clue also.

I sent Scott an email and he has asked me to direct people to his
site so they can see for themselves:
http://www.agiledata.org/essays/mappingObjects.html

Quote:

If you want to know what a DBMS is, you should definitely read Chris
Date.

It's really funny:

Alfredo
Bob Badour
Costin Cozianu

All of you keep on telling me the same and all of you love to use
personal insults.

I am looking forward to see
Dave Drummond
and
Eric Ezzy
posting here with the same arguments also.

I would love to meet all of you multiple personalities in real life,
to see how many you really are.

I also wonder why Chris Date never posts to newsgroups himself.

Kind regards,
Carl
--
Carl Rosenberger
db4o - database for objects - http://www.db4o.com

#3

Carl,

I posted a simple problem that called for a simple solution.

The bottom line is the fact that your product doesn't provide that
simple solution.

You whine about personal insults, while you started with accusing me of
throwing dirt and lots of other non-sense, including trolling mode as
bad or worse than Bob Badour's.

At least if I ever was insulting you I was merely stating facts.

Carl Rosenberger wrote:

Quote:

Costin Cozianu wrote:

After a long history of trolling on comp.databases.theory and
comp.databases.object this is by far the worst bullshit you can spin in
one post.

Personal insults are not my level of discussion so I guess
we can end the thread at this point.

Whenever I want to do any of the operation memntioned in the challenge
it takes me exactly 1 SQL statement. To "bind it" in Java, I'd only have
to something like
MyApp.dbConnection.execute( statement )

With this approach you are not programming OO.
You are only using Java as your shell for SQL.

Now you have some guts.

It is you that admitted that you can't come up with a decent solution,
and you're accusing me of not programming OO.

First of all, you're not programming at all, you're bullshitting. I
asked you for a simple code sample, and you started one more of your
troll fests.

Therefore I don't think you have any clue what OO programming is.

Quote:

The relational SQL approach tries to "look at all data at the
same time from the top with one statement".

Object orientation works the other way around:
"Look at the smallest representations and try to solve small
problems, one at a time."

I think you seriously need to relearn what OO really is. OO excels at
solving problems by factoring out common abstractions.

You have a product out there for some time, yet all this time you were
unable to find out a decent abstraction for the most basic and most
fundamental problem in creating object models:

- managing many to many relationships

And for the simplest of object models, you come here and whine that it'd
take you 5 days, and then you have the guts to start insulting me. I
write more OO production code in 1 month than you probably ever wrote.

That speaks volumes of your knowledge of OO, and also of your honesty.

You have the wrong idea that if I have this User in my information
model, I should also have User as a Java class. That's not OO, that's
simply bad dogma.

In order for you to have a clue what OO really is you should quit
reading Scott Ambler and the likes (if you read him it's no wonder you
take 5 days for very basic problems), and go back to the basics about
principles of abstraction and object orientation.

Try Object Oriented Programming in the Beta Programming Language by
Nygaard et. all.

#4

Costin Cozianu <c_cozianu (AT) hotmail (DOT) com> wrote

Costin,

Quote:

In case you had any doubts what would be a SQL solution here you have it:

CREATE TABLE Users
( user_id INTEGER NOT NULL PRIMARY KEY,
username VARCHAR NOT NULL,
CONSTRAINT groups_uq UNIQUE (username));

CREATE TABLE Groups
(group_id INTEGER NOT NULL PRIMARY KEY,
group_name VARCHAR ,
CONSTRAINT groups_uq UNIQUE (group_name));

The model could be even more simple because the user_id and group_id
are not necessary. IMO they only introduce unnecessary complexity to
the logical database design.

Alfredo

#5

Alfredo Novoa wrote:

Quote:

Costin Cozianu <c_cozianu (AT) hotmail (DOT) com> wrote

Costin,

In case you had any doubts what would be a SQL solution here you have it:

CREATE TABLE Users
( user_id INTEGER NOT NULL PRIMARY KEY,
username VARCHAR NOT NULL,
CONSTRAINT groups_uq UNIQUE (username));

CREATE TABLE Groups
(group_id INTEGER NOT NULL PRIMARY KEY,
group_name VARCHAR ,
CONSTRAINT groups_uq UNIQUE (group_name));

The model could be even more simple because the user_id and group_id
are not necessary. IMO they only introduce unnecessary complexity to
the logical database design.

Alfredo

Strictly they are part of the problem domain. For example in Unix you
have users and groups with exactly this information content.

#6

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.

The real-world szenarios for OO-databases start from a completely
different point:
Somebody decides to write an application and to use oo-techniques.
That means he will anyway have some classes for users and groups that
implement a proper behavior in memory. The task for the database is to
store and retrieve that data. Her is the place where we can compete if
you like.

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

Kind Regards
Bernd Deichmann, Poet Software

#7

Bernd Deichmann wrote:

Quote:

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.

Bernd, it really a pleasure to see you and some other
object database vendors post here more frequently.

I get the idea, our scene is on the jump to new success.

With Microsoft's transition to .NET we are currently
crossing the line to the object age:
Just about today more than 50% of all new applications
are created with OO techniques.

This should be our chance.

However, I am afraid, we will all have to use the least
common denominator as our standard:

(1) The effort to implement our products' interfaces to
store and load objects are negligible. Whether it's your
transparent persistency...
only one #makePersistent() call
.....or our declarative interface....
#set() stores and updates objects
....it's supersimple for developers to wrap our lean
interfaces into a tiny class, that could delegate to the
right method.

(2) We do have a problem with querying. Some of us hardly
support any queries, some go for JDOQL, some have OQL,
some have a small subset of SQL with proprietary extensions.
I think, SQL is the path into the future for all of us,
whether we like it or not.

In our traditional business, SQL won't really matter.
In the practice of demanding OO applications our present
proprietary querying systems may be a lot more elegant
than SQL.

We will need SQL, to sell to executives, that don't really
understand the technology. "Yes we have a standard, and it's
very strong." will make them happy.

I propose the following object database standard:
(1) Classes
(2) A proprietary wrapper class. Virtually all it needs
is a store(Object) method.
(3) SQL querying

All is there, waiting for us.
....it's easier than XML. :-)

If we all support SQL, we can also offer the command line
features that people like Costin are demanding from us.

My idea with S.O.D.A. was to create a common object querying
interface for our object database products and to build an
SQL layer on top as open source, available for all of us.
Frankly, I understand that a public company with a couple
of millions of revenues does not consider it a good idea to
follow an initiative that appears to be initiated and
supported by a single small competitive startup only. All I
can do is frequently repeat the invitation to join in on
the project:
http://sourceforge.net/projects/sodaquery/

JDO will lock you in on Java.
The complete Microsoft landscape is wide open for us with
..NET and a common object model.

Looking at the vendors represented in the JDO process, I
am sure you will have to keep querying compatible to an
underlying SQL layer.

Object querying can be a lot more intelligent, allowing to
execute object's code during the Query evaluation process.
With a very lean interface we can supply a more advanced
querying functionality than SQL.

Think about it.

Beste Gruesse aus dem heissen Muenchner Sueden nach Hamburg.

Kind regards,
Carl
--
Carl Rosenberger
db4o - database for objects - http://www.db4o.com

#8

Hi Bernd,

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

Bernd Deichmann wrote:

Quote:

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.

Quote:

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 ?

Quote:

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.

Before you jump in and claim that Delphi style of application doesn't
scale, is not OO, and all the others , here are some hard fighures
- 1 man (me)
- full blown accounting system for a non-trivial system (roguhly tens
of millions of dollars), multi-user, OLTP, reports, the whole enchilada
- Delphi, PostgreSql, Excel are the main ingredients .

3 months development time, including production roll-out. Still in use
unmodified after 3 years. Speeds like one screen/associated transaction
per hour or one report per hour are not uncommon. You can't really do
the same with object models.

All that it boils down to in the end is the eternal LOC. It has been
observed repeatedly that the capacity of 1 developer to
produce/assimilate/debug/maintain 1 LOC is roughly the same regardless
of paradigm/programming language (of course, not talking about extremes).

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.

I don't think automatically in terms of "objects" and "persistency
support". I think in terms of problems and solutions. Some information I
might package as objects, other I might look at it as tuples, some areas
are programmed OO, other functionally.

Whatever gives me just a few lines of code and good performance. It's
not always objects.

Quote:

Kind Regards,
Bernd Deichmann, Poet Software

Best regards,
Costin

#9

On Tue, 24 Jun 2003 11:58:05 -0700, Costin Cozianu
<c_cozianu (AT) hotmail (DOT) com> wrote:

Quote:

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 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? They can't be, because they are successful, and beleave it
or not, FastObjects is a major reason for their success.
It all depends on the szenario.

Quote:

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.
Don't think of OODBs as a central data storage of a company.
As long as sharing plain data is the "common sense" and not sharing
objects they can't be in that role.

Quote:

Before you jump in and claim that Delphi style of application doesn't
scale, is not OO, and all the others , here are some hard fighures
- 1 man (me)
- full blown accounting system for a non-trivial system (roguhly tens
of millions of dollars), multi-user, OLTP, reports, the whole enchilada
- Delphi, PostgreSql, Excel are the main ingredients .

3 months development time, including production roll-out. Still in use
unmodified after 3 years. Speeds like one screen/associated transaction
per hour or one report per hour are not uncommon. You can't really do
the same with object models.

Have you tried it? How can you say that?
For me our customers are the demonstration that it can be done.
Most of them are very successful, as already stated above.
Isn't success the important point?

Quote:

All that it boils down to in the end is the eternal LOC. It has been
observed repeatedly that the capacity of 1 developer to
produce/assimilate/debug/maintain 1 LOC is roughly the same regardless
of paradigm/programming language (of course, not talking about extremes).

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.

Quote:

I don't think automatically in terms of "objects" and "persistency
support". I think in terms of problems and solutions. Some information I
might package as objects, other I might look at it as tuples, some areas
are programmed OO, other functionally.

Whatever gives me just a few lines of code and good performance. It's
not always objects.
Completely agree.

Kind Regards,
Bernd Deichmann, Poet Software

#10

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

Quote:

"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.
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.

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.

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?

Kind Regards
Bernd Deichmann, Poet Software