"Alfredo Novoa" <alfredo (AT) ncs (DOT) es> wrote

"In theory, there is no difference between theory and practice, but in
practice there usually is."

I don't think *any* of the ODBMS proponents have ever said there is
something fundamentally wrong with the relational *model*. There was a
thread a while back where I tried to make this point (unsuccessfully, I'm
afraid). However, with the products commercially available today, there are
applications where an ODBMS provides superior performance in both execution
time and development cost to other products (call them SQL-DBMS if you
must). This is the reality with which we application developers live.

There are other data to be managed than the enterprise data warehouse, and
more things to be done with data than generating reports.

I would think the opposite is true. Because they posses the One True Path of
the Relational Model, zealotry abounds. OO practitioners seem to be more
pragmatic to me (perhaps because I am one?)

I've never heard an ODBMS vendor proclaim that their product is superior to
an RDBMS in *every* case, which is the kind of dogma regularly spewed here
by the other side.

We will go way off topic here, but evolution is extremely religious.
Science is about what can be *observed* and *repeated*. Evolution is neither
observable nor repeatable.

Darwin said "The fossil record will prove me out." It has not. Darwin was a
fraud.

If you say so. I thought the Relational Model stood on firmer ground.
--
<disclaimer>
Opinions posted are those of the author.
My company doesn't pay me enough to speak for them.
</disclaimer>
--
Jim Melton
Software Architect, Fusion Programs
Lockheed Martin IS&S
(303) 971-3846

[ I'm going to snip the Darwinism vs. Creationism
from these posts since it is OT ]

Jim Melton wrote:
Amen and Hallelujah! (In keeping with the religious vein
here )

In my world, which may be different from *anyone else's world*
we deal mostly with On-line-transaction-processing (OLTP).
(You want reports? copy the data on to some other box but
don't bother my OLTP!)

We chose an RDBMS for several pragmatic reasons:
1 - people are familiar with it. (No retrining)
2 - it appeared much less painful to do schema
changes which supported applications using
the old and the new schema using the same
data store. (it's still painful, but less so
with the RDBMS).
3 - We needed an "industrial strength" DBMS
which we would not have to debug on the fly.
(Known problems are more easily avoided than
unknown ones.)

In this sense, I am an agnostic. I need to get a job done.
Whatever does it "best" is the technology of choice.
Your definition of "best" may vary, but mine is
"whichever does the job within the functional,
organizational, and performance constraints for
this given project." I have little sympathy for
theory when the theory says I need 40+ table
accesses to process a query, or if the theory
says that the DBMS is going to do a full table
scan behind my back (and take up unknown clock
time in the process).

I do not want the DBMS to be a "black box", I want
to know how to tune the engine and make it hum.
Insofar as I can make an RDBMS hum without violating
normalization, I will. If I can't, I'll start
navigating through it the way I would do with
an OODBMS (or a CODASYL database) and take my
lumps regarding maintenance issues. It's all
a tradeoff. There is NO ONE RIGHT WAY!

[ BTW - that 40+ is not an overstatement. Just today
I was on a call where the someone from the
application development team estimated that they
could only support 10 TPS using a particular DBMS.
I asked "why are you accessing 40 tables to satisfy
this query?"
Them: "how did you know that? It's actually 42."
Me: "I did the arithmetic." ]

No, the "debate" is between the theorists and
the engineers or pragmatists.

Until we get infinite speed CPU's and zero
latency on disk accesses, theory will have
to take a back seat to getting the job done.

This is not to say you do not have to have
a rock-solid Logical Data Model for your application.
It's saying that, once you have that, you
then go and see how that plays in the real
world of the physics of CPU speeds and disk
accesses and make reasoned tradeoffs between
the theory and the practice.

[P.S. - I once computed that to satisfy a particular
report an 8 way outer join would take
about 1800 years to complete on
a 100 MHz processor with 3600 RPM disks.
Even with 10,000 RPM disks, it would have taken
600 years. So much for theory. Time to
go back to the drawing board. ]

--
"It is impossible to make anything foolproof because fools are so ingenious"
- A. Bloch

"Jim Melton" <jim.melton (AT) lmco (DOT) com> wrote in message

In execution time I agree, but in development cost I don't see how.

But OODBMS salesmen say that OODBMS's are ideal for enterprise data
warehouses and generating reports.

But it is a mathematically proved better path. It is like to call
zealots to who posses the one true path of trigonometry.

They seem to be more ignorant and misinformed to me. Most of them can
only think in creating procedural code.

I am one too.

The Relational Model is not superior in a few cases, but it is never
inferior. But it is not dogma, only proved facts decades ago. Read
about the "Great" debate of the 70's.

But as I said many times OODBMS vendors promote the use of the network
model in cases that is evident it is very inferior like in business
systems.

=:-O
:-(

Science has many meanings, but evolution is observable and repeatable,
and we have overwhelming evidences.

Frankly I didn't expect that incredible nonsense from you.

It has, but they are comparable cases because the ground is absolutely
firm in both cases. But what I was trying to say is that The
Relational Model is still very young to be accepted and understood by
the masses.


Regards
Alfredo

Nick Landsberg <hukolau (AT) NOSPAM (DOT) att.net> wrote


A very typical case. The datawarehouse concept consists in that.

SQL-DBMS or pseudo RDBMS.

It is implementation theory. It does not have relationship with the
data model.

If you can't it is because the DBMS vendors failed.

Is this dogma?

No, because the pragmatists say many nonsenses about theory only
because good implementations are not avaiable.

The tradeofs don't exist with with the current state of the art, but
the implementations are not yet avaiable. And it is probable that they
will not be avaiable soon because it is not probable that a wonderful
DBMS would be a commercial success. It would be like to give flowers
to the pigs.

With the Transrelational Model it could take miliseconds.

Some people did and the solution is yet here, and it is impressive.

http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=/netahtml/PTO/srchnum.html&r=1&f=G&l=50&s1='20010000536'.PGNR.&O S=DN/20010000536&RS=DN/20010000536

This is only the begining, it was extended to work with disk based
implementations and for more things.

Regards
Alfredo

Alfredo Novoa wrote:

SQL. Commercial RDBMS. In-memory.
Provides ACID semantics, rollback, logging
and replication to the backup machine.

I think I said that below. You start with an
LDM and make tradeoffs.

Well, that's all we have right now, what's
out there on the market. It does me very
little good to cry in my beer over "what
might have been" or "what might be in the
future." I have to get something usable to my
customers within a few months.

It's meta-dogma.

See above copmment about crying in your beer.
I have to live in the world of delivering
a product and I have to live with the implementations
currently available.

One thing we seem to agree on is that it is
the other one spouting nonsense.

I scanned the patent to which you gave the URL below.
Fascinating.

Being somewhat pragmatic about it, if it will not
a commercial success (as you claim), why should
I worry about it? Oink!

I did the actual arithmetic using the relational
model. Did you actually do the computations
or is this an unsubstantiated claim?

Yes, very impressive. It seems to focus on the
efficiency of queries. It is possible that
I missed it in my cursory scan, but I did not
see anything about the efficiency of updates.
I'll have to go back and check.


--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch

"Nick Landsberg" <hukolau (AT) NOSPAM (DOT) att.net> wrote

It's really very impressive - can't wait for Date's book on TransRelational,
but you can read about it in the 8th edition of Intro to DB Systems.
Mind-blowingly innovative, yet simple. It could revolutionize far more than
databases.

You can't. The model is abstract, and implies little or nothing about
implementation and its efficiency. And in the case of TransRelational,
whatever you infer is probably wrong.

It may be unsubstantiated, but I guarantee your math is wrong. Read about
TransRelational and watch your assumptions about indexing and query
efficiency be shattered - your equations just don't model the way things are
done.

- erk

Eric Kaun wrote:

I infer nothing for the TransRelational model because I
haven't disected it yet. I have often done computations
on relational implementations which take into consideration
the indexing scheme used, the size of the data-set, the
speed of the CPU, the expected access time for the disks, etc.
The particular example I used in the original post
was for a database which was optimized for single-record
accesses (appropriate indices applied) and was a first
order approximation. If you were to redo the computations
you might have gotten 60 years instead of 600, but
neither is an acceptable result.

If you mean that the computations do not reflect the TR
model, then you are correct. It wasn't around when the
particular computation I noted was done. Nor is it
available on any commercial DBMS which I may buy today.

It really, really looks like a great idea (the TR
model). Like all great ideas, it needs to be
implemented in an industrial-strength engine.
(i.e. not just queries, but the whole 9 yards
regarding data-integrity, consistency, atomicity,
durability, transaction isolation, replication, etc.)

To paraphrase a colleague from about 15 years ago
(circa 1990) -

"Five years ago, we would have hanged anyone wanting
to use an RDBMS in a production environment. Nowadays
we would probably hang them if they didn't."

If you can wait 5 years, fine. As much as I like
the concept, I can't wait 5 years.


--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch

RDM is a subset of relational algebra. RDM is optimal for its scope.
For problems outside of RDM's scope, RDM will be inefficient and
impractical. For problems that are within the scope of models even
more restricted than RDM, the restricted model will be more efficient.
Overall, RDM is well suited for many common applications.

But, suppose we are modeling persons. A person may (or may not) have
the following two attributes: skin and hair. Skin may (or may not)
have the attributes of color(s) and texture(s). Likewise hair may (or
may not) have the attributes of color(s) and texture(s). Thus example
data might be:

Joe.
Bob with black hair.
John with black skin and red, blue hair.
Mary with smooth, white skin and red, silky hair.

Could you show how RDM would be not be inferior at modelling the above
data compared to iddy biddy XDb. By that I mean, as normalized and
NULL-less (or do you consider NULLs to be "superior"). And how would
RDM be as or less "navigational" at finding a person than XDb's
relational expression based queries shown at
www.xdb1.com/Example/Ex005.asp

PS. How you can be sure RDM is never inferior when you (and Bob)
couldn't even provide an RDM based solution in several cases? Would
you be willing to give them a second attempt?

Nick Landsberg <hukolau (AT) NOSPAM (DOT) att.net> wrote

But they don't provide The Relational Model. A little omision

Ok, but don't say that the model fails.

Then I will not buy that. It is not proved that there is no one right
way.

Then why do you react when I criticize theoretical approaches?

I always said that sometimes you are forced to use primitive
approaches in the daily work. But they are primitive anyway.

It is a good thing that you find it fascinating.

I expect it will be in the long term, and the early adopters will have
a big competitive advantage.

But the patent is near to 5 years old and nothing happened :-?

Impossible. The Relational Model is orthogonal to performance.

No, but Date reported more impressive differences.

The complexity with current implementations is in the order of (n^8),
but with the Transrelational model is only in the order of (n). Take
your own conclusions.

There is stuff about that. The eficience of updates is not a hard
problem anyway. I am implementing an alternative approach that can be
used also with disk based DBMS's.

Regards
Alfredo

"Eric Kaun" <ekaun (AT) yahoo (DOT) com> wrote


Me too, I am implementing the basic idea in my spare time, but using a
sligthly different approach also appropriate to be used in disk based
DBMS's.

But I have too little spare time

Patents are not a problem in Europe, but I don't know how many
differences are enough to avoid patent problems in the US.


Regards
Alfredo