In an attempt to throw the authorities off his trail, jdbeaufoy (AT) hotmail (DOT) com (JohnB) transmitted:
Lots of "OO" databases have come and been ignored.

I think the base problem is that there is very little agreement as to
what "object orientation" truly means, from a theoretical perspective.
"Everyone" is in abject worshipfulness of OO (well, possibly not
_everyone_), but, like the blind men looking at the elephant, there
are quite different ideas out there about the "right" way of having
OO.

In practice, look at the languages out there. A reasonable list of
"important" ones might be:
- C++ (of course, the creator of the influential STL libraries thinks
OO is a huge mistake, so if you use STL, that's likely to bias
things...)
- Java
- Smalltalk (it has been influential, and it _is_ in use...)
- C#
- Perl
- Python

These are hardly a complete listing of "OO" languages; it would be
good to point out others such as Ada (first internationally
standardized OO language, which influenced later ones), Common Lisp
Object System (CLOS), Ruby (which appears to me to have influenced
C#), Eiffel, Modula-3 (influential, if not still popular), Objective
C...

These assorted languages have _very_ different sets of semantics,
different ways of organizing classes, different ways of handling
inheritance.

With the result that someone hoping to create a "Common Object
Database" scheme has a BIG challenge on their hands in mapping it onto
multiple languages.

Sometimes they don't try, and so we see libraries for Java or C++ that
provide "persistance layers" for suitably defined Java classes or C++
classes. Of course, that means _all_ your code has to be written in
the language that got chosen, and the data is all but inaccessable to
scripting tools using other languages.

At the other end of the spectrum, the OMG created a would-be standard,
sort of paralleling CORBA. But a "language neutral" scheme will be,
to some degree, inefficient and hostile to any of the languages used.
You won't be writing _good_ Java, or _good_ C++; you'll have to be
using idioms that aren't natural to any of the languages. Which will
suck.

Then there's the "referencing" problem. OO systems are rife with
references, which really means we're pointing back to the hierarchical
DB schemes of yesteryear, which are what relational databases were
supposed to be improving on.

If you look at the "object relational" systems, there tend to be some
contradictions in terms there, too. Not long ago, there were
proposals on the table to try to improve PostgreSQL's object handling
(it was one of the first O-R databases), which fell into pretty much
nothingness because there wasn't agreement on what could be treated as
a consistent "object model." It's not clear that there's anything
that can be unambiguously identified as an "object" in an O-R DBMS.

If this rambling around sounds a little bit incoherent, then you're
getting the point. Codd and Date did a pretty good job of coherently
describing what it means to have a "relational" database. Reality may
have diverged from the original set of principles, but it nonetheless
cohered enough to support the emergence of big companies/divisions
like Oracle, IBM/DB2, Sybase, Informix, and such, with software that
functions reasonably similarly.

OO and O-R haven't been coherent enough for there to be a clear
"thing" that emerges that can support being a multi-billion dollar
business.
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://www.ntlug.org/~cbbrowne/rdbms.html
Rules of the Evil Overlord #132. "Before appointing someone as my
trusted lieutenant, I will conduct a thorough background investigation
and security clearance. <http://www.eviloverlord.com/>

The steam seems to be rising particularly from the description that
the "relational model is byte-oriented."

Problem #1: That's a nonsensical phrase.

It is usual for an author to try to put a "best foot forward" on the
first page, to state things _clearly_ on that, the most important page
of the entire book.

A gaffe that bad (what on earth does 'byte-oriented' mean, anyways?)
calls into question whether or not the technical reviewers, and
editors did _their_ jobs.

Problem #2: If we replaced the poor wording with a more natural one,
it would _still_ be nonsense.

A better wording of what he _tried_ to say might be thus:

"Relational database systems focus on the physical representation of
data types, where data is characterized as INTEGERS, FLOATS,
CHARACTER VARYING of some particular length, and the likes.
Object-Relational DBMSes put the focus on the kind of data, where
you might instead have a PRODUCT_COUNT, PRICE, or
PRODUCT_DESCRIPTION."

To some extent, that is consistent with a lot of common practice. SQL
DBMSes generally _don't_ have you start by defining a set of
application-specific "types," and then using those types to define
what is in a given record.

We don't get:
create type customer_id character varying(8)
matching regular expression
"[A-Z][A-Z][A-Z][A-Z][0-9][0-9][0-9][0-9]";
create type product_quantity numeric(10,2);

And then define tables like..
create table purchase (
purchasor customer_id,
quantity product_quantity,
item product_id,
order_on timestamp
);

But Darwen and Date quite clearly propose _exactly_ this sort of thing
as being the way relational systems _ought_ to be used.

I don't think the book is necessarily totally nonsense as a result of
all of this.

But what seems more than likely is that the book is little more than a
thinly-veiled sales job to try to convince the reader that
"Object-Relational" is some tremendously original sort of
"post-relational" idea. Which demonstrates profound disrespect for
the original ideas. People never tried very hard to follow Codd's 12
"relational principles;" to call "relational databases" deficient
because of that lack of effort is quite insulting.

If they added the "CREATE TYPE" to SQL, this would NOT make SQL "less
relational;" to the contrary, it would likely make it more strongly
so.

It is, of course, in the interests of some to have you _believe_
otherwise, particularly if that led you to buy their products.
--
output = ("cbbrowne" "@" "cbbrowne.com")
http://www.ntlug.org/~cbbrowne/rdbms.html
Why do they put Braille dots on the keypad of the drive-up ATM?

A long time ago, in a galaxy far, far away, "Abdullah Kauchali" <someone (AT) someplace (DOT) com> wrote:
The steam seems to be rising particularly from the description that
the "relational model is byte-oriented."

Problem #1: That's a nonsensical phrase.

It is usual for an author to try to put a "best foot forward" on the
first page, to state things _clearly_ on that, the most important page
of the entire book.

A gaffe that bad (what on earth does 'byte-oriented' mean, anyways?)
calls into question whether or not the technical reviewers, and
editors did _their_ jobs.

Problem #2: If we replaced the poor wording with a more natural one,
it would _still_ be nonsense.

A better wording of what he _tried_ to say might be thus:

"Relational database systems focus on the physical representation of
data types, where data is characterized as INTEGERS, FLOATS,
CHARACTER VARYING of some particular length, and the likes.
Object-Relational DBMSes put the focus on the kind of data, where
you might instead have a PRODUCT_COUNT, PRICE, or
PRODUCT_DESCRIPTION."

To some extent, that is consistent with a lot of common practice. SQL
DBMSes generally _don't_ have you start by defining a set of
application-specific "types," and then using those types to define
what is in a given record.

We don't get:
create type customer_id character varying(8)
matching regular expression
"[A-Z][A-Z][A-Z][A-Z][0-9][0-9][0-9][0-9]";
create type product_quantity numeric(10,2);

And then define tables like..
create table purchase (
purchasor customer_id,
quantity product_quantity,
item product_id,
order_on timestamp
);

But Darwen and Date quite clearly propose _exactly_ this sort of thing
as being the way relational systems _ought_ to be used.

I don't think the book is necessarily totally nonsense as a result of
all of this.

But what seems more than likely is that the book is little more than a
thinly-veiled sales job to try to convince the reader that
"Object-Relational" is some tremendously original sort of
"post-relational" idea. Which demonstrates profound disrespect for
the original ideas. People never tried very hard to follow Codd's 12
"relational principles;" to call "relational databases" deficient
because of that lack of effort is quite insulting.

If they added the "CREATE TYPE" to SQL, this would NOT make SQL "less
relational;" to the contrary, it would likely make it more strongly
so.

It is, of course, in the interests of some to have you _believe_
otherwise, particularly if that led you to buy their products.
--
output = ("cbbrowne" "@" "cbbrowne.com")
http://www.ntlug.org/~cbbrowne/rdbms.html
Why do they put Braille dots on the keypad of the drive-up ATM?

"Bob Badour" <bbadour (AT) golden (DOT) net> wrote in message :

(Quoting my book)

Bob sweetie, you've been quite coherent on these issues in other places,
so I will apply the Socratic approach.

What is the difference between 'the relational model', and an
RDBMS? Why is an RDBMS 'byte-oriented'? Why can the relational model
never be byte oriented?

How do you propose to model (say) vectors in an RDBMS/SQL system? Can you
explain why the relational model is perfectly suited to handling
vectors?

And my area of experience, can you describe how a query processor that
operates on vectors would need to vary from one which assumes that all
of the query language's domains are ordinal? (Do you know what
ordinal data is? hint: something about mapping to natural numbers).
(Hint on the question: transitivity of operators.)

How are the normal forms defined mathematically? What is redundancy,
and why is it that a set cannot (by definition) have redundant elements?
(Hint: answer involves keys and dependencies.)

This is a poor choice of words, on my part. One slipped by me. I
apologize unreservedly. You got me. Good one. 'The second deficiency is
that the SQL data model suffers . . .'

What is a 'relational table', and how does it differ from a relation?
What does it mean to say 'flat'? (Hint: answer involves planarity and
order, and one of the properties of a SQL/RDBMS table which you ought
to know distinguishes them from relations is that table attributes are
ordered whereas elements of a relation header are not).

For bonus marks, can you name three implementation artifacts
present in the guts of all RDBMS implementaions which are relations
but are not tables? (To clarify the question, lets just say tables
must all have primary keys.)

You have not read the book, and you clearly have not even read the
excerpts (if 'to read' means 'to comprehend').

[ snip ]


Bob, honey, sweetie, you have said *nothing* about my work and still less
about my ability. You have simply labeled me as 'ignorant' and then supplied
a list of quotes which you claim (implicitly) support this conclusion.
Nothing you have quoted is in any way controversial (except for the poorly
phrased observation about structure.)

A man is judged as much by his enemies, as he is by his friends.

All the very best hugs and kisses -

KR

Pb

Bob Badour wrote:
You always bring up that argument and it always is outdated.

Network databases did not match the programming style back
in 1970. They did not supply direct language bindings to
mainstream languages.

Todays object databases are built for Java and C# (and all
other .NET object languages) and the tight coupling between
programming language and database results in:
- less programming code that needs to be written
- only one single scheme/model that needs to be maintained:
classes
- better performance
- the possibility to use automatic refactoring
- simpler deployment

The benefits are:
- lower cost
- faster time-to-market
- faster applications

Time and products may not be ready for enterprise data
management yet but object databases work excellent for:
- embedded use
- rapid prototyping
- use in low-resource systems
- complex or deep class hierarchies
- tree-structured data
In these areas they clearly beat relational databases.


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

Christopher Browne <cbbrowne (AT) acm (DOT) org> wrote

I completely agree, and that's not what I wrote.

'Byte-oriented' (in what I actually wrote) refers to the way physical
properties of data storages come up constantly in RDBMS systems. An
RDBMS's strings have length, and the description of types in the manuals
always say something about how many bytes of storage each type consumes.
Introducing physical properties into a logical model creates design
dilemnas, increases development time and makes maintenance harder, blah
blah blah.

At the bottom of the very first page of the excepts on Amazon
you will find (should you actually bother to look) the following sentences:

"In contrast with the more byte-oriented Relational Database Management
Systems (RDBMS) technology, an object-relational database organizes
the data and behavior of business objects within an abstract data
model. Object-relational query statements deal with objects: personal
name, part code, polygon and video instead of INTEGER, VARCHAR or
DECIMAL data values."

[ snip ]

This is a major theme of the book. The product being described pioneered
the CREATE TYPE ideas. We built it. No one came. End of story.

The book may or may not be a sales job (I suggest you actually read it
and find out for yourself) but it is quite explicit in its description
of ORDBMS technology as a slightly improved implementation of the
relational model.

Please read the book. Please look at the code. Everything in the book
ran in production systems 5 years ago.I mean jeez: you can get the
bloody thing for $2!

The running example in the book is a database where only one of the
data types in the schema is mentioned in any standards document.
All of the other 'types' in the SQL are user-defined, and correspond
to a logical domain identified during conceptual modeling. I show how
to implement support for hierarchies, query-as-a-type, a complete
temporal SQL implementation, show how to create what amounts to a
relational interface to a file-system (ie. SELECT F.filename, F.changedate
FROM FileSystem F WHERE F.dirname = '/home/me' ORDER BY F.changedate
to underscore the points that relations aren't just tables.

Oh whatever. As you can see from how well the book's selling, anything
that tries to describe how to actually do what is advocated by the
world's relational zealots is a bust. (And I count myself among those
zealots. . . .)

I give up. I'm gonna work on XML.

KR

Pb

"Bob Badour" <bbadour (AT) golden (DOT) net> wrote

Yo!

Let's talk a little ignorance here, just a mo -
pull up a chair and catch the flow
'bout a Blunder or two and the Ignorance Rule,
coz' Bob-the-Chimp's a hootin fool.

First fuk-a-upa, Blunder One,
Date said, "If you're gonna have classes, son,
then don't confuse it with a relvar,
do that you'll blow it - HA!"

Well let's take a moment to review
just what the product does really do.
It's got a ROW TYPE -- row structure kinda,
talkin' imprecise -- see what we finda!

It ain't a relation, sonny jim,
if its got some fat tuples, but some is slim.
Tables created in this way
is not relations, no matter what you say.

An' if Bob would read - not jus' shout,
he might have realized (before gettin' word out)
that domain = type was the bigger feature
but he's just not a readin' kinda-creature.
(Been in Postgres since '89, you betcha!)

Second Blunder - here we go,
Date sez "Dem' pointers gotta go!
They got no place at the logical level!
Put 'em in you go to the devil!"

And yo! Take a look! Here's what Bob will find
when he pulls his head from his behind
Sure, SQL-3 says, REF() to ROW
but the product DOESN'T DO IT - NO!

It wasn't hard: it just seemed dumb,
rather work on R-trees, son.
An' no one missed it, least not so far,
'cept Bob, who sees what isn't thar.

So now we got this prize buffoon
'round the rim of some kinda spoon
He don't know shit, and it shows,
everything he says just blows!

Jus' wrappin' up - the Ignorance Rule,
says "He who waves his finger, fool,
gives the rest of us pause to wonder
jus' who's da moron bringin' da blunda!"

(Thank you, thank you, I'll be here all week . . )

"Bob Badour" <bbadour (AT) golden (DOT) net> wrote

Yo!

Let's talk a little ignorance, just a mo -
pull up a chair and catch the flow
'bout a Blunder or two and the Ignorance Rule,
coz' Bob-the-Chimp's a hootin fool.

First fuk-a-upa, Blunder One,
Date said, "If you're gonna have classes, son,
then don't confuse it with the relvar,
do that you'll blow it - HA!"

Well let's take a moment to review
just what the product does really do.
It's got a ROW TYPE -- row structure kinda,
talkin' imprecise -- see what we finda!

It ain't a relation, sonny jim,
if its got some fat tuples, but some is slim.
Tables created in this way
is not relations, no matter what you say.

An' if Bob would read - not jus' shout,
he might have realized (before gettin' word out)
that domain = type was the bigger feature
but he's just not a readin' kinda-creature.
(Been in Postgres since '89, you betcha!)

Second Blunder - here we go,
Date sez "Dem' pointers gotta go!
They got no place at the logical level!
Put 'em in you go to the devil!"

And yo! Take a look! Here's what Bob will find
when he pulls his head from his behind
Sure, SQL-3 says, REF() to ROW
but the product DOESN'T DO IT - NO!

It wasn't hard: it just seemed dumb,
rather work on R-trees, son.
An' no one missed it, least not so far,
'cept Bob, who can see what isn't thar.

So now we got this prize buffoon
runnin' 'round the rim of some kinda spoon
He don't know shit, and it shows,
'most eveything he says just blows!

So! Wrappin' up - the Ignorance Rule,
says "He who waves his finger, fool,
gives the rest of us pause to wonder
jus' who's da moron bringin' da blunda!"

(Thank you, thank you, I'll be here all week . . )

"Paul G. Brown" <paul_geoffrey_brown (AT) yahoo (DOT) com> wrote

One specifies a logical representation of data, and the other manages data
so represented.


No RDBMS implementation is any more or any less 'byte-oriented' than the
product you were shilling. That's what makes your statement a load of crap.


The relational model is a logical representation and not a physical
representation.


Any number of ways including using a vector type generator.


The relational model represents data as typed values in relations--including
values of vector types, if necessary. How is that imperfect?


No, but then again, I don't know why a query processor would make such an
assumption in the first place (other than the fact that all realisable
computer systems are ordinal.) Then again, I don't write books on query
processors. Neither do I write books on Russian literature, the genetics of
c. elegans or a myriad of other topics for which I lack sufficient
expertise.

It seems you lack sufficient expertise with logical data models to make
accurate, informed statements about them or comparing them as your book
attempts to do.


<superfluous description of "ordinal" snipped>

How does repeating a value in multiple relations--as is necessary for
lossless decomposition using project--make a normalized design "free of"
redundancy? It's free of update anomalies caused by specific types of
redundancy, but that's something entirely different. As I said, one load of
crap after another.


If you wanted to make statements specifically about SQL, why would you make
statements about RDBMS instead? They are two different things. When I wanted
to criticize your book and question your suitability as an author of books
on database management, I criticized your book and questioned your
suitability as an author. I did not criticize books and question the
suitability of authors.


Table and relation are synonyms when speaking about an RDBMS. How is an
unordered set of points in an n-dimensional space flat?

As I said: a load of crap.


Yet another load of crap. Some tables in SQL are not relations, and SQL
relies on attribute ordering in some operations, which is why SQL DBMSes are
not strictly speaking RDBMSes. Nevertheless, bags of unordered points in
n-dimensional spaces are neither planar (unless n<=2) nor ordered.

It is absurd to criticise RDBMSes and then rationalize the criticism by
saying you were really criticizing SQL DBMSes for not being RDBMSes.
Especially when the criticism of SQL is not even valid. That's crap squared.


I cannot read your mind, and neither can anyone else reading your book. What
you actually wrote was one load of crap after another. Comprehension is
doubly important for authors. See above.


It does not surprise me that someone who wrote one load of crap after
another would lack the ability to recognize that what he wrote was crap.
Your inability does not improve what you wrote nor does it diminish the
validity of the criticism. I still see nothing to recommend your book.


The quoted texts are certainly not controversial among the ignorant and
misinformed, of which there are far too many in this profession. I don't
expect to find any controversy among the educated and informed regarding my
observations about the loads of crap in your book.

"Christopher Browne" <cbbrowne (AT) acm (DOT) org> wrote


With all due respect, Christopher, the above is a load of crap too.
Relational database management systems focus on the logical representation
of data. What's more, the product described in the book is a network model
dbms because it re-introduces pointers or references, which puts the focus
on location.


SQL failed to include adequate support for domains or user-defined data
types. The statement above attributes a flaw in SQL to relational database
management systems that is in fact caused by SQL's lack of relational
fidelity.


If a text largely propagates ignorance and misinformation regarding
fundamentals, a few correct details won't rehabilitate it. I see nothing to
recommend the book.


That's basically my assessment as well.


I would call it misinforming more than insulting. The misinformation won't
harm Codd, Date et al or any informed, thinking practitioner. The
misinformation harms those whose education is incomplete.