ODMG Website?
Carl Rosenberger
Hi all,
although we all know that the ODMG work is no longer being continued,
it does surprise me that the website is abandoned completely.
Currently I am experiencing the Apache testpage only:
http://www.odmg.org/
Hey, where have all of these guys gone?
Some of them seem to take a long vacation, I guess.
Heiko Bobzin left in September, taking nearly 8 years off.
(see the message below, forwarded to me by a friend)
What about all the other ODMG guys? Is there noone even
interested to keep the site up? Strange!
Who will set an object database standard in the future?
It can't be JDO, since it's Java only.
Kind regards,
Carl
------- Forwarded message follows -------
Subject: Please resend.
From: "Heiko Bobzin" <Heiko....@xxxx.de>
To: xxxx@xxxx
Date sent: xxx, xx Sep 2002 xx:xx:xx +0x00
I will be out of the office starting 20.09.2002 and will not return
until 20.05.2010.
I cannot receive emails any longer. Please resend your message either to
xxxx xxxx (xx...@xxxx.de) if it concerns xxxx Software or resend
it to xx...@xxxx.com, if private.
Thanks.
mopaz
[]'s
José.
"Carl Rosenberger" <ca...@db4o.com> escreveu na mensagem
news:b84cpe$f6c$07$1...@news.t-online.com...
Jon Reid
The Apache default page is still up and I sent mail to webm...@odmg.org as
it suggests on that page.
Thanks
Jon Reid
Former (and last) ODMG OQL /C++ Working Group Editor
"Carl Rosenberger" <ca...@db4o.com> wrote in message
news:b84cpe$f6c$07$1...@news.t-online.com...
Paul DeWolf
the most important standard for the ODMG to create and manage. OQL was
unfortunately not properly adopted by the ODMG member vendors, but even if
it was it might not have competed well against SQL because it was dependent
on oo-databases to be adopted (a chicken and egg problem). For a variety of
reasons the ODMG was doomed from the outset.
My belief is that XML will become the query language standard for object
oriented databases and provide another standard for databases in general.
It can be adopted with confidence because it has already been established
and will survive regardless of the success of any group of vendors.
This will eventually break the stranglehold that SQL has on database access
and allow the database implementation to be swapped not only between
vendors, but also between relational and object paradigms.
There is no reason why an application has to suffer the performance and
maintenance problems (nightmares) that relational databases cause. I think
conformance to SQL is 95% of the reason why there is so much time and money
invested in relational database vendors and consultants rather than adopting
alternatives.
Once there's another standard that supports query by traversal so that you
can compare database implementations without completely rewriting the
application, there will be the sea change that many have been waiting for
over the last 15 or so years.
Paul
"Carl Rosenberger" <ca...@db4o.com> wrote in message
news:b84cpe$f6c$07$1...@news.t-online.com...
>
Jim Melton
--
<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 Astronautics
(303) 971-3846
"Paul DeWolf" <pa...@thievesandkings.com> wrote in message
news:hCwsa.464135$Zo.104428@sccrnsc03...
Robert Klemme
"Paul DeWolf" <pa...@thievesandkings.com> schrieb im Newsbeitrag
news:hCwsa.464135$Zo.104428@sccrnsc03...
> My belief is that XML will become the query language standard for object
> oriented databases and provide another standard for databases in
general.
> It can be adopted with confidence because it has already been
established
> and will survive regardless of the success of any group of vendors.
Did you mean "XPath" instead of "XML"? Otherwise could you please explain
how to use XML for querying? Thanks!
robert
Jon Reid
use with XML.
XPath 1.0 is supported in SQL Server 2000 and other relational databases as
well as XML databases.
XQuery is the new XML dialect for querying that is intended to encompass
XPath.
It is currently in W3C working draft stage, with new draft published May 2
2003 (4 days ago).
It is being published in concert with XPath 2.0; from the working draft:
"XQuery Version 1.0 includes XPath Version 2.0 as a subset."
(http://www.w3.org/TR/xquery/)
----------------------------------------------------------------------------
Jon D. Reid Micro Data Base Systems, Inc.
(www.mdbs.com)
former (briefly) ODMG OQL Working Group Editor
j...@mdbs.com
"Robert Klemme" <bob....@gmx.net> wrote in message
news:b95bf7$f3j45$1...@ID-52924.news.dfncis.de...
Paul DeWolf
"Robert Klemme" <bob....@gmx.net> wrote in message
news:b95bf7$f3j45$1...@ID-52924.news.dfncis.de...
>
Hi Robert,
Yes, I meant XPath or XQuery, but I've thought of them as pieces of the XML
standard.
Paul
Paul DeWolf
news:b8uidu$oc...@cui1.lmms.lmco.com...
> How does one query in XML?
Hi Jim,
As mentioned in the other responses, the XPath and XQuery standards are both
in development. I don't know enough about them, unfortunately, but my
understanding is that since XML is node-based, they'll support the concept
of doing a query within the context of a given node.
This is what I think is the fundamental problem with SQL (at least the
standard) is that it only supports scoping by type or table. Since it only
supports relationships through joins it doesn't scale well as the joins
become complex and the tables get very large. SQL expects me to find my
children by looking among all the children in the world, rather than looking
in my own house.
RDBMS vendors offer methods to do limited optimizations, but then they
become proprietary. They also have limited effectiveness and are difficult
to maintain because ultimately everything has to be accessible and
updateable through an SQL query engine.
Even if a database system provides ways to define groups of objects in
contexts, there's no efficient way to specify that unit through SQL without
using a join. This is why you can't put an SQL interface on an object
database and still have it perform well. It's the language that cripples
the model.
XML fits object databases extremely well because things are easily stored by
node (i.e. OID) instead of by type. XPath and/or XQuery allow one to scope
the query according to node, which means that the underlying database
implementation can take advantage of that. In Objectivity's case it could
implement the nodes as any combination of databases, containers,
relationships, maps, STL collections, etc.
An existing application that uses XPath and XQuery could replace a
relational database with an object database and achieve huge performance
benefits without changing the application at all. Conversely, if an
existing application uses an object database, a second application (e.g. a
report generator) could access the database in a generic way using a
standard and easy-to-use language.
As I understand it, there are XML-based report generators being developed.
If they became as ubiquitous as Crystal Reports (or a product like Crystal
Reports builds an XPath or XQuery interface), the typical problem of trying
to generate reports from an oo-database would be eliminated. In fact, the
report generation would likely run faster on an oo-database than on a
relational database.
Having a high performance and non-proprietary interface could theoretically
mitigate (if not eliminate) all the major objections to using non-relational
databases. The competition would be a very healthy thing for all concerned.
Paul
Bob Badour
> "Jim Melton" <jim.m...@lmco.com> wrote in message
> news:b8uidu$oc...@cui1.lmms.lmco.com...
> > How does one query in XML?
>
> Hi Jim,
>
> As mentioned in the other responses, the XPath and XQuery standards are
both
> in development. I don't know enough about them, unfortunately, but my
> understanding is that since XML is node-based, they'll support the concept
> of doing a query within the context of a given node.
>
> This is what I think is the fundamental problem with SQL (at least the
> standard) is that it only supports scoping by type or table. Since it
only
> supports relationships through joins it doesn't scale well as the joins
> become complex and the tables get very large. SQL expects me to find my
> children by looking among all the children in the world, rather than
looking
> in my own house.
I can see why you could not identify the misinformed, ignorant tripe in the
"Call for Book Chapters" post. The above paragraph is also misinformed,
ignorant tripe.
Apparently, you have never heard of clustering and/or hashing--both are
physical storage structures available in one or more SQL products. That one
may decide to use these physical structures without changing existing
queries and applications falls under the category of "physical
independence".
> RDBMS vendors offer methods to do limited optimizations, but then they
> become proprietary.
Horseshit. Are you really that ignorant of the most basic database
management knowledge? Or do you work for a vendor?
> They also have limited effectiveness
More horseshit.
> and are difficult
> to maintain because ultimately everything has to be accessible and
> updateable through an SQL query engine.
And even more horseshit.
What fantasy world do you live in?
> Even if a database system provides ways to define groups of objects in
> contexts, there's no efficient way to specify that unit through SQL
without
> using a join.
Still more horseshit. Do you even know SQL?
> This is why you can't put an SQL interface on an object
> database and still have it perform well.
You may lack that ability, but I don't think you have any business assuming
others share your limitations.
> It's the language that cripples
> the model.
It's ignorance that cripples the mind.
> XML fits object databases extremely well because things are easily stored
by
> node (i.e. OID) instead of by type.
In other words, it regresses to the location based models from the fifties
and the sixties that proved unworkable decades ago.
> In Objectivity's case it could
> implement the nodes as any combination of databases, containers,
> relationships, maps, STL collections, etc.
You ARE a vendor. That explains the horseshit.
> An existing application that uses XPath and XQuery could replace a
> relational database with an object database and achieve huge performance
> benefits without changing the application at all.
Really? Does this assume the application is written in any particular
language? Does it also assume that the relational database has an efficient
physical storage structure to begin with?
How do you propose to prove your claim? I find it rather incredible.
> Conversely, if an
> existing application uses an object database, a second application (e.g. a
> report generator) could access the database in a generic way using a
> standard and easy-to-use language.
Um, you mean like they would if they just used SQL. Of course, I would
prefer a better, more relational language, but then in the current market it
would not be a standard language--just an even-easier-to-use language. I
remain hopeful, however.
> As I understand it, there are XML-based report generators being developed.
> If they became as ubiquitous as Crystal Reports (or a product like Crystal
> Reports builds an XPath or XQuery interface), the typical problem of
trying
> to generate reports from an oo-database would be eliminated.
That is a rather interesting speculation. What types do XPath and XQuery
operate on?
> In fact, the
> report generation would likely run faster on an oo-database than on a
> relational database.
Demonstrably incorrect speculation.
> Having a high performance and non-proprietary interface could
theoretically
> mitigate (if not eliminate) all the major objections to using
non-relational
> databases.
Apparently, you lack any knowledge of the vast majority of major objections.
> The competition would be a very healthy thing for all concerned.
Competition is always a healthy thing. I wish SQL had more sound
competitors, but technologies built on ignorance just won't compete.
Paul DeWolf
"Bob Badour" <bba...@golden.net> wrote in message
news:_GXta.39$c06.5...@mantis.golden.net...
SQL doesn't define any kind of clustering or hashing. Products that use SQL
may, but just as you say it's a separate operation. XML allows you to embed
a variable length list of objects within other objects or one can use that
to embed "pointers" to other objects. The world isn't flat. Data storage
and transport shouldn't be either.
> That one
> may decide to use these physical structures without changing existing
> queries and applications falls under the category of "physical
> independence".
Yes, but if you insert data using SQL, you can't describe how you want it
physically stored. "Physical independence" also means "physical ignorance".
The application may know that two objects belong to the same group, but
there's no way for the application to specify that through SQL. Neither a
DBA nor a stored procedure can physically group them unless there's a column
in a table somewhere that provides that information.
> > RDBMS vendors offer methods to do limited optimizations, but then they
> > become proprietary.
>
> Horseshit. Are you really that ignorant of the most basic database
> management knowledge? Or do you work for a vendor?
>
> > They also have limited effectiveness
>
> More horseshit.
>
> > and are difficult
> > to maintain because ultimately everything has to be accessible and
> > updateable through an SQL query engine.
>
> And even more horseshit.
>
> What fantasy world do you live in?
I'm at a loss. How do I respond to such convincing arguments?
> > Even if a database system provides ways to define groups of objects in
> > contexts, there's no efficient way to specify that unit through SQL
> without
> > using a join.
>
> Still more horseshit. Do you even know SQL?
How do you select a row from one table and related rows from another table
in a single query without a join?
> > This is why you can't put an SQL interface on an object
> > database and still have it perform well.
>
> You may lack that ability, but I don't think you have any business
assuming
> others share your limitations.
I'm sure you could build an object database with an SQL interface that
performs well and scales. The world is waiting.
> > It's the language that cripples
> > the model.
>
> It's ignorance that cripples the mind.
>
>
> > XML fits object databases extremely well because things are easily
stored
> by
> > node (i.e. OID) instead of by type.
>
> In other words, it regresses to the location based models from the fifties
> and the sixties that proved unworkable decades ago.
No, not really. Modern object oriented databases generally have a single
layer of indirection between the logical id and the physical location of an
object. Where that layer of indirection is has a great deal to do with the
system's flexibility and performance.
> > In Objectivity's case it could
> > implement the nodes as any combination of databases, containers,
> > relationships, maps, STL collections, etc.
>
> You ARE a vendor. That explains the horseshit.
I'm not a vendor, but I've worked for one for the past few years. I used to
work for one of the top software companies that has tried very
unsuccessfully to develop enterprise GIS systems with a relational back end
(provided by the leading vendor). The applications were severely limited in
functionality because as the data models got more complex, the database
simply couldn't perform with a reasonable amount of data.
Supposedly relational databases can and do solve every data storage problem
that's existed. So why is there so much money still invested in DBAs and
consultants? Why do these consultants work on the same project for years?
Why do the applications still grind to a crawl when the size of the data
gets to a terabyte?
The other argument I've heard is that the true relational vision hasn't
really been implemented (e.g. the Date manifesto). I haven't read the book,
but I've heard it's brilliant if you assume that joins are instantaneous and
don't actually have to build it.
> > An existing application that uses XPath and XQuery could replace a
> > relational database with an object database and achieve huge performance
> > benefits without changing the application at all.
>
> Really? Does this assume the application is written in any particular
> language?
No.
> Does it also assume that the relational database has an efficient
> physical storage structure to begin with?
>
> How do you propose to prove your claim? I find it rather incredible.
It assumes a non-trivial application with enough data and complexity to see
the difference between the databases. It's pretty easy to demonstrate how
much better an object oriented database can perform and scale with complex
data if you start with a complex object model and a suitable amount of real
data.
It's easy but it takes time to write the code, especially to ingest tabular
data and rebuild relationships. Data in XML format makes this much, much
easier, which is another reason XML will help the non-relational world.
> > Conversely, if an
> > existing application uses an object database, a second application (e.g.
a
> > report generator) could access the database in a generic way using a
> > standard and easy-to-use language.
>
> Um, you mean like they would if they just used SQL. Of course, I would
> prefer a better, more relational language, but then in the current market
it
> would not be a standard language--just an even-easier-to-use language. I
> remain hopeful, however.
Yes, I mean like they would if they just used SQL. SQL is great for
ease-of-use as long as you have time to kill. The reason why it's so awful
to developers is partly that it's ugly when embedded in otherwise oo code,
but the real problem is that it forces them to flatten their object model
and change the order in which they do things. They can't simply send off a
SQL query, get the results, then send another SQL query based on the first,
etc. Performance goes down the drain.
> > As I understand it, there are XML-based report generators being
developed.
> > If they became as ubiquitous as Crystal Reports (or a product like
Crystal
> > Reports builds an XPath or XQuery interface), the typical problem of
> trying
> > to generate reports from an oo-database would be eliminated.
>
> That is a rather interesting speculation. What types do XPath and XQuery
> operate on?
>
>
> > In fact, the
> > report generation would likely run faster on an oo-database than on a
> > relational database.
>
> Demonstrably incorrect speculation.
We'll probably get a chance to see.
> > Having a high performance and non-proprietary interface could
> theoretically
> > mitigate (if not eliminate) all the major objections to using
> non-relational
> > databases.
>
> Apparently, you lack any knowledge of the vast majority of major
objections.
I work for an oo-database vendor in technical sales. I think I've heard the
major objections. Yours is apparently "horseshit".
> > The competition would be a very healthy thing for all concerned.
>
> Competition is always a healthy thing. I wish SQL had more sound
> competitors, but technologies built on ignorance just won't compete.
Technologies that solve problems without causing too many of their own
usually compete quite well. For a number of years, object-oriented
databases have been providing solutions that relational databases simply
couldn't. Unfortunately, they have also come with their own problems, by
far the most significant being that there hasn't been a common interface
between them like the relational vendors had with SQL.
Consequently, one couldn't create, edit or access objects in the database
without writing (usually vendor-specific) code in C++, Java or Smalltalk. I
believe that XML, XPath and XQuery will change that. I don't really care if
you don't believe me, time will tell.
Paul
Axel Hallez
> "Jim Melton" <jim.m...@lmco.com> wrote in message
> news:b8uidu$oc...@cui1.lmms.lmco.com...
> > How does one query in XML?
>
> Hi Jim,
>
> As mentioned in the other responses, the XPath and XQuery standards are
both
> in development. I don't know enough about them, unfortunately, but my
> understanding is that since XML is node-based, they'll support the concept
> of doing a query within the context of a given node.
>
> This is what I think is the fundamental problem with SQL (at least the
> standard) is that it only supports scoping by type or table. Since it
only
> supports relationships through joins it doesn't scale well as the joins
> become complex and the tables get very large.
I don't think that RDBMS's scale worse than ODBMS's. As far as I can see,
they mostly use the same techniques to manage scalability.
> SQL expects me to find my
> children by looking among all the children in the world, rather than
looking
> in my own house.
> RDBMS vendors offer methods to do limited optimizations, but then they
> become proprietary. They also have limited effectiveness and are
difficult
> to maintain because ultimately everything has to be accessible and
> updateable through an SQL query engine.
1. I would not call the available optimization techniques like clustering
(which
is basically the 'look in your own house' you mention) or several
indexing
flavours limited.
2. Although most of these techniques are not compliant to any standard
ubiquitous, I mean every serious RDBMS has B-Tree indexing.
3. I doesn't matter that these techniques are not standardized since they
are
transparant for the user/application, so you can still use create your
queries
and database applications in an (almost) vendor independent way (but the
vendor dependencies are due to differences in the SQL dialects and have
notting to do with proprietary optimization techniques).
> Even if a database system provides ways to define groups of objects in
> contexts, there's no efficient way to specify that unit through SQL
without
> using a join. This is why you can't put an SQL interface on an object
> database and still have it perform well. It's the language that cripples
> the model.
I don't agree, it heavily depends on the storage model of the object
database.
It is also doubtfull that an object database which can't handle sql
efficiently will
handle object querying languages like OQL efficiently. Most ODBMS's want to
support some kind of querying by extent, which is basically the same as
querying
by table.
BTW, Intersystems Caché is a product which has both an SQL and an object
interface, and both interfaces are reported to be very fast.
> XML fits object databases extremely well because things are easily stored
by
> node (i.e. OID) instead of by type. XPath and/or XQuery allow one to
scope
> the query according to node, which means that the underlying database
> implementation can take advantage of that. In Objectivity's case it could
> implement the nodes as any combination of databases, containers,
> relationships, maps, STL collections, etc.
>
> An existing application that uses XPath and XQuery could replace a
> relational database with an object database and achieve huge performance
> benefits without changing the application at all. Conversely, if an
> existing application uses an object database, a second application (e.g. a
> report generator) could access the database in a generic way using a
> standard and easy-to-use language.
I agree that XML technology can provide a common interface to different
kinds
of databases, but I'm not sure if it's the best way to do it.
The way XML models data is very much the same as in old time hierarchical
databases. As far as I can remember, there were to major reason why
hierarchical
have been abandoned:
1. They had no strict seperation between the logical layer and the physical
layer.
This is not an issue with the XML approach.
2. They offered limited modelling capabilities.
This issue comes back again with XML: if your model needs to store
information
beyond the hierarchical structure, you're in trouble.
> As I understand it, there are XML-based report generators being developed.
> If they became as ubiquitous as Crystal Reports (or a product like Crystal
> Reports builds an XPath or XQuery interface), the typical problem of
trying
> to generate reports from an oo-database would be eliminated. In fact, the
> report generation would likely run faster on an oo-database than on a
> relational database.
>
> Having a high performance and non-proprietary interface could
theoretically
> mitigate (if not eliminate) all the major objections to using
non-relational
> databases. The competition would be a very healthy thing for all
concerned.
If there's one IT field where competition is very high, it is in
(relational) databases.
Axel Hallez
Paul DeWolf
My responses are below:
"Axel Hallez" <axel....@rug.ac.be> wrote in message
news:b9ag6f$ose$1...@newsreader.mailgate.org...
>
> "Paul DeWolf" <pa...@thievesandkings.com> wrote in message
> news:e3Tta.34070$pa5....@rwcrnsc52.ops.asp.att.net...
> > "Jim Melton" <jim.m...@lmco.com> wrote in message
> > news:b8uidu$oc...@cui1.lmms.lmco.com...
> > > How does one query in XML?
> >
> > Hi Jim,
> >
> > As mentioned in the other responses, the XPath and XQuery standards are
> both
> > in development. I don't know enough about them, unfortunately, but my
> > understanding is that since XML is node-based, they'll support the
concept
> > of doing a query within the context of a given node.
> >
> > This is what I think is the fundamental problem with SQL (at least the
> > standard) is that it only supports scoping by type or table. Since it
> only
> > supports relationships through joins it doesn't scale well as the joins
> > become complex and the tables get very large.
>
> I don't think that RDBMS's scale worse than ODBMS's. As far as I can see,
> they mostly use the same techniques to manage scalability.
There are two main reasons that RDBMS's generally have trouble scaling.
The first is that they tend to be centralized and server heavy. Once you
reach the limits of your processing hardware, you have to replace it rather
than add to it. Once you surpass the limits of available hardware (or your
budget), you're in a bind. Sun and IBM must be rather fond of Oracle, since
they've sold a lot of their top-end hardware just to serve data.
Some object oriented databases are also centralized and server heavy, so an
oo-database doesn't necessarily solve that problem, but much of the
centralization has to do with the SQL query engine, so an object database is
less likely to be as centralized. Ours, for example, is totally
distributable so you can parallelize like crazy.
The second reason has to do with traversing complex relationships.
Implementing a many-to-many relationship in a relational database requires a
join table (also called a junction table or connectivity table). For
example, a professor can have many students and a student can have many
professors. You need a separate table than your student and professor
tables to describe who is connected to whom.
Because the join table contains all the combinations, it many more rows than
the original tables. It requires two b-tree lookups to join a professor
with his students or vice versa (select * from students, professors,
jointable where jointable.studentid = students.studentid and
jointable.professorid = <id>). As the total number of students and/or
professors grows, the join table will grow even faster and the performance
of the lookup for the students of a particular professor will degrade.
A true object oriented database will tend to allow a professor to have their
own list of students. Once you've found a professor, you've already got the
ids of his students, you don't have to search a very large join table for
them.
Consequently, no matter how many students join the university, it still
takes the same amount of time for the professor to look up his students. As
relationships get even more complex with many-to-many-to-many-to-many
relationships that you may want to traverse, a relational database will get
slower and slower with more data.
Many applications actually don't need to scale that much. In my example,
the number of students and professors will reach a peak and the data model
will stay fairly simple, so a relational database will probably work fine.
Applications like CAD/CAM, GIS and others have such complex relationships
and have such quantities of data that using standard relational databases
becomes extremely difficult.
Some scientific and other applications that have constant streams of new
data also need to be able to scale more than relational databases will
support.
There are also many applications in the middle that are fairly complex and
have a lot of data. If they keep their requirements within reasonable
limits and buy high-end servers they'll be o.k., but they'd be better off
doing things with another paradigm.
I maintain that the majority of these middle applications avoid the
alternatives because 1. They don't know there are alternatives. 2. It's
very difficult to test the alternatives and migrate. 3. They need the ease
of accessing their data through SQL. 4. They're afraid of being locked into
a small vendor and 5. They don't want to lose their investment.
I believe that if SQL is replaced or extended with language that better
supports traversal of relationships and doesn't require as much mapping code
between objects and tables, it will greatly help ease all of these problems
and provide more choices to how data is stored and served. That's really my
point.
> > SQL expects me to find my
> > children by looking among all the children in the world, rather than
> looking
> > in my own house.
> > RDBMS vendors offer methods to do limited optimizations, but then they
> > become proprietary. They also have limited effectiveness and are
> difficult
> > to maintain because ultimately everything has to be accessible and
> > updateable through an SQL query engine.
>
> 1. I would not call the available optimization techniques like clustering
> (which
> is basically the 'look in your own house' you mention) or several
> indexing
> flavours limited.
It depends. If they solve the problem without causing new ones, they're not
limited. I call them limited because the application can't participate in
making the clustering decisions and that can be very important. You also
can't cluster mixed types. You can't cluster the house object, the parent
objects and the children objects on the same page on the disk.
If you need to be able to get all this information in one disk I/O, there's
no way to do it with the relational clustering functions. If you don't need
to be able to do that, then from your point of view the clustering isn't
limited.
The philosophy of the vendor I work for is "If you can do it with a
relational database, use a relational database." We don't compete with
relational databases in their spaces.
Interesting. I do like their ads, but I admit that I don't know that much
about their product. Do they use extensions to the SQL language?
I totally agree. XML databases that use the old hierarchical structure on
disk are in deep trouble. Like I said in my other post, if you have a layer
of indirection between the logical object id and the physical location you
can avoid that mistake.
> > As I understand it, there are XML-based report generators being
developed.
> > If they became as ubiquitous as Crystal Reports (or a product like
Crystal
> > Reports builds an XPath or XQuery interface), the typical problem of
> trying
> > to generate reports from an oo-database would be eliminated. In fact,
the
> > report generation would likely run faster on an oo-database than on a
> > relational database.
> >
> > Having a high performance and non-proprietary interface could
> theoretically
> > mitigate (if not eliminate) all the major objections to using
> non-relational
> > databases. The competition would be a very healthy thing for all
> concerned.
>
> If there's one IT field where competition is very high, it is in
> (relational) databases.
I don't think SQL and relational databases are inherently evil (although a
vendor or two might be), but there are alternatives that are better in some
situations.
There's a lot of competition between VCR manufacturers, but don't you also
want to be able to buy a DVD player or TiVo? If you have an application
that doesn't fit well with a relational database, more relational choices
don't help.
Paul
nob...@nobody.com
Ignore the postings from Badour and others. They're just a bunch of
net trolls smearing the group with FUD on Object Databases. I think
they may work for one of the advocacy groups run by Chris Date.
After all, if Rdbs are so great, why doesn't Mr. Badour hang his hat
on comp.databases.relational, instead of arguing here?
Maybe he's just a sanctimonious crusader trying to "educate" us.
<grin>.
On Tue, 6 May 2003 18:53:53 -0400, "Bob Badour" <bba...@golden.net>
wrote:
Kazuhiro Nakao
> I believe that if SQL is replaced or extended with language that better
> supports traversal of relationships and doesn't require as much mapping code
> between objects and tables, it will greatly help ease all of these problems
> and provide more choices to how data is stored and served. That's really my
> point.
SQL can be well integrated with object databases, while SQL query
still takes advantage of relationships between objects for better
performance, i.e., looking in my own house rather than looking among
all the children in the world to find my children. I want to show an
example below.
The next query needs a join operation in relational database: select
all the employees of a department 'X'. You would write a query like:
SELECT e.name, ...
FROM Employees e JOIN Departments d ON e.dep_id = d.dep_id
WHERE d.name = 'X';
With object database, you would define two classes Employee and
eparment with a relationship (belongsTo) between them. Then, you can
write an SQL query like:
SELECT e.name, ...
FROM Employee e JOIN Department d ON e.belongsTo = d.OID
WHERE d.name = 'X';
(you can see a sort of intuitive translation between
table <----> class
column <----> attribute
row <----> object
)
Then, SQL compiler (and optimizer) generates a plan like:
1) find a Deparment object which has name 'X'
(may use an index if defined)
2) then, get all the employees through relationship navigation
(use relationship 'employees' which is defined as inverse for
'belongsTo')
3) generate projection from the Employee objects obtained
An SQL query that needs to look at more than one class really takes
advantage of object relationships.
Another extension to SQL that helps object programming is a capability
that allows you to get back objects directly (Java, C#, C++,
whatever) rather than projection, you write something like:
SELECT REF(e) FROM Employee e ...
and, in C# (for example)
Employee emp = (Employee) aDataReader.getObject(0);
--
Kazuhiro Nakao
Matisse Software, Inc.
Jim Melton
> news:e3Tta.34070$pa5....@rwcrnsc52.ops.asp.att.net...
> > "Jim Melton" <jim.m...@lmco.com> wrote in message
> > news:b8uidu$oc...@cui1.lmms.lmco.com...
> > > How does one query in XML?
> >
> > Hi Jim,
> >
> > As mentioned in the other responses, the XPath and XQuery standards are
> both
> > in development. I don't know enough about them, unfortunately, but my
> > understanding is that since XML is node-based, they'll support the
concept
> > of doing a query within the context of a given node.
> >
> > This is what I think is the fundamental problem with SQL (at least the
> > standard) is that it only supports scoping by type or table. Since it
> only
> > supports relationships through joins it doesn't scale well as the joins
> > become complex and the tables get very large. SQL expects me to find my
> > children by looking among all the children in the world, rather than
> looking
> > in my own house.
>
> I can see why you could not identify the misinformed, ignorant tripe in
the
> "Call for Book Chapters" post. The above paragraph is also misinformed,
> ignorant tripe.
Gee, Bob, I've missed you. Your posts are always so enlightening.
Jim Melton
> Some scientific and other applications that have constant streams of new
> data also need to be able to scale more than relational databases will
> support.
This is my area of experience. Relational Databases seem to make their
living off querying semi-static tables of flat data. I write applications
that deal with a constrant stream of data (of varying complexities). I have
tried storing to an RDBMS and the performance is abysmal. I currently use
Objectivity/DB and am very pleased with the performance. I *could not* use a
relational product to pass data between my components they way I do with
Objectivity and achieve anywhere near the same performance.
In my industry, performance is not just a matter of making a VP wait and
extra 30 minutes for his report. People can live or die based on the
performance of our products.
> > 1. I would not call the available optimization techniques like
clustering
> > (which
> > is basically the 'look in your own house' you mention) or several
> > indexing
> > flavours limited.
>
> It depends. If they solve the problem without causing new ones, they're
not
> limited. I call them limited because the application can't participate in
> making the clustering decisions and that can be very important. You also
> can't cluster mixed types. You can't cluster the house object, the parent
> objects and the children objects on the same page on the disk.
Despite Bob's endearing style, I did learn a bit from crossing swords with
him in the past. The argument is that an application *should not* specify
where the data is stored, as it limits the value of the data to another
application. This is what is meant by location transparency.
The clustering directives for RDBMSs are specified in the DDL. Yes, it
requires columns on which to cluster, as an RDBMS requires a unique key
value, even if it must be synthetic, to enforce the uniqueness of the
relations. I too find these to be flaws, but present the arguments as I
understand them for completeness.
A database that is physically tuned for one application will necessarily be
sub-optimally tuned for another. To the extent that the data can be
reorganized *without breaking either application*, then the database can
claim location transparency. For a large, corporate data warehouse, this can
be a significant issue. For an application that deals with streams of
time-perishable data, it's not so big a deal. I cheerfully trade location
transparency for current performance.
Bob Badour
> "Paul DeWolf" <pa...@thievesandkings.com> wrote in message
> news:YJaua.800058$S_4.820337@rwcrnsc53...
> > Some scientific and other applications that have constant streams of new
> > data also need to be able to scale more than relational databases will
> > support.
>
> This is my area of experience. Relational Databases seem to make their
> living off querying semi-static tables of flat data. I write applications
> that deal with a constrant stream of data (of varying complexities). I
have
> tried storing to an RDBMS and the performance is abysmal.
You used one particular product with one or a few designs and it did not
work for you. That says nothing about the general case of relational
database management systems. The one product you used might not support the
physical structure options required to meet your performance requirements,
but others could.
> I currently use
> Objectivity/DB and am very pleased with the performance. I *could not* use
a
> relational product to pass data between my components they way I do with
> Objectivity and achieve anywhere near the same performance.
I am sorry to hear about your disability.
> In my industry, performance is not just a matter of making a VP wait and
> extra 30 minutes for his report. People can live or die based on the
> performance of our products.
I guess that's why your company is willing to accept the additional and
extremely high cost of paying expert programmers to perform basic dbms
functions.
> > > 1. I would not call the available optimization techniques like
> clustering
> > > (which
> > > is basically the 'look in your own house' you mention) or several
> > > indexing
> > > flavours limited.
> >
> > It depends. If they solve the problem without causing new ones, they're
> not
> > limited. I call them limited because the application can't participate
in
> > making the clustering decisions and that can be very important. You
also
> > can't cluster mixed types. You can't cluster the house object, the
parent
> > objects and the children objects on the same page on the disk.
>
> Despite Bob's endearing style, I did learn a bit from crossing swords with
> him in the past. The argument is that an application *should not* specify
> where the data is stored, as it limits the value of the data to another
> application. This is what is meant by location transparency.
>
> The clustering directives for RDBMSs are specified in the DDL. Yes, it
> requires columns on which to cluster, as an RDBMS requires a unique key
> value, even if it must be synthetic, to enforce the uniqueness of the
> relations. I too find these to be flaws, but present the arguments as I
> understand them for completeness.
Perhaps I misread the above. It seems to me you are saying you find it a
flaw to manage data as data and a flaw to separate concerns. Your findings
astonish me given they contradict all of the Turing Award winners with which
I am familiar and contradict my own two decades of programming experience.
> A database that is physically tuned for one application will necessarily
be
> sub-optimally tuned for another. To the extent that the data can be
> reorganized *without breaking either application*, then the database can
> claim location transparency. For a large, corporate data warehouse, this
can
> be a significant issue. For an application that deals with streams of
> time-perishable data, it's not so big a deal. I cheerfully trade location
> transparency for current performance.
If you don't need data management, you don't need a data management system,
and you can ignore good data management principles. However, if you need
data management, I suggest you look for a solution that does not require any
unecessary tradeoffs.
Paul DeWolf
My responses are below, followed by a rant.
"Jim Melton" <jim.m...@lmco.com> wrote in message
news:b9e1r3$2p...@cui1.lmms.lmco.com...
Yes, it's good if an application can get an object without knowing where it
is stored. It's also good to be able to manage the physical design from
outside the application. But that doesn't preclude an application being
able to place objects together.
> The clustering directives for RDBMSs are specified in the DDL. Yes, it
> requires columns on which to cluster, as an RDBMS requires a unique key
> value, even if it must be synthetic, to enforce the uniqueness of the
> relations. I too find these to be flaws, but present the arguments as I
> understand them for completeness.
Yes, one can cluster up to a point if one adds synthetic columns to the data
model and they can make it seem transparent with views. But I still don't
think vendors allow you to cluster disparate types, so if a parent node has
twenty different _kinds_ of children, you still can't cluster them
effectively. That would make the physical rows have different sizes within
the physical table. Don't relational databases use the fact that the width
of each row is constant to be able to calculate the offset to any given row?
> A database that is physically tuned for one application will necessarily
be
> sub-optimally tuned for another. To the extent that the data can be
> reorganized *without breaking either application*, then the database can
> claim location transparency. For a large, corporate data warehouse, this
can
> be a significant issue. For an application that deals with streams of
> time-perishable data, it's not so big a deal. I cheerfully trade location
> transparency for current performance.
There's no reason an oo database can't allow reorganization of the data
without breaking an application. This is partly the purpose for our
physical design framework - to make this a standard process. If an
application makes a decision about the physical proximity of two objects,
there's no reason why that has to be a problem to other applications in an
object database.
When an application traverses objects in Objectivity (looks an object up by
its OID), it doesn't have to know anything about where those objects are
stored. The only way one loses "location transparency" is if one makes a
conscious decision to use the physical location (database or container) as
part of the logical lookup without using the physical design framework or
some other method of indirection. But you don't have to do that to get the
benefits of clustering. It's a nice feature of Objectivity and often a
great trade-off for "location transparency", but it's not the core of our
performance.
A big factor in the problems with relational databases and the philosophies
of CJ Date and his followers is that they force you into the smart server
and dumb client (smart database, dumb application) model. The defenders
keep claiming that there's nothing that you cannot do by making the database
smarter. They also say that that's where you always want to do it. Giving
power to the application would cause anarchy and then what would DBAs do?
But it's very analogous to the client/server trade-off. There are
advantages to having smart servers and dumb terminals, but there are also
advantages to having smart clients and little or no servers. There are also
advantages to having smart clients AND smart servers.
Anyone who argues that you can make up for dumb clients with smarter servers
(or vice versa) and that it will fit across all applications is truly
ignorant and/or misinformed. Larry Ellison tried to argue years ago that
soon PCs would no longer have hard drives because all data and programs
would be on the internet. Who needs anything on the client? He's since
admitted we was a little mistaken on that.
You don't want to have to look up everything on the internet. There's quite
a bit of data that you want stricter access to, and if you can have your
data on your local disk and access data on a pier-to-pier network AND have
access to the internet, isn't that better? You don't want to have to find a
file that you just created by looking on Google, no matter how clever and
optimized Google is.
Object databases (at least ours) went to the other end of the spectrum in
putting a lot of the database on the client side and losing some of the
benefits of a smarter server. But then again, you can put your own
application on a server and build your own server-side benefits. Either way
we still provide visibility and transactions across all the objects in the
database.
It's better to have the choice, and object databases have a better capacity
to provide server-side benefits than relational vendors do to add
client-side benefits. Relational databases are centralized around the tuple
query engine that everything has to go through. With some it's like a
religion.
According to the relational bigots, "If your application didn't work well
enough with a relational database, you just didn't work on it hard enough.
You probably should have hired some smarter DBAs and maybe some consultants.
You're ignorant and misinformed."
It's so easy to say that, but here's what really happens. Fred starts with
a data model, flattens and normalizes it as they tell him in RDBMS 101.
Fred's group loads the database with the data, which is pretty easy because
he can do it a table at a time, and he's feeling like things are going quite
well. He starts with a simple application prototype with simple queries and
things are going great. He's demoing it and he and the database are looking
good.
Now he spends months developing Phase I of the application and finds that
when more data is added and the application needs to zip through some common
data structures across multiple tables, performance is getting bad. He's
already added indexes to all the primary keys. RDBMS 101 says to expect
this and that he should now DEnormalize the areas that need better
performance. Joining primary and foreign keys apparently isn't
instantaneous despite relational theory and b-trees. He does the
denormalizing and changes the application code. Performance isn't great,
but it works. Phase I is deployed and they start training the users.
Phase I made a nice demo, but everyone is really waiting for Phase II.
That's just adding some tables and columns for some other data that needs to
be integrated and adding some features that users have requested because
it's too awkward to get certain combinations of data. It's scheduled to be
built, tested and deployed in six months.
Hmmm. It's six months and Fred's still building. These changes seemed
trivial, but it's making the model more complex. Besides the new tables of
data he's getting, he needs to add a new table between two other tables.
Those were two tables he was considering denormalizing to get better
performance. It's easy enough to add the information to the schema but the
new tables are causing more joins. The SQL statements are getting weird
too. Fred adds some views to the database to make the SQL easier to read
and write, but the application's performance stinks again. Fred's Phase I
was promising great things, but what about Phase II? Fred's starting to
think he's stuck between backing off on his promises or screwing up the
performance of the entire application.
Ah, but it's impossible to get stuck like that with a top-of-the-line
database, isn't it? Look how many people are using it successfully. Fred's
just not doing things correctly. Fred hires a smarter DBA than his old one
and maybe a couple consultants who promise that they'll give him the best of
all worlds in no time.
Oh, they've already discovered a couple of problems. First, the server is
old and needs upgrading and more memory. Isn't it obvious? The database is
using all the memory and CPU. The database is so smart that it must be
using the resources efficiently. Think how many years they've had to build
and optimize it. Fred's server is great for serving files, but a database
is a whole other thing. The hardware just doesn't cut it. Either that or
Fred's not quite smart enough to design the application properly.
Speaking of which, the queries that the developers are using aren't really
correct. They need to combine some of their functions into a single query.
Haven't they studied RDBMS? They can't develop the software as if things
are in memory, after all. We'll add a couple of views and some stored
procedures and teach them to query it properly. Of course, that means
they'll have to change their mapping code. Oh, and I hope your DBA and/or
developers know PL/SQL because when we leave, they're going to have to
maintain those stored procedures and triggers.
Just kidding, the consultants are never going to leave - Fred's in the
middle of putting their kids through college.
Plus they give him the good news that the next version of Oracle is going to
support server clusters better, so he'll be able to upgrade to larger and
more expensive hardware to solve his problems - Oracle is scalable that way.
Then one day Fred thinks about it and wonders why it takes all this money
and effort to simply write data onto disk and retrieve it again. He can
describe how he wants to get the data fairly simply (like following a tree
down to find all the items connected to this widget), but the SQL code is a
mess even with the views. He could write the stuff to a file and read it
back in a tiny fraction of the time that it takes to write it to the
database and read it again. Why does this expensive software require so
much expensive hardware and still he has performance problems? Why is he
working so hard on the database? This wasn't what he expected to spend all
his time on.
What does he do? He's supposedly got the best database money can buy.
That's what his IT department, DBAs and consultants tell him. Maybe he can
write his own persistence layer? He'd have to write his own concurrency,
data migration and transaction managers. Yuck. If Oracle can't do what he
wants, why should he suppose his developers can? Switch to another
database? He probably does have the best relational database money can buy,
so what else can he do?
Well, he can choose an object database. After some research his developers
are telling him that they think it will help them, but it's pretty new to
them, but now he's faced with rewriting a lot of code even to get back to
Phase I. He'll also have to work with a relatively unknown vendor, which
makes his boss really nervous. Perhaps the company would be able to save
money by getting rid of the DBAs and consultants they hired at the beginning
of the project (funny, they're telling Fred that it'll never work), but
that's really not something his boss wants to hear, and they still need them
to maintain Phase I until they have a replacement anyway.
No, Fred's company will have to keep them for now, but they won't be able to
help with this oo-database they know nothing about. In fact, they'll be
openly hostile about it.
Fred's desperate and frustrated, so he goes to a newsgroup to find out more
about these oo-databases. It seems awfully quiet, but someone there says
that they've been successful using an object database on an application that
wasn't working with a relational database. Just what he wants to hear. Ah,
but Bob Badour chimes in and says that's impossible. They just didn't work
hard enough with their relational database.
Gee, that's what the DBA says too. In fact, there's even a book with
mathematical theories that seem to prove that Fred's application is as fast
as it can get. It must be true. Fred calls an oo-database vendor and asks
how much performance improvement he could expect, but they can't tell him
without knowing a great deal about his application. He'd really need to do
a prototype. The oo-database theory sounds really good, but how can he
prove it to himself, let alone his boss? He can't afford to take use his
staff for an experiment that could take well over a month.
Ultimately Fred quits and joins a smaller company that's starting a new
project that needs a database. He talks his new boss into trying an
object-oriented database. This time his Phase I takes a little longer to
build, but man, it's fast. Phase II comes in ahead of schedule and it's
still fast.
Meanwhile, his replacement at the previous company adds what features he
can, but the application stays looking pretty much like Phase I. Everyone
says that Fred was a good architect but got burned out. People would really
like to see a new version of the application and they'll probably start the
project again when they can afford to buy the new servers, but until then
they'll live with it. Fred tries to tell his replacement about oo-databases
when they happen to meet at a restaurant, but his replacement isn't really
interested. It wasn't really his application in the first place and the
momentum's gone.
This is why it's so important to be able to convert the database without
changing the whole application. By the time Fred is not "ignorant and
misinformed", it's too late for him to try to fix the project he's on. If
he could prove to everyone that he could get Phase II running like a banshee
with another product AND save costs he could not only fight but also win the
battle. But converting to a vendor-specific database interface will just
cost too much time and money to take the risk.
It's enough to keep many people listening to the FUD that people like Bob
Badour spread and keep compromising. People understandably need to see real
proof quickly with their own application. Objectivity has many prospects
and customers willing to do the initial work to realize the long-term
benefits (SLAC has a 750 terabyte Objectivity database administered
half-time by a Physicist). Most of them knew from the get-go the
limitations of relational databases. Some of them learned were able to
convert.
As I mentioned in my other posting, we don't even try to convert people if
they're not "brilliant or desperate". It's way too expensive to try to
educate a market and there are enough applications that HAVE to use an
alternative that Objectivity's doing fine. I'm writing this because I'm on
vacation and I can't help myself.
But if XML, XPath and XQuery encourages the use of object traversal and
databases are expected to support those data structures instead of the
expectation that applications should be designed around the database, that
will only help alternative technologies and Fred's choices. That's why I
think that XML will do what the ODMG was trying to do.
Paul
Bob Badour
Within the memory space of the application, the application can do whatever
it wants. However, if it directly controls location in the dbms, it dictates
location outside the application making it unmanageable outside the
application. The two mutually exclude each other.
> > The clustering directives for RDBMSs are specified in the DDL. Yes, it
> > requires columns on which to cluster, as an RDBMS requires a unique key
> > value, even if it must be synthetic, to enforce the uniqueness of the
> > relations. I too find these to be flaws, but present the arguments as I
> > understand them for completeness.
>
> Yes, one can cluster up to a point if one adds synthetic columns to the
data
> model and they can make it seem transparent with views. But I still don't
> think vendors allow you to cluster disparate types
What you think and what actually is are two different things. I suggest you
study clusters in oracle:
http://storacle.princeton.edu:9001/oracle8-doc/server.805/a58225/ch4a.htm#19
90679
>, so if a parent node has
> twenty different _kinds_ of children, you still can't cluster them
> effectively.
Whether one will gain any performance benefits having clustered so many
tables is questionable; however, oracle allows one to cluster up to 32
tables.
> That would make the physical rows have different sizes within
> the physical table.
So? What's wrong with that?
> Don't relational databases use the fact that the width
> of each row is constant to be able to calculate the offset to any given
row?
No. In general, they do not; although, they can if that is the physical
storage structure desired. Nothing in the relational model either demands or
prohibits any physical storage structure. The relational model strongly
suggests having a wide selection of physical structures from which to
choose.
> > A database that is physically tuned for one application will necessarily
> be
> > sub-optimally tuned for another. To the extent that the data can be
> > reorganized *without breaking either application*, then the database can
> > claim location transparency. For a large, corporate data warehouse, this
> can
> > be a significant issue. For an application that deals with streams of
> > time-perishable data, it's not so big a deal. I cheerfully trade
location
> > transparency for current performance.
>
> There's no reason an oo database can't allow reorganization of the data
> without breaking an application. This is partly the purpose for our
> physical design framework - to make this a standard process. If an
> application makes a decision about the physical proximity of two objects,
> there's no reason why that has to be a problem to other applications in an
> object database.
I do not think you fully appreciate the implications of physical
independence. For instance, how easy would it be to decide that an
employee's name should be redundantly stored locally to his home department,
at the regional office for payroll and at the head office for HR? That his
birthdate is stored at the head office for HR, his base salary is stored at
the regional office for payroll and his cubicle location is stored locally
to his home department? That the data stored at the head office for HR is
clustered by job title and indexed a dozen ways from sunday, that the data
stored at the regional office for payroll is unclustered and indexed by
employee number and by ssn and that the data stored locally to his home
department is neither clustered nor indexed? (It's a small department, after
all, and indexing would only slow things down.)
How easy would it be to decide that ordering a given query result will
happen on each client computer today, change it to happen at the local
department tomorrow and change it again to use the existing order from an
index at the regional office next week? I expect a recompile will be
necessary, but I do not anticipate changing any application code.
> When an application traverses objects in Objectivity (looks an object up
by
> its OID), it doesn't have to know anything about where those objects are
> stored.
Except that OID is nothing more than a location even if it specifies a
location that stores a location. Your statement is a contradiction.
> The only way one loses "location transparency" is if one makes a
> conscious decision to use the physical location (database or container) as
> part of the logical lookup without using the physical design framework or
> some other method of indirection.
One loses physical indepdence as soon as one is allowed to make such a
decision because everthing else must account for the possibility.
> But you don't have to do that to get the
> benefits of clustering. It's a nice feature of Objectivity and often a
> great trade-off for "location transparency", but it's not the core of our
> performance.
Physical access is the core of performance -- good or bad. The question is
whether to force users to deal with physical issues directly or whether to
separate the physical access concern from the expressibility concern.
> A big factor in the problems with relational databases and the
philosophies
> of CJ Date and his followers is that they force you into the smart server
> and dumb client (smart database, dumb application) model.
You neither understand the relational model nor the principles of sound data
management. Whether something executes on a server or a client is a physical
issue with which casual users should never have to deal. Businesses require
intelligent data management and intelligent applications even if they seldom
get either.
> The defenders
> keep claiming that there's nothing that you cannot do by making the
database
> smarter.
There are many problems that are simply too hard to solve by making the dbms
smarter--no matter what logical model one uses. Plenty of proofs exist
demonstrating that various tasks are NP-complete problems. Humans will
always have to intervene to guide the dbms to the best solution when the
best solution is too expensive to calculate. The question is: Does a small
number of humans with extensive training and rare aptitudes intervene for a
large number of humans with diverse training and aptitudes? Or must every
user have expert level knowledge of physical database access methods?
> They also say that that's where you always want to do it. Giving
> power to the application would cause anarchy and then what would DBAs do?
The relational model empowers applications and users. As I say above, you
neither understand the relational model nor the principles of sound data
management. Forcing casual users to contend with irrelevant (even if
important) technical minutiae does not empower them--it frustrates them.
> But it's very analogous to the client/server trade-off. There are
> advantages to having smart servers and dumb terminals, but there are also
> advantages to having smart clients and little or no servers. There are
also
> advantages to having smart clients AND smart servers.
As I say above, these are all physical design concerns that should be
totally separate from logical expressibility concerns. There are no
advantages to frustrating users by forcing them to grapple with irrelevant
technical minutiae.
> Anyone who argues that you can make up for dumb clients with smarter
servers
> (or vice versa) and that it will fit across all applications is truly
> ignorant and/or misinformed.
That's a very fine straw man you are burning, but nobody has argued that.
> Larry Ellison tried to argue years ago that
> soon PCs would no longer have hard drives because all data and programs
> would be on the internet. Who needs anything on the client? He's since
> admitted we was a little mistaken on that.
Larry Ellison has sold a lot of folks a lot of different bills of goods.
He's the ultimate fad marketeer. Of course, that says little about data
management or the principles of sound data management.
> Object databases (at least ours) went to the other end of the spectrum in
> putting a lot of the database on the client side and losing some of the
> benefits of a smarter server. But then again, you can put your own
> application on a server and build your own server-side benefits. Either
way
> we still provide visibility and transactions across all the objects in the
> database.
It is exactly that visibility that damages your product beyond all repair.
> It's better to have the choice
It's better if the vast majority of users do not have to make the choice and
if those most capable can easily change the choice at any time.
> and object databases have a better capacity
> to provide server-side benefits than relational vendors do to add
> client-side benefits.
You are making an absurd claim. This is a direct result of understanding
neither the relational model nor the principles of sound data management.
> Relational databases are centralized around the tuple
> query engine that everything has to go through.
Relational database management systems are a direct application of predicate
logic and of set algebra to the problem of data management. Mathematics is
not centralized around anything. Even the concept of centralization implies
a physical location. All network model and hierarchic model database
management systems, including OID-based object databases, rely on physical
location while the relational model prohibits such reliance.
You are so caught up in the physical aspects of your product, you appear
unable to even conceive of true physical independence.
> With some it's like a
> religion.
The OID folks certainly take a lot on faith. Predicate logic and set algebra
are mathematics not religion.
> According to the relational bigots, "If your application didn't work well
> enough with a relational database, you just didn't work on it hard enough.
If your application didn't work well enough with the dbms you used, it
probably was not an rdbms and if it was, it probably provided insufficient
physical independence, logical independence and support for user-defined
types. If you were using an rdbms with adequate physical independence,
logical independence and support for user-defined types, your applications
would work well without much effort at all.
> You probably should have hired some smarter DBAs and maybe some
consultants.
That's a requirement for location-based data models not for the relational
model. Have you never noticed that those who most adamantly proclaim the
benefits of location-based data models are exactly the programmers who would
most benefit from requiring all users be experts at physical access methods?
> You're ignorant and misinformed."
It's an unpleasant truth but altogether too common. How would you propose to
deal with widespread misinformation and prideful ignorance?
> It's so easy to say that, but here's what really happens. Fred starts
with
> a data model, flattens and normalizes it as they tell him in RDBMS 101.
How do you mean flatten? How does placing object values in an n-dimensional
space flatten anything? Doesn't it flatten things to map them to a linear
OID address space?
> Fred's group loads the database with the data, which is pretty easy
because
> he can do it a table at a time, and he's feeling like things are going
quite
> well. He starts with a simple application prototype with simple queries
and
> things are going great. He's demoing it and he and the database are
looking
> good.
>
> Now he spends months developing Phase I of the application and finds that
> when more data is added and the application needs to zip through some
common
> data structures across multiple tables, performance is getting bad. He's
> already added indexes to all the primary keys. RDBMS 101 says to expect
> this and that he should now DEnormalize the areas that need better
> performance.
Again, you do not understand the relational model nor do you understand the
principles of sound data management. Your hypothetical anecdote above says
more about your own ignorance and misinformation than anything about
relational database management systems.
> Joining primary and foreign keys apparently isn't
> instantaneous despite relational theory and b-trees.
B-trees have nothing to do with relational theory, and logical joins need
not require any processing time assuming the appropriate physical
arrangements--it's a no-op for some arrangements. No-op's are instantaneous
in case you were wondering.
> He does the
> denormalizing and changes the application code.
Again, the above sentence says more about your ignorance and misinformation
than about your alleged topic.
[remainder of irrelevant straw man fantasy snipped]
> Well, he can choose an object database.
And make his problems much worse.
> Ultimately Fred quits and joins a smaller company that's starting a new
> project that needs a database. He talks his new boss into trying an
> object-oriented database. This time his Phase I takes a little longer to
> build, but man, it's fast. Phase II comes in ahead of schedule and it's
> still fast.
Dream on. Phase II is exactly where the effort to deliver will start to grow
exponentially because the lack of physical independence and the lack of
logical independence will require major rewrites to all of the Phase I code.
The business will have to choose between two unpalatable choices: Abandon
important feature requests or pay for extensive rewrites.
> As I mentioned in my other posting, we don't even try to convert people if
> they're not "brilliant or desperate". It's way too expensive to try to
> educate a market
Tell me about it. It's so much easier for marketeers and snake-oil salesmen
to propagate urban myths and to encourage comforting ignorance than it is to
actually educate. One cannot educate in sound-bites. In the end, folks have
to decide to put in the necessary effort for themselves.
> and there are enough applications that HAVE to use an
> alternative that Objectivity's doing fine.
I guess if there is a gun to their head they will put up with just about
anything. Won't they?
> But if XML, XPath and XQuery encourages the use of object traversal ...
which proved unworkable decades ago, they will prove unworkable too.
and
> databases are expected to support those data structures instead of the
> expectation that applications should be designed around the database
You apparently have no concept of the importance of logical independence nor
of the role of views. A dbms should deliver exactly the data required by
each application to that application, and it should do this for all
applications. After all, this is the whole point of data management and of
the separation of data management concerns from application concerns.
> that
> will only help alternative technologies and Fred's choices. That's why I
> think that XML will do what the ODMG was trying to do.
Those who ignore the past are doomed to repeat it.
Carl Rosenberger
[a great story]
Hi Paul,
congratulations for this beautiful story about Fred and his
database troubles.
The only point you didn't mention:
You never get fired for using Oracle. Fred didn't either.
I don't believe in XPath or XQuery. I think both are by far
too overloaded and complex to be adopted fast enough.
We have a widely accepted programming language: Java.
We have a widely accepted language for ad-hoc queries: SQL.
In my opinion the best approaches try to merge thes two
worlds. This is happening from both directions:
There are Java APIs that build representations for SQL.
There are SQL dialects that allow calling Java methods.
Cheers,
Carl
Carl Rosenberger
> > But if XML, XPath and XQuery encourages the use of object traversal ...
>
> which proved unworkable decades ago, they will prove unworkable too.
This statement clearly is wrong:
Object traversal is being used in all object-oriented programming
languages. More than 50% of all new software projects are conducted
with object oriented languages.
Wake up Bob Badour, we are in the object age.
Network databases failed in the past because they did not match the
programming paradigm. Today they do.
Carl
Paul DeWolf
<snip>
> Within the memory space of the application, the application can do
whatever
> it wants. However, if it directly controls location in the dbms, it
dictates
> location outside the application making it unmanageable outside the
> application. The two mutually exclude each other.
See below.
> > > The clustering directives for RDBMSs are specified in the DDL. Yes, it
> > > requires columns on which to cluster, as an RDBMS requires a unique
key
> > > value, even if it must be synthetic, to enforce the uniqueness of the
> > > relations. I too find these to be flaws, but present the arguments as
I
> > > understand them for completeness.
> >
> > Yes, one can cluster up to a point if one adds synthetic columns to the
> data
> > model and they can make it seem transparent with views. But I still
don't
> > think vendors allow you to cluster disparate types
>
> What you think and what actually is are two different things. I suggest
you
> study clusters in oracle:
>
http://storacle.princeton.edu:9001/oracle8-doc/server.805/a58225/ch4a.htm#19
> 90679
Very interesting. It's better than I thought. It's not limited to a single
type, it's limited to 4 or 5.
> >, so if a parent node has
> > twenty different _kinds_ of children, you still can't cluster them
> > effectively.
>
> Whether one will gain any performance benefits having clustered so many
> tables is questionable; however, oracle allows one to cluster up to 32
> tables.
The documentation says that if you use more than 4-5 tables, the clustering
benefits will probably be lost. Say I have a network element (like a
router) that I'd like to cluster with its children which may be many, many
different types (other routers, cards, cabinets, blocks, etc.), I can't
effectively cluster them with Oracle. It's easy and natural with
Objectivity.
Say I want to store an XML document and cluster by nodes and their children
(a fairly obvious thing to do). I guess each child has to be one of 4-5
types. Not very useful.
It would be nice if Oracle understood inheritance. If I have lots of
different kinds of nodes, I either have to create separate tables each with
node information (and join across all tables to find nodes of any type) or
have a node table with a join to every kind of node or I have absolutely
huge table. All three methods are awful.
> > That would make the physical rows have different sizes within
> > the physical table.
>
> So? What's wrong with that?
If they're different sizes you can no longer use the physical row id to
calculate the offset where that row is physically located, you have to have
some kind of lookup. You also have to deal with fragmentation because a new
row won't necessarily fit where an old row was deleted. Nothing that can't
be overcome if you do it right, but it slows things down a bit.
> > Don't relational databases use the fact that the width
> > of each row is constant to be able to calculate the offset to any given
> row?
>
> No. In general, they do not; although, they can if that is the physical
> storage structure desired. Nothing in the relational model either demands
or
> prohibits any physical storage structure. The relational model strongly
> suggests having a wide selection of physical structures from which to
> choose.
Choice is good.
> > > A database that is physically tuned for one application will
necessarily
> > be
> > > sub-optimally tuned for another. To the extent that the data can be
> > > reorganized *without breaking either application*, then the database
can
> > > claim location transparency. For a large, corporate data warehouse,
this
> > can
> > > be a significant issue. For an application that deals with streams of
> > > time-perishable data, it's not so big a deal. I cheerfully trade
> location
> > > transparency for current performance.
> >
> > There's no reason an oo database can't allow reorganization of the data
> > without breaking an application. This is partly the purpose for our
> > physical design framework - to make this a standard process. If an
> > application makes a decision about the physical proximity of two
objects,
> > there's no reason why that has to be a problem to other applications in
an
> > object database.
>
> I do not think you fully appreciate the implications of physical
> independence... <lots of redundancy snipped>
Yes, I fully appreciate the implications of physical independence. I don't
think you fully appreciate the benefits of choice.
It comes down to whether you look for an item of data using direct pointer
or search for it or do something in between. Direct pointers will obviously
be the fastest, but they're horribly restrictive. Pointers to pointers,
handles (or whatever you want to call the layer of indirection) provide more
physical independence.
We have one layer of indirection in our pointers that's built in, which is
what differentiates us and other oo databases from hierarchical databases.
Developers can add more layers of indirection to increase physical
independence.
Except that a query has to start somewhere (there's always a physical
location somewhere at the root no matter what), queries can be considered
totally physically independent. If you expect the data to be a constantly
moving target, maybe that's the right thing for the application.
C++ allows you to have direct access to memory pointers. Java has a layer
of indirection so that the VM can manage memory and control the physical
location of every object, but at the cost of some speed. Not a huge cost
because it just has pointers to pointers and it's generally all in memory.
What you're suggesting is to eliminate all pointers and go find objects
solely according to their attributes.
That's a really significant cost aggravated by the fact that disks are much
slower than memory. Buying enough memory for the cache helps, which is why
Oracle is such a memory hog.
It's fine to preach the benefits of physical independence, but to suggest
it's free is selling snake oil. Please explain to me how joining two rows
with a foreign and primary key can be a no-op. Are you assuming that these
objects are clustered or has some other physical relationship? Are you
assuming they're already in a cache?
We don't force people to use pointers, relational databases force people not
to. Objectivity will allow a developer to have as much physical
independence as they want. You can develop an Objectivity application using
nothing but queries instead of using pointers or name lookups, but you'll
lose performance just like a relational database. If that's all a consumer
wants, we happily tell them to go buy a relational database. If there
aren't many relationships between objects and they mostly want to query by
attribute, it'll work better for them.
Conversely, it would be more honest for relational vendors to admit that if
someone needs to create a network element management (or GIS or CAD/CAM or
scientific) system whose work is 99% object traversal, an object database
will be faster and use fewer resources, rather than have their bigots call
them stupid because they couldn't make their application fit the
requirements of the database.
> > According to the relational bigots, "If your application didn't work
well
> > enough with a relational database, you just didn't work on it hard
enough.
>
> If your application didn't work well enough with the dbms you used, it
> probably was not an rdbms and if it was, it probably provided insufficient
> physical independence, logical independence and support for user-defined
> types. If you were using an rdbms with adequate physical independence,
> logical independence and support for user-defined types, your applications
> would work well without much effort at all.
>
>
> > You probably should have hired some smarter DBAs and maybe some
> consultants.
>
> That's a requirement for location-based data models not for the relational
> model. Have you never noticed that those who most adamantly proclaim the
> benefits of location-based data models are exactly the programmers who
would
> most benefit from requiring all users be experts at physical access
methods?
>
>
> > You're ignorant and misinformed."
>
> It's an unpleasant truth but altogether too common. How would you propose
to
> deal with widespread misinformation and prideful ignorance?
I'm doing it now.
> > It's so easy to say that, but here's what really happens. Fred starts
> with
> > a data model, flattens and normalizes it as they tell him in RDBMS 101.
>
> How do you mean flatten? How does placing object values in an
n-dimensional
> space flatten anything? Doesn't it flatten things to map them to a linear
> OID address space?
There are two forms of flattening. The first is taking inheritance
hierarchies and turn them into a flat list of tables. The second is taking
object hierarchies like trees and networks and loading them into linear
tables. Both cause applications to suffer.
Paul
Bob Badour
> Paul DeWolf wrote:
>
> [a great story]
>
>
> Hi Paul,
>
> congratulations for this beautiful story about Fred and his
> database troubles.
Only another snake-oil salesman could call such a load of marketing
horseshit beautiful. No doubt you expect it to fertilize your own market.
Bob Badour
> Bob Badour wrote:
> > > But if XML, XPath and XQuery encourages the use of object traversal
...
> >
> > which proved unworkable decades ago, they will prove unworkable too.
>
> This statement clearly is wrong:
>
> Object traversal is being used in all object-oriented programming
> languages.
This newsgroup is not comp.object and not comp.programming.object. It is a
comp.databases.* newsgroup. Object traversal proved unworkable as a logical
data model for database management decades ago.
> More than 50% of all new software projects are conducted
> with object oriented languages.
So? Do you have a point?
> Wake up Bob Badour, we are in the object age.
Marketing horseshit. I have been writing object-based and object-oriented
programs for 15 years now.
Date's and Darwen's _The Third Manifesto_ has done more to improve the state
of the art of type inheritance than anything else I have ever seen.
I'm not the one who needs to wake up. Sometimes it feels like I am
surrounded by zombies; although, I run across other alert individuals from
time to time.
> Network databases failed in the past because they did not match the
> programming paradigm. Today they do.
Misinformed, ignorant, marketing horseshit. Both object-oriented programming
languages and network model databases predate the relational model. If they
are going to be so great together, why did the combination suck so badly
back in 1969?
Lee Fesperman
>
> Paul DeWolf wrote:
>
> [a great story]
>
> database troubles.
>
> The only point you didn't mention:
> You never get fired for using Oracle. Fred didn't either.
Sour grapes.
> I don't believe in XPath or XQuery. I think both are by far
> too overloaded and complex to be adopted fast enough.
What's this? You've finally realized that you can't build a better query language using
ad-hoc techniques and location navigation? Good for you!
BTW, I've noticed you scrounging usenet for someone to build a SQL interface to your
object repository. I wish you luck. The problem is that SQL (albeit flawed) gets its
power from the relational model.
> We have a widely accepted programming language: Java.
> We have a widely accepted language for ad-hoc queries: SQL.
>
> In my opinion the best approaches try to merge thes two
> worlds. This is happening from both directions:
> There are Java APIs that build representations for SQL.
> There are SQL dialects that allow calling Java methods.
Yes, and our ORDBMS provides an elegant integration of SQL and Java. FirstSQL/J is a
true relational DBMS with full SQL support amd SQL extensions for calling Java methods
and more. See the review in the current Java Developers Journal for an application using
the Java capabilities.
--
Lee Fesperman, FirstSQL, Inc. (http://www.firstsql.com)
==============================================================
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)
Carl Rosenberger
Lee Fesperman wrote:
> > I don't believe in XPath or XQuery. I think both are by far
> > too overloaded and complex to be adopted fast enough.
>
> What's this? You've finally realized that you can't build a better query
> language using ad-hoc techniques and location navigation?
I still believe that query-by-example is the most natural way
to create a query from within an object oriented language:
You can simply use your class model behind a query form
(the same form you use for displaying and editing the object),
let the user enter data and use the created object to query
the database.
Neither XPath nor XQuery provide this simplicity. It's a big
lot of syntax to learn (or implement) and it's just another
hierarchical language without specific benefits in comparison
to Java (as far as I can see). The only point in creating yet
another language:
People might provide interfaces from a couple of other
programming languages.
> BTW, I've noticed you scrounging usenet for someone to build a SQL
> interface to your object repository.
Cooperation is all about "scrounging". In your terms open source
must be "scrounging" also.
You missed a step in between:
I am looking for people to contribute ideas and possibly work to
the S.O.D.A. API. As you very well know from a long thread some
time ago, I have been looking for comments and contributions long
before the first implementation was running.
If there are suggestions for improvements or for a completely
different and better query-by-example query API, I would be
glad to hear them. Do you call that "scrounging"?
I try to listen to anybody that has good ideas. I have learned
a lot from what relational guys have posted in return to my
postings ( in spite of their troll slang ). Do you call that
"scrounging"?
I do think that they have a point:
Java is flawed.
All relations between objects are RELATIONS (what else :-) )
and in most cases they should work bi-directional.
I have hopes that I can come up with a different object system
some day and possibly it will even be good enough for relational
proponents.
For now Java and C# are mainstream and object databases store
objects better, faster and more efficient than relational
databases because they work with exactly the same object model
as the languages - they understand the languages better.
As Paul has perfectly pointed out further up the thread:
In the most common query usecases, object databases understand
that they do not need to worry about the complete set of
possible joins - they only need to scan the attached objects
in the hierarchy. This clearly must be faster.
...especially if you run method executions over all candidate
objects, as you do it in your product and as we do it with
S.O.D.A.
> The problem is that SQL (albeit flawed) gets its
> power from the relational model.
Where ist the problem?
I have proved to you before that it is dead-simple to create
an object database with all relational features:
Simply store a shadow of the data in a relational database
that runs within the object database.
> > We have a widely accepted programming language: Java.
> > We have a widely accepted language for ad-hoc queries: SQL.
> >
> > In my opinion the best approaches try to merge thes two
> > worlds. This is happening from both directions:
> > There are Java APIs that build representations for SQL.
> > There are SQL dialects that allow calling Java methods.
>
> Yes, and our ORDBMS provides an elegant integration of SQL and Java.
> FirstSQL/J is a true relational DBMS with full SQL support amd SQL
> extensions for calling Java methods and more. See the review in the
> current Java Developers Journal for an application using
> the Java capabilities.
I wrote the above statement with your product in mind.
Do you still serialize objects?
Doesn't the system break when someone adds a field to a class?
I still don't think that it's ideal that all objects need to be
instantiated to query them but this does work very good for lots
of RAM and/or little data.
In comparison to your system, I still think it's a lot simpler
to store the complete object network as it comes.
I challenge you for a "howto" and performance race.
Here is a possible roadmap:
(1) Create a hierarchy of three by three classes, three
levels of inheritance, trees of depth three.
(2) Store 10000 instances of a mixture of objects from
the above classes and time the performance.
(3) Add one more field to each class.
(4) Store another 10000 instances.
(5) Time a flat query.
(6) Time a deep query.
(7) Modify all objects of one class and stop the time.
(8) Instantiate all objects and stop the time.
These are my "weapons". Please choose yours.
Kind regards,
Carl
--
Carl Rosenberger
db4o - database for objects - http://www.db4o.com
Bob Badour
>
> Lee Fesperman wrote:
> > > I don't believe in XPath or XQuery. I think both are by far
> > > too overloaded and complex to be adopted fast enough.
> >
> > What's this? You've finally realized that you can't build a better query
> > language using ad-hoc techniques and location navigation?
>
> I still believe that query-by-example is the most natural way
> to create a query from within an object oriented language:
That's not a query: That's just restrict.
> I do think that they have a point:
> Java is flawed.
> All relations between objects are RELATIONS (what else :-) )
> and in most cases they should work bi-directional.
They all work bi-directional in any case. The relational model just requires
a lot less looping.
> I have hopes that I can come up with a different object system
> some day and possibly it will even be good enough for relational
> proponents.
You would have to learn the basic principles of data management, first, and
I don't expect you will ever do that.
> For now Java and C# are mainstream and object databases store
> objects better, faster and more efficient than relational
Bullshit. Marketing bullshit.
> As Paul has perfectly pointed out further up the thread:
> In the most common query usecases, object databases understand
> that they do not need to worry about the complete set of
> possible joins - they only need to scan the attached objects
> in the hierarchy.
As I made clear further up the thread, one can choose any physical layout
with the relational model so many joins are no-ops, in any case. Since an
rdbms will allow any physical layout, it can duplicate the performance
characteristics of any other dbms.
> This clearly must be faster.
Misinformed, ignorant tripe.
> > The problem is that SQL (albeit flawed) gets its
> > power from the relational model.
>
> Where ist the problem?
Tacking SQL onto a navigational object database will leave the result with
all the problems and weaknesses of the navigational object database.
> I have proved to you before that it is dead-simple to create
> an object database with all relational features:
> Simply store a shadow of the data in a relational database
> that runs within the object database.
In other words, it is easy to cripple an rdbms by forcing users to go
through a navigational object interface. I understand this; I just don't
understand why anybody would desire it.
Carl Rosenberger
> > I still believe that query-by-example is the most natural way
> > to create a query from within an object oriented language:
>
> That's not a query: That's just restrict.
Define query please.
> > I do think that they have a point:
> > Java is flawed.
> > All relations between objects are RELATIONS (what else :-) )
> > and in most cases they should work bi-directional.
>
> They all work bi-directional in any case. The relational model just requires
> a lot less looping.
No, object oriented languages do not automatically work bi-directional.
A pointer from one object in memory points to other places in memory
where it's member objects are located. This pointer is a physical address,
it can't be reversed. If you only have access to one of the member objects
at the destination address, you have no possibility to find all the
objects that reference it.
Another example that makes this clear:
class Person{
Address address;
public static void main(String[] args){
Person person;
// Person constructed somewhere
bobBadourIsWrong(person.address);
}
void bobBadourIsWrong(Address address){
// no access to the Person here;
}
}
> > For now Java and C# are mainstream and object databases store
> > objects better, faster and more efficient than relational
>
> Bullshit. Marketing bullshit.
No.
Imagine an object database as a list of pointers. Imagine a
physical implementation with direct pointers from one object
to the next, with *zero* indirections. You can't beat that
with a relational databases, since you have to store
additional keys somewhere.
Your logical independance costs performance, because it needs
additional indirections.
Here is an example of the fastest and smallest possible notation
for a collection that stores any number of words, neglecting
compression algorithms and providing access to each word
individually:
4 // the number of words stored
5 // address of word 1
6 // address of word 2
13 // address of word 3
16 // address of word 4
3 // length of word 1
B
o
b
6 // length of word 2
B
a
d
o
u
r
2 // length of word 3
i
s
5 // length of word 4
w
r
o
n
g
This is a phyisical implementation with direct pointers.
Beat the efficiency with a relational system!
The above is trivial for words. In practice objects only
consist of pointer lists. An object database can traverse
the graph directly using these pointers. A relational
database has to perform an index lookup for every single
relation.
By your definition you need logical independance. This
independance costs performance because it needs an extra
computing step.
> As I made clear further up the thread, one can choose any physical layout
> with the relational model so many joins are no-ops, in any case. Since an
> rdbms will allow any physical layout, it can duplicate the performance
> characteristics of any other dbms.
Strictly navigating with object databases, ALL relationships
outside of the tree are no-ops, not only "many".
> > I have proved to you before that it is dead-simple to create
> > an object database with all relational features:
> > Simply store a shadow of the data in a relational database
> > that runs within the object database.
>
> In other words, it is easy to cripple an rdbms by forcing users to go
> through a navigational object interface. I understand this; I just don't
> understand why anybody would desire it.
Imagine you have an object of a class Person in your Java code,
with an attached address and an attached phone number.
How can you beat one single statement to store this Person:
database.store(person);
No addititonal code, no setting up tables. Please provide evidence
of a more efficient line of code that stores an object.
Bob Badour
> Bob Badour wrote:
> > > I still believe that query-by-example is the most natural way
> > > to create a query from within an object oriented language:
> >
> > That's not a query: That's just restrict.
>
> Define query please.
A question.
> > > I do think that they have a point:
> > > Java is flawed.
> > > All relations between objects are RELATIONS (what else :-) )
> > > and in most cases they should work bi-directional.
> >
> > They all work bi-directional in any case. The relational model just
requires
> > a lot less looping.
>
> No, object oriented languages do not automatically work bi-directional.
I never said anything about automatically; hence, the reference to all the
looping required by your product and others like it.
> A pointer from one object in memory points to other places in memory
> where it's member objects are located. This pointer is a physical address,
> it can't be reversed.
Sure it can. All the program has to do is loop through all the places that
might have a pointer to a given address and one has reversed the direction
of the reference. Duh.
> If you only have access to one of the member objects
> at the destination address, you have no possibility to find all the
> objects that reference it.
If you are only allowed access to one object, you don't need pointers.
'Cause what is there to point at?
> > > For now Java and C# are mainstream and object databases store
> > > objects better, faster and more efficient than relational
> >
> > Bullshit. Marketing bullshit.
>
> No.
More bullshit.
[piles of bullshit removed for expediency]
> > As I made clear further up the thread, one can choose any physical
layout
> > with the relational model so many joins are no-ops, in any case. Since
an
> > rdbms will allow any physical layout, it can duplicate the performance
> > characteristics of any other dbms.
>
> Strictly navigating with object databases, ALL relationships
> outside of the tree are no-ops, not only "many".
Bullshit.
> > > I have proved to you before that it is dead-simple to create
> > > an object database with all relational features:
> > > Simply store a shadow of the data in a relational database
> > > that runs within the object database.
> >
> > In other words, it is easy to cripple an rdbms by forcing users to go
> > through a navigational object interface. I understand this; I just don't
> > understand why anybody would desire it.
>
> Imagine you have an object of a class Person in your Java code,
> with an attached address and an attached phone number.
>
> How can you beat one single statement to store this Person:
Lots of ways.
Alfredo Novoa
> Date's and Darwen's _The Third Manifesto_ has done more to improve the state
> of the art of type inheritance than anything else I have ever seen.
I agree. I have learnt more about OO with The Third Manifesto than
with any other book.
Their arguments against bundling types and operators together were an
eye opening for me.
Regards
Alfredo
Paul DeWolf
I'm glad you've gotten some good information from The Third Manifesto. I've
heard that it's packed with useful information. I've also heard that the
model has a couple major flaws that form the reasons that it hasn't been
implemented.
The biggest flaw is the fact that "pointers" are still not allowed.
Everything is still done by query. This becomes a big problem when you want
to provide one form of inheritance.
Date's model provides a good method to model inheritance where the subtypes
are more restrictive, what oo-programmers call improper inheritance. The
most common example is having circles inherit from ellipse, where a circle
is a special case of ellipse where the x and y coordinates are the same.
Date's model does not provide the means to efficiently define a subclass of
ellipse like "filled ellipse" that would have an extra member like
"fillcolor". Although improper inheritance isn't as improper as some would
claim, the other use of inheritance is the more useful form.
From a practical point of view you really must be able to provide "proper"
inheritance in an efficient way to support real-life situations.
XML is a great example, where you have 12 different types of nodes. Having
to model each of those as completely independent types with no relationship
to "node" simply doesn't work well in a relational database. This is why
Oracle is now providing a completely separate way of storing XML independent
of their tables and making a big deal about it.
They CAN'T put the XML in their tables and allow you to store and read it
efficiently. Even they have acknowledged it. BTW, their separate "native"
XML storage functions are more like providing a separate file I/O interface
than a database interface, so you still can't do the things you need to do
at a node level. They provide an SQL interface as well as a file interface,
but it's still not good for traversal.
Since it still doesn't provide "proper" inheritance, Date's model doesn't
really help. You can have columns of any class, which is like using
embedded classes in a C++ class. But, since he does everything by value,
not by reference, you effectively end up with 12 different tables that
really need to be normalized.
If you normalize, you end up with more joins and joins ARE horribly
expensive. This is where the model fails. The only way Date suggests to
make the joins less expensive is to use physical clustering (Bob's "no-op"),
which ends up violating the "physical independence" even more than using
pointers does.
BTW, I'd invite a rational discussion of this. Flame wars like Bob
instigates aren't much fun (at least to me) and just get in the way of real
understanding. They also can kill newsgroups, (perhaps one of Bob's
motivations).
Paul
"Alfredo Novoa" <alf...@ncs.es> wrote in message
news:e4330f45.03051...@posting.google.com...
Lee Fesperman
>
> Lee Fesperman wrote:
> > BTW, I've noticed you scrounging usenet for someone to build a SQL
> > interface to your object repository.
>
> Cooperation is all about "scrounging". In your terms open source
> must be "scrounging" also.
Sorry, I couldn't find a polite way to describe asking someone to fit a square peg in a
round hole. Like it or not, the real power of SQL comes from the relational model.
> You missed a step in between:
> I am looking for people to contribute ideas and possibly work to
> the S.O.D.A. API. As you very well know from a long thread some
> time ago, I have been looking for comments and contributions long
> before the first implementation was running.
>
> If there are suggestions for improvements or for a completely
> different and better query-by-example query API, I would be
> glad to hear them. Do you call that "scrounging"?
>
> I try to listen to anybody that has good ideas. I have learned
> a lot from what relational guys have posted in return to my
> postings ( in spite of their troll slang ). Do you call that
> "scrounging"?
You may try, but you don't listen.
I responded to your 'some time ago' thread with devastating criticism that you blithely
ignored.
I don't see much intellectual honesty in calling me a troll why you indulge in
fantasies, build smoke castles in the sky.
> I do think that they have a point:
> Java is flawed.
> All relations between objects are RELATIONS (what else :-) )
> and in most cases they should work bi-directional.
Objects are just programming artifacts. RELATIONS between them are ad-hoc connections
without any fundamental theory.
> I have hopes that I can come up with a different object system
> some day and possibly it will even be good enough for relational
> proponents.
That is an immense undertaking.
You've only shown qualifications for being a dreamweaver, none for accomplishing either
task.
BTW, have you looked at Chris Dat's efforts in this area?
> For now Java and C# are mainstream and object databases store
> objects better, faster and more efficient than relational
> databases because they work with exactly the same object model
> as the languages - they understand the languages better.
I prefer a database that understands the application better rather than the programming
language.
The computing world has moved on from assembly languages to interpreted languages
because they realized that functionality is as important as performance. You are still
saying that performance outweighs all else.
You should take a look at the current (long) thread on comp.databases where Pick
adherents are making the same argument.
> > The problem is that SQL (albeit flawed) gets its
> > power from the relational model.
>
> Where ist the problem?
Your lack of understanding.
> I have proved to you before that it is dead-simple to create
> an object database with all relational features:
> Simply store a shadow of the data in a relational database
> that runs within the object database.
You have proved nothing.
An RDBMS is not just a collection of tables and rows.
It is an organic whole that includes security, constraint maintenance, transactions,
optimization, all defined and accessed with a high level declarative language.
Your scheme would require extensive programming and would be a poor substitute for an
RDBMS. It would be a true shadow.
> > > We have a widely accepted programming language: Java.
> > > We have a widely accepted language for ad-hoc queries: SQL.
> > >
> > > In my opinion the best approaches try to merge thes two
> > > worlds. This is happening from both directions:
> > > There are Java APIs that build representations for SQL.
> > > There are SQL dialects that allow calling Java methods.
> >
> > Yes, and our ORDBMS provides an elegant integration of SQL and Java.
> > FirstSQL/J is a true relational DBMS with full SQL support amd SQL
> > extensions for calling Java methods and more. See the review in the
> > current Java Developers Journal for an application using
> > the Java capabilities.
>
> I wrote the above statement with your product in mind.
I figured. That's why I responded.
> Do you still serialize objects?
> Doesn't the system break when someone adds a field to a class?
You can add fields when using serialization.
However, it is a completely different issue with our system versus yours.
Our data model is radically different from yours. See below.
> I still don't think that it's ideal that all objects need to be
> instantiated to query them but this does work very good for lots
> of RAM and/or little data.
>
> In comparison to your system, I still think it's a lot simpler
> to store the complete object network as it comes.
See below.
> I challenge you for a "howto" and performance race.
>
> Here is a possible roadmap:
> (1) Create a hierarchy of three by three classes, three
> levels of inheritance, trees of depth three.
> (2) Store 10000 instances of a mixture of objects from
> the above classes and time the performance.
> (3) Add one more field to each class.
> (4) Store another 10000 instances.
> (5) Time a flat query.
> (6) Time a deep query.
> (7) Modify all objects of one class and stop the time.
> (8) Instantiate all objects and stop the time.
>
> These are my "weapons". Please choose yours.
That just reveals an object repository mindset.
A DBMS needs to service many types of users (applications).
You and I have discussed extensively on usenet why the object model handles that
situation poorly.
You seem to be a 'dreamweaver' like Xdb (James). Or, should I call it marketing?
Here's my marketing:
The Relational Model is a well-researched and respected model for DBMSs, but it has
suffered from poor implementations, especially by the major vendors. We are doing
something about it. We are building a better implementation of the Relational Model for
the benefit of users.
We support objects as an implementation of relational 'domains'. These are simple
independent objects, not complex lattices of objects. To model lattices, we use tables
and rows.
Another area where we're striving for a better relational implementation is the
Optimizer. The Optimizers for major vendors are poorly engineered.
I'm not denying that a well tuned query can perform spectacularly on these systems. It
is the necessity of expert tuning that I object to. Two equivalent query formulations
can exhibit several orders of magnitude difference in performance.
These products are stealing the benefits of the relational model with their poor
implementations. They encourage 'denormalized' tables, reduced integrity and other hacks
to achieve performance. Of course the need for extensive tuning also ties you to a
specific product.
This is the relational achilles heel that you, and others, are pounding on. However,
your solutions require as much specialized programming as the major SQL DBMSs.
Our Optimizer is more comprehensive and fundamentally sound. It provides 'even'
optimization and deals adroitly with complex, nested formulations. Rewriting a query to
achieve performance is rarely needed.
This opens the true capabilities of the relational model to users.
Carl Rosenberger
> > I try to listen to anybody that has good ideas. I have learned
> > a lot from what relational guys have posted in return to my
> > postings ( in spite of their troll slang ). Do you call that
> > "scrounging"?
>
> fantasies, build smoke castles in the sky.
I never called you a troll and excuse me, if that impression
came across. If you look at the thread closely, there are some
other people that clearly deserve that term.
I try to stay away from direct personal insults as long as I can,
since they never help to produce anything useful in discussions.
I rather ignore people before wasting my time. When "horsehit"
is all that comes back as an argument, it clearly is time to stop
the discussion.
By the way:
I do feel insulted by some of the terms that you use:
"scrounging", "dreamweaver", "Your lack of understanding".
What is your deeper intention?
If you don't have any interest in what I write, please read someone
elses posts. If you don't want to talk to me, please respond to
someone else.
> > All relations between objects are RELATIONS (what else :-) )
> > and in most cases they should work bi-directional.
>
> Objects are just programming artifacts. RELATIONS between them are
> ad-hoc connections without any fundamental theory.
Now thats a really funny statement.
What if I create an object to represent a row in a table.
Would a relation to another row be an "ad-hoc connection
without any fundamental theory". ?
Objects can represent ANYTHING. It's up to the programmer to
decide on the meaning that it uses for them.
Objects can simulate a relational system perfectly.
Your database engine is written in an object-oriented language.
Alphora Dataphor ("Gods own engine" to put in in the words of
the Tutorial-D worshipers) is written in an object-oriented
language.
Of course it is possible to produce a relational sound system
from objects.
> BTW, have you looked at Chris Dat's efforts in this area?
Yes.
Alphora is supposed to be the outcome isn't it?
Judging from the newsgroup traffic, the project is dead,
in spite of the latest 2.0 Beta 1 release.
Alfredo Novoa seems to have been one of the only people
experimenting and in dm-discuss he now claims that he
wants to write his own engine.
> > I have proved to you before that it is dead-simple to create
> > an object database with all relational features:
> > Simply store a shadow of the data in a relational database
> > that runs within the object database.
>
> You have proved nothing.
>
> An RDBMS is not just a collection of tables and rows.
>
> It is an organic whole that includes security, constraint maintenance, transactions,
> optimization, all defined and accessed with a high level declarative language.
>
> Your scheme would require extensive programming and would be a poor substitute for an
> RDBMS. It would be a true shadow.
I could use all the security, constraint maitenance and optimization
from the relational database under the hood, couldn't I?
How can you know in advance, what I am up to?
If you have constructive criticism that's fine but please guess
your own future.
> > I challenge you for a "howto" and performance race.
>
> Here's my marketing:
[empty theory bubbles snipped]
I was not talking about marketing.
I challenged you for a performance RACE to store objects.
What are your conditions?
> Our Optimizer is more comprehensive and fundamentally sound. It provides 'even'
> optimization and deals adroitly with complex, nested formulations. Rewriting a query to
> achieve performance is rarely needed.
Now that's great.
Let's race it against our engine.
Bob Badour
> Lee Fesperman wrote:
> > > I try to listen to anybody that has good ideas. I have learned
> > > a lot from what relational guys have posted in return to my
> > > postings ( in spite of their troll slang ). Do you call that
> > > "scrounging"?
> >
> > I don't see much intellectual honesty in calling me a troll why you
indulge in
> > fantasies, build smoke castles in the sky.
>
> I never called you a troll and excuse me, if that impression
> came across. If you look at the thread closely, there are some
> other people that clearly deserve that term.
>
> I try to stay away from direct personal insults as long as I can,
> since they never help to produce anything useful in discussions.
If only you would strive to produce anything useful in discussions. If only!
> I rather ignore people before wasting my time. When "horsehit"
> is all that comes back as an argument, it clearly is time to stop
> the discussion.
Are you saying nobody should talk to you? Or have you started to offer
anything else to discussions?
> By the way:
> I do feel insulted by some of the terms that you use:
> "scrounging", "dreamweaver", "Your lack of understanding".
>
> What is your deeper intention?
How long have you suffered from these paranoid fears?
> If you don't have any interest in what I write, please read someone
> elses posts.
If you don't want intelligent, educated people to read your posts, post them
where intelligent, educated people won't see them.
> If you don't want to talk to me, please respond to
> someone else.
What if he wants to speak to the lurkers?
> > > All relations between objects are RELATIONS (what else :-) )
> > > and in most cases they should work bi-directional.
> >
> > Objects are just programming artifacts. RELATIONS between them are
> > ad-hoc connections without any fundamental theory.
>
> Now thats a really funny statement.
>
> What if I create an object to represent a row in a table.
You have created an ad-hoc object to represent a row in a table.
> Objects can represent ANYTHING.
They are okay for physical representation, I guess. But I am hoping for
better in days to come.
> It's up to the programmer to
> decide on the meaning that it uses for them.
Except that the programmer has no sound method to communicate that meaning
to anyone or anything. Had the programmer used relations, the predicates
would communicate the semantics explicitly.
> Objects can simulate a relational system perfectly.
So can a turing machine. Are you likewise suggesting that turing machines
are a suitable solution for general database management problems?
> Your database engine is written in an object-oriented language.
> Alphora Dataphor ("Gods own engine" to put in in the words of
> the Tutorial-D worshipers) is written in an object-oriented
> language.
Um, if not a programming language, what did you expect them to write
programmes in? Peanut butter?
> Of course it is possible to produce a relational sound system
> from objects.
With some education, discipline and effort, you are correct. One can also
produce them without objects.
> > BTW, have you looked at Chris Dat's efforts in this area?
>
> Yes.
>
> Alphora is supposed to be the outcome isn't it?
No, the outcome was _The Third Manifesto_ coauthored with Hugh Darwen.
Alphora took it from there to a product.
> > > I have proved to you before that it is dead-simple to create
> > > an object database with all relational features:
> > > Simply store a shadow of the data in a relational database
> > > that runs within the object database.
> >
> > You have proved nothing.
> >
> > An RDBMS is not just a collection of tables and rows.
> >
> > It is an organic whole that includes security, constraint maintenance,
transactions,
> > optimization, all defined and accessed with a high level declarative
language.
> >
> > Your scheme would require extensive programming and would be a poor
substitute for an
> > RDBMS. It would be a true shadow.
>
> I could use all the security, constraint maitenance and optimization
> from the relational database under the hood, couldn't I?
Um, let's see. You want to create a relational dbms from a relational dbms.
Are you sure the effort is not too ambitious for you?
> How can you know in advance, what I am up to?
I do not. Even if I could read minds, I think I would avoid yours. However,
I can extrapolate the views you have expressed previously to get a general
idea of the rationality of what you might be up to. I expect Lee can too.
> If you have constructive criticism that's fine but please guess
> your own future.
What good would one of those do? They roll off you like water off a duck's
back.
> I was not talking about marketing.
Since when? Did I miss something?
Paul DeWolf
Be happy that Bob and Lee are on the other side. If they were arguing our
positions, I think they'd be causing more harm than they do now. I think I
heard that Larry Ellison isn't so public anymore because they found it hurt
Oracle sales.
I just looked at the SODA site on sourceforge. It sounds very interesting,
and I'll try to look more deeply when I get the chance. A common, simple
interface would do tremendous good to all oo-databases. I'd also like to
learn more from you about your views on XPath and XQuery.
Cheers,
Paul
"Carl Rosenberger" <ca...@db4o.com> wrote in message
news:b9rsj0$gd0$07$1...@news.t-online.com...
andrewst
Originally posted by Paul Dewolf
> standard) is that it only supports scoping by type or table.
> Since it only
> supports relationships through joins it doesn't scale well as
> the joins
> become complex and the tables get very large. SQL expects me
> to find my
> children by looking among all the children in the world, rather
> than looking
> in my own house.
>
I may as well say "an ODBMS can't find a named child unless I know what
house she lives in". Probably equally naive.
Originally posted by Paul Dewolf
> Even if a database system provides ways to define groups of objects in
> contexts, there's no efficient way to specify that unit through
> SQL without
> using a join. This is why you can't put an SQL interface on an object
> database and still have it perform well. It's the language that
> cripples
> the model.
>
Joins work just fine. It's the object "data model" that's a cripple.
--
Posted via http://dbforums.com
Carl Rosenberger
> > This is what I think is the fundamental problem with SQL (at least the
> > standard) is that it only supports scoping by type or table.
> > Since it only
> > supports relationships through joins it doesn't scale well as
> > the joins
> > become complex and the tables get very large. SQL expects me
> > to find my
> > children by looking among all the children in the world, rather
> > than looking
> > in my own house.
>
> You are having a laugh, are you not? Never heard of indexes?
> I may as well say "an ODBMS can't find a named child unless I know what
> house she lives in". Probably equally naive.
[...]
> Joins work just fine.
Paul and his crew provide the engine for some of the most complex
huge databases. Your "Joins work just fine" statement may not be
adequate for that scale. In huge databases, you never have enough
performance.
A very simple example:
Imagine you have a database with 2 billion of hydrogen atoms, joined
together to one billion of hydrogen molecules. If you have one atom
and want to find the corresponding one, your index solution will have
to walk the complete tree consisting of 2 billion of index entries.
They may not fit into RAM, I am afraid. Alright then, if you have
a perfectly balanced tree on your hard disk, you will need at least
31 (2 ^ 31 = 2147483648) reads to your disk and 31 compare operations.
An object database typically references objects directly. Access time
is constant:
Walk one pointer!
...no matter if you have 10 atoms, 2 billion, or 42 fantastillions.
You can get away with one singel read operation.
That's the best performance you can get.
In huge databases, index construction and maintenance can also become
a performance problem.
If you access objects on the intended reference path (and yes, there
are applications that do that) you may get along completely without
indices.
Joins have a problem with null.
Joins do not have a viewpoint on the data so the optimzer has to guess,
where to start and what to do next.
If you have a deep class hierarchy, your queries can become
very very complex.
Imagine an inheritance hierarchy of 10 classes.
How many joins will you use?
With object databases, the query will remain dead-simple:
Choose whatever extent from the hierarchy that you wish and
query for it.
Just a sample:
Class1
Class2
...
...
Class9
Class10
If you want all data contained in a class 9 object:
Object database pseudocode:
database.get(class9.class);
Relational pseudocode:
SELECT FROM Class1, Class2, ... , Class9, Class10
WHERE Class1.pkey = Class2.fkey
AND Class2.pkey = Class3.fkey
...
...
AND Class8.pkey = Class9.fkey
AND Class9.pkey = Class10.fkey
Guess what's more work to write, more work to maintain.
Guess what will run faster.
> It's the object "data model" that's a cripple.
I wouldn't call it a "cripple" but I fully agree that it's not
perfect.
It does work quite good for application development.
Type-safety (do you have that in relations ?) and modern IDE tool
support (anything equivalent to refactor relational models as
quickly as you can refactor classes with Eclipse?) make development
very very efficient.
The commonly used object model may not be theoretically correct but
it proves to get the job done. In modern IT, minimizing development
time and minimizing development cost are more important than
theoretically more correct data models. It's all about becoming
profitable. Fast!
If you question the principle benefits of object-oriented development,
you may be the one that's having a laugh.
X-post and Fup to comp.databases.theory.
I feel like a whipping today.
Lee Fesperman
>
> Lee Fesperman wrote:
> > > I try to listen to anybody that has good ideas. I have learned
> > > a lot from what relational guys have posted in return to my
> > > postings ( in spite of their troll slang ). Do you call that
> > > "scrounging"?
> >
> > I don't see much intellectual honesty in calling me a troll why you indulge in
> > fantasies, build smoke castles in the sky.
>
> I never called you a troll and excuse me, if that impression
> came across. If you look at the thread closely, there are some
> other people that clearly deserve that term.
I'm a relational guy who has posted reponses to your articles, and your response was to
me. You didn't distinguish except in your own mind.
> I try to stay away from direct personal insults as long as I can,
> since they never help to produce anything useful in discussions.
> I rather ignore people before wasting my time. When "horsehit"
> is all that comes back as an argument, it clearly is time to stop
> the discussion.
>
> By the way:
> I do feel insulted by some of the terms that you use:
> "scrounging", "dreamweaver", "Your lack of understanding".
You snipped my explanation of scrounging. I'll deal with the others in context.
> What is your deeper intention?
Dispelling fantasies?
> If you don't have any interest in what I write, please read someone
> elses posts. If you don't want to talk to me, please respond to
> someone else.
This public usenet, not your private soapbox.
As Bob devined, I'm speaking to lurkers ;^)
> > > All relations between objects are RELATIONS (what else :-) )
> > > and in most cases they should work bi-directional.
> >
> > Objects are just programming artifacts. RELATIONS between them are
> > ad-hoc connections without any fundamental theory.
>
> Now thats a really funny statement.
Either you don't understand, or you are being insulting.
> What if I create an object to represent a row in a table.
> Would a relation to another row be an "ad-hoc connection
> without any fundamental theory". ?
>
> Objects can represent ANYTHING. It's up to the programmer to
> decide on the meaning that it uses for them.
Ad-hoc, without any fundamental theory.
Earlier, I asked you for a testable summary of the difference between a good object
design and one that is not as good.
You don't have to answer ... no one can.
Here's one for a good database design under the relational model:
+ All relations are normalized.
+ Every relation has a proper primary key.
+ Links between relations as declared with foreign keys.
+ Business rules are declared as constraints.
> Objects can simulate a relational system perfectly.
>
> Your database engine is written in an object-oriented language.
> Alphora Dataphor ("Gods own engine" to put in in the words of
> the Tutorial-D worshipers) is written in an object-oriented
> language.
>
> Of course it is possible to produce a relational sound system
> from objects.
Come on, you are not that naive. Perhaps you think the lurkers are.
You're confusing the implementation language and what is being implemented. If I write a
text-editor in an object-oriented language, I'm not writing an 'object' text-editor.
The relational model is a logical model; it places no restrictions on the physical
implementation and storage. The physical implementation and storage can be based
entirely on objects.
In fact, that is exactly what we do. In memory mode, our DBMS stores the database
information (tables and rows) in memory as objects.
However, that is just an implementation detail, invisible to the users of the system. It
just as well could have been implemented in a non-OO language.
> > > I have proved to you before that it is dead-simple to create
> > > an object database with all relational features:
> > > Simply store a shadow of the data in a relational database
> > > that runs within the object database.
> >
> > You have proved nothing.
> >
> > An RDBMS is not just a collection of tables and rows.
> >
> > It is an organic whole that includes security, constraint maintenance,
> > transactions, optimization, all defined and accessed with a high
> > level declarative language.
> >
> > Your scheme would require extensive programming and would be a poor
> > substitute for an RDBMS. It would be a true shadow.
>
> I could use all the security, constraint maitenance and optimization
> from the relational database under the hood, couldn't I?
>
> How can you know in advance, what I am up to?
I know that implementing an RDBMS is not 'dead simple'.
> If you have constructive criticism that's fine but please guess
> your own future.
How do you constructively critique a bunch of vague assertions?
> > > I challenge you for a "howto" and performance race.
> >
> > Here's my marketing:
>
> [empty theory bubbles snipped]
Cute. That's not intended as insulting?
> I was not talking about marketing.
>
> I challenged you for a performance RACE to store objects.
>
> What are your conditions?
>
> > Our Optimizer is more comprehensive and fundamentally sound. It
> > provides 'even' optimization and deals adroitly with complex,
> > nested formulations. Rewriting a query to achieve performance
> > is rarely needed.
>
> Now that's great.
Sarcasm?
> Let's race it against our engine.
It's apples and oranges, again.
I'm describing an optimizer for a declarative database language.
Your engine has neither a declarative language nor an optimizer.
The stated (in the text you snipped) purpose is to eliminate hand optimization.
Your engine requires hand optimization (and you think you are improving on Oracle?)
I win by default. No sarcasm, just cold, hard facts.
Mikito Harakiri
> andrewst wrote:
> A very simple example:
> Imagine you have a database with 2 billion of hydrogen atoms, joined
> together to one billion of hydrogen molecules. If you have one atom
> and want to find the corresponding one, your index solution will have
> to walk the complete tree consisting of 2 billion of index entries.
> They may not fit into RAM, I am afraid. Alright then, if you have
> a perfectly balanced tree on your hard disk, you will need at least
> 31 (2 ^ 31 = 2147483648) reads to your disk and 31 compare operations.
> An object database typically references objects directly. Access time
> is constant:
> Walk one pointer!
> ...no matter if you have 10 atoms, 2 billion, or 42 fantastillions.
> You can get away with one singel read operation.
> That's the best performance you can get.
>
> In huge databases, index construction and maintenance can also become
> a performance problem.
Wrong arithmetics. A typical B-tree having 1G nodes will be 4 levels deep. 3
levels would typically be cached. Therefore, we have 1 random IO, the same
as in the OODB case where the foreigh key reference is expressed explicitly
by a pointer.
Bob Badour
news:akUwa.11$MU1...@news.oracle.com...
That's a very good point. Clustering will further reduce the single random
IO to zero.
Mikito Harakiri
> Clustering will further reduce the single random IO to zero.
I'm skeptical about clustering idea. Physical locality is a goal that is
difficult to achieve. When implemented it is so complex that requires
extraordinary DBA effort to maintain it. I was never convinced that
mastering Oracle Clusters, for example, is worth the effort.
In general, we can't be certain how many layers of indirection is between
the data stored on disk and query output. We might think that blocks x and y
are collocated, but filer has striping. Also, storing records with the same
join key value in the same block migh be good for that particular join
order, but may adversely affect other queries. Then, query optimization is
so overwhelmed with problems that it simply couldn't devote sufficient
attention to developing a convincing cost estimation model in the clustering
case. Finally, clustering is only important for sequential-read devices (aka
disks), and would progressively become less relevant as soon as
random-access persistent storage (solid state disks, etc) become more
common.
Bob Badour
> "Bob Badour" <bba...@golden.net> wrote in message
> news:RfVwa.58$oC4.13...@mantis.golden.net...
> > Clustering will further reduce the single random IO to zero.
>
> I'm skeptical about clustering idea. Physical locality is a goal that is
> difficult to achieve. When implemented it is so complex that requires
> extraordinary DBA effort to maintain it. I was never convinced that
> mastering Oracle Clusters, for example, is worth the effort.
I can only assume the way oracle implements clustering is more complex than
it needs to be.
> In general, we can't be certain how many layers of indirection is between
> the data stored on disk and query output. We might think that blocks x and
y
> are collocated, but filer has striping. Also, storing records with the
same
> join key value in the same block migh be good for that particular join
> order, but may adversely affect other queries.
Absolutely. And creating an index means there is redundant information that
must be maintained. And adding physical pointers means there are redundant
structural artifacts to maintain. etc.
Every physical structure biases performance in favour of some uses and
against others. That's just the nature of the beast no matter the logical
data model.
Your comment does not invalidate the point that a join need not have any
performance cost.
> Then, query optimization is
> so overwhelmed with problems
Perhaps your optimizer is, but I am not convinced this has to be.
> that it simply couldn't devote sufficient
> attention to developing a convincing cost estimation model in the
clustering
> case.
Tell me, what is the physical difference between clustering 25 binary
relations on a common key vs. storing a 26-ary relation with all non-key
columns nullable? It seems to me they should have identical cost estimation
models.
> Finally, clustering is only important for sequential-read devices (aka
> disks), and would progressively become less relevant as soon as
> random-access persistent storage (solid state disks, etc) become more
> common.
It has potential benefits for any block-read device that operates with
significant latency or at a significantly slower speed than the cpu.
Adrian Veith
Carl Rosenberger wrote:
> andrewst wrote:
>
> They may not fit into RAM, I am afraid. Alright then, if you have
> a perfectly balanced tree on your hard disk, you will need at least
> 31 (2 ^ 31 = 2147483648) reads to your disk and 31 compare operations.
>
> An object database typically references objects directly. Access time
> is constant:
> Walk one pointer!
> ...no matter if you have 10 atoms, 2 billion, or 42 fantastillions.
> You can get away with one singel read operation.
> That's the best performance you can get.
Sorry Carl, but this is really a bad example. like Mikito said, a B-tree
needs only 4 to 5 levels for this.
But you can beat even this, if your dbms internally optimizes its
structures for foreign keys. than a join using a foreign key would be
also virtually a one op. Thus you can have constant access time too, but
without loosing the flexibility of the relational theory.
I implement this technic in our Gonzales database server (it is NOT a
relational database, but you could use this technic in a pure relational
system as well).
As a side effect we are able to write queries where we use the foreign
key as an implicit join:
select from a_table
where b_key::c_key::value = "xy"
instead of
select from a_table, b_table, c_table
where a_table.b_key = b_table.id and b_table.c_key = c_table.id and
c_table.value = "xy"
b_key is foreign key to b_table.id
c_key is foreign key to c_table.id
the operation :: dereferences a foreign key to the row where it "points"
to.
How this query is operated is job of the optimizer, because not
necessarily is the way from a_table to b_table to c_table to value the
fastest - even if the join in this direction is cheap.
currently our syntax for these implicit joins is limited to a special
"id-type". But there is no reason not to implement it in a more general way.
Viele Grüße,
Adrian Veith.
andrewst
Originally posted by Carl Rosenberger
> huge databases. Your "Joins work just fine" statement may not be
> adequate for that scale. In huge databases, you never have enough
> performance.
>
systems. Examples given about Students and Professors led me to believe
we were talking about databases in general.
Originally posted by Carl Rosenberger
> A very simple example:
> Imagine you have a database with 2 billion of hydrogen atoms, joined
> together to one billion of hydrogen molecules. If you have one atom
> and want to find the corresponding one, your index solution will have
> to walk the complete tree consisting of 2 billion of index entries.
> They may not fit into RAM, I am afraid. Alright then, if you have
> a perfectly balanced tree on your hard disk, you will need at least
> 31 (2^ 31 = 2147483648) reads to your disk and 31 compare operations.
>
That assumes each index node has just 2 branches. In Oracle at least, a
figure of a few hundred branches per node is more likely, so the level
will be more like 4 than 31. Granted that's still more than 0 reads.
Originally posted by Carl Rosenberger
> Joins do not have a viewpoint on the data so the optimzer has
> to guess,
> where to start and what to do next.
>
A join on an indexed, selective column will cause the optimizer no
grief.
Originally posted by Carl Rosenberger
The work can be hidden inside views. By "all data contained in a class
9 object" do you mean 1 instance of the object, or all objects of that
class? It's not clear to me from the above.
Originally posted by Carl Rosenberger
> > It's the object "data model" that's a cripple.
>
> I wouldn't call it a "cripple" but I fully agree that it's not
> perfect.
>
> It does work quite good for application development.
>
> Type-safety (do you have that in relations ?) and modern IDE tool
> support (anything equivalent to refactor relational models as
> quickly as you can refactor classes with Eclipse?) make development
> very very efficient.
>
> The commonly used object model may not be theoretically correct but
> it proves to get the job done. In modern IT, minimizing development
> time and minimizing development cost are more important than
> theoretically more correct data models. It's all about becoming
> profitable. Fast!
>
> If you question the principle benefits of object-oriented development,
> you may be the one that's having a laugh.
>
You are conflating the "object data model" with "object oriented
programming". I didn't question the benefits of object-oriented
programming, only of object databases.
If as you say, it's all about how soon and cheaply the application is
complete, and if correctness and usability of the data is unimportant,
then you are of course correct. But when the business later asks for
reports that access the data in ways that aren't in your hard-coded
access paths, it will find that it got what it paid for... ;)
Mikito Harakiri
between
> > the data stored on disk and query output. We might think that blocks x
and
> y
> > are collocated, but filer has striping. Also, storing records with the
> same
> > join key value in the same block migh be good for that particular join
> > order, but may adversely affect other queries.
>
> Absolutely. And creating an index means there is redundant information
that
> must be maintained. And adding physical pointers means there are redundant
> structural artifacts to maintain. etc.
Short memory. You explained that once to me already: your idea is
maintaining implicit pointers not collocating matching parent and child
records together. [Physical] clustering is a confusing name for it.
> Perhaps your optimizer is, but I am not convinced this has to be.
Agreed. Optimizer decision to use implicit pointer vs. alternative doesn't
seem to be a big deal. When refered to optimizer complexity, I had enormous
task difficulty in mind: access paths combinatorial explosion, impossibility
of deriving intermediate cardinalies correctly, etc, etc.
> Tell me, what is the physical difference between clustering 25 binary
> relations on a common key vs. storing a 26-ary relation with all non-key
> columns nullable? It seems to me they should have identical cost
estimation
> models.
Agreed. Evaluating cost of access path via pointer dereference is not harder
than evaluating access path via join index.
Terminogy, again. Or, perhaps, you can illustrate why access through
implicit pointer can be called clustering?
> > Finally, clustering is only important for sequential-read devices (aka
> > disks), and would progressively become less relevant as soon as
> > random-access persistent storage (solid state disks, etc) become more
> > common.
>
> It has potential benefits for any block-read device that operates with
> significant latency or at a significantly slower speed than the cpu.
My misunderstanding here, again. Within randomely-accessed storage model
dereferencing [implicit] pointer is one operation, why navigating tree from
the root to the leaf are several.
Carl Rosenberger
> > Imagine you have a database with 2 billion of hydrogen atoms, joined
> > together to one billion of hydrogen molecules. If you have one atom
> > and want to find the corresponding one, your index solution will have
> > to walk the complete tree consisting of 2 billion of index entries.
> > They may not fit into RAM, I am afraid. Alright then, if you have
> > a perfectly balanced tree on your hard disk, you will need at least
> > 31 (2 ^ 31 = 2147483648) reads to your disk and 31 compare operations.
> > An object database typically references objects directly. Access time
> > is constant:
> > Walk one pointer!
> > ...no matter if you have 10 atoms, 2 billion, or 42 fantastillions.
> > You can get away with one singel read operation.
> > That's the best performance you can get.
> >
> > In huge databases, index construction and maintenance can also become
> > a performance problem.
>
> Wrong arithmetics. A typical B-tree having 1G nodes will be 4 levels deep. 3
> levels would typically be cached. Therefore, we have 1 random IO, the same
> as in the OODB case where the foreigh key reference is expressed explicitly
> by a pointer.
How many comparison operations will you have on average?
I don't think the "we have 3 levels in the cache" argument will
hold for the type of applications I was originally referring to:
http://www.slac.stanford.edu/slac/media-info/20020412/database.html
How will your response times evolve with your B-tree approach, if
you have more data? It will increase!
Direct pointer access performance is constant, flat, always the same:
FAST!
...no matter how much data you store.
Agreed, my arithmetics on the number of read operations that you
need with a B-Tree approach were wrong.
Some weirdos reading along are trying to be funny:
"Yeah with clustering, we need zero access to the storage medium."
In this case I guess, with good enough clustering a relational
database can work without a storage medium. Gee, I wish I had
such a Zen-database to carry around in the 5th dimension of my
pocket.
For those of you (Adrian) arguing that a relational database can
also implement foreign keys as pointers:
In this case you are violating the no.1 relational principle that
values (the logical representation) should be independant of the
physical representation.
The advantage of using direct pointers in object databases, that
works best for huge databases also works best for limited
ressources and limited storage capacities:
PDAs, mobile phones, embedded devices, JavaCard
An object database that uses direct pointers to allow navigating
through objects will achieve the best performance with the least
ressource consumption. Indices will not be necessary.
Alfredo Novoa
> > > Walk one pointer!
> > > ...no matter if you have 10 atoms, 2 billion, or 42 fantastillions.
> > > You can get away with one singel read operation.
Like with a RDBMS.
> Direct pointer access performance is constant, flat, always the same:
> FAST!
> ...no matter how much data you store.
That is why it is used in some SQL-DBMSs
> For those of you (Adrian) arguing that a relational database can
> also implement foreign keys as pointers:
> In this case you are violating the no.1 relational principle that
> values (the logical representation) should be independant of the
> physical representation.
It does not violate anything. Data independence is what permits you to
implement foreign key constraints as you want.
> The advantage of using direct pointers in object databases, that
> works best for huge databases also works best for limited
> ressources and limited storage capacities:
> PDAs, mobile phones, embedded devices, JavaCard
There are better approaches suitable for RDBMSs, although not yet
implemented in industrial strength DBMSs.
> An object database that uses direct pointers to allow navigating
> through objects will achieve the best performance with the least
> ressource consumption. Indices will not be necessary.
Indexes are not necessary in RDBMSs, in fact we can achieve better
performance with less resource consumption without using indexes.
Regards
Alfredo
Marshall Spight
> performance with less resource consumption without using indexes.
Can you explain what you're referring to? Is this the Required Tech
patent, or something else? I'm interested in learning about alternatives
to indexes.
Marshall
Marshall Spight
> For those of you (Adrian) arguing that a relational database can
> also implement foreign keys as pointers:
> In this case you are violating the no.1 relational principle that
> values (the logical representation) should be independant of the
> physical representation.
You correctly state the principle, but it doesn't support what
you're saying. If the logical representation is independent of
the physical representation, then the psysical representation
is free to work however it likes. That means it's okay for
the implementation to use pointers, even though pointers
are not part of the logical model.
Marshall
Peter Koch Larsen
> Mikito Harakiri wrote:
> > > Imagine you have a database with 2 billion of hydrogen atoms, joined
> > > together to one billion of hydrogen molecules. If you have one atom
> > > and want to find the corresponding one, your index solution will have
> > > to walk the complete tree consisting of 2 billion of index entries.
> > > They may not fit into RAM, I am afraid. Alright then, if you have
> > > a perfectly balanced tree on your hard disk, you will need at least
> > > 31 (2 ^ 31 = 2147483648) reads to your disk and 31 compare operations.
> > > An object database typically references objects directly. Access time
> > > is constant:
> > > Walk one pointer!
> > > ...no matter if you have 10 atoms, 2 billion, or 42 fantastillions.
> > > You can get away with one singel read operation.
> > > That's the best performance you can get.
> > >
> > > In huge databases, index construction and maintenance can also become
> > > a performance problem.
> >
> > Wrong arithmetics. A typical B-tree having 1G nodes will be 4 levels deep. 3
> > levels would typically be cached. Therefore, we have 1 random IO, the same
> > as in the OODB case where the foreigh key reference is expressed explicitly
> > by a pointer.
>
> How many comparison operations will you have on average?
element in some ordered structure - such as a B-tree - you will need
about 31 comparisons.
>
> I don't think the "we have 3 levels in the cache" argument will
> hold for the type of applications I was originally referring to:
> http://www.slac.stanford.edu/slac/media-info/20020412/database.html
>
> How will your response times evolve with your B-tree approach, if
> you have more data? It will increase!
>
> Direct pointer access performance is constant, flat, always the same:
> FAST!
Quite fast. You do need one access to read the data.
> ...no matter how much data you store.
>
> Agreed, my arithmetics on the number of read operations that you
> need with a B-Tree approach were wrong.
Yes - your arithmetic is not quite up to date either ;-)
>
> Some weirdos reading along are trying to be funny:
> "Yeah with clustering, we need zero access to the storage medium."
> In this case I guess, with good enough clustering a relational
> database can work without a storage medium. Gee, I wish I had
> such a Zen-database to carry around in the 5th dimension of my
> pocket.
What the weirdos tried to tell you is that by clustering data you
store the oxygen atoms together with its corresponding hydrogen atom.
This means that when you read the record corresponding to a specific
hydrogen atom, the two oxygen atoms that relate to that hydrogen atom
will typically be on the same page. And if they are not on the same
page, they will be on the next page.
>
>
> For those of you (Adrian) arguing that a relational database can
> also implement foreign keys as pointers:
> In this case you are violating the no.1 relational principle that
> values (the logical representation) should be independant of the
> physical representation.
Here you are once again confused. The relational model is a logical
model, not a physical one. Thus the DBMS-implementors are free to
choose whatever representation they like. This includes clustering and
pointer-operations.
>
>
> The advantage of using direct pointers in object databases, that
> works best for huge databases also works best for limited
> ressources and limited storage capacities:
> PDAs, mobile phones, embedded devices, JavaCard
>
> An object database that uses direct pointers to allow navigating
> through objects will achieve the best performance with the least
> ressource consumption. Indices will not be necessary.
If there is no "index", how are you going to find a specific hydrogen
atom?
>
>
> Kind regards,
> Carl
Kind regards
Peter
Alfredo Novoa
> "Alfredo Novoa" <alf...@ncs.es> wrote in message news:e4330f45.03051...@posting.google.com...
> >
> > Indexes are not necessary in RDBMSs, in fact we can achieve better
> > performance with less resource consumption without using indexes.
>
> Can you explain what you're referring to? Is this the Required Tech
> patent, or something else?
Yes it is. It is an impressive advance in storage technology. Although
I am not very aware about the US software patent implications. I think
I can use it at my own discretion if I don't sell my products in US,
Japan, Jordan and perhaps now Irak }:), but I don't know what is the
exact country list. Is Canada in the list?
I think software patents are evil. I hope Europe will continue staying
away of them.
Does anyone know what are the procedures if you want to use a patented
algorithm in the US?
> I'm interested in learning about alternatives
> to indexes.
It worths a while.
Regards
Alfredo
Bob
> BTW, Intersystems Caché is a product which has both an SQL and an object
> interface, and both interfaces are reported to be very fast.
Caché isn't the only one. Check Mattisse. This one also has both SQL and
object interface.
These two are somewhat different from other object databases.
Bob
Alfredo Novoa
Hi Paul,
Sorry for the delay. I have not seen your response until now.
> heard that it's packed with useful information. I've also heard that the
> model has a couple major flaws that form the reasons that it hasn't been
> implemented.
>
> The biggest flaw is the fact that "pointers" are still not allowed.
It is hardly a flaw, because Date and Darwen have shown that pointer
based type inheritance is flawed.
> Everything is still done by query.
I don't understand this.
> Date's model provides a good method to model inheritance where the subtypes
> are more restrictive
It is just common sense.
> most common example is having circles inherit from ellipse, where a circle
> is a special case of ellipse where the x and y coordinates are the same.
>
> Date's model does not provide the means to efficiently define a subclass of
> ellipse like "filled ellipse" that would have an extra member like
> "fillcolor".
And it is an strong point of the model, because "filled ellipse" is
not a subtype of ellipse. They are disjoint types. You can not fill an
ellipse, you can fill an elliptical shape.
"Filled elliptical shape" inherits from ellipse is like "thick colored
drawed point" inherits from "mathematical point"
But with Date & Darwen's model "filled elliptical shape" may be a
subtype of "elliptical shape"
>Although improper inheritance isn't as improper as some would
> claim, the other use of inheritance is the more useful form.
It is funny that OOpists call improper inheritance to the only way of
proper subtyping.
> XML is a great example, where you have 12 different types of nodes.
XML is a great nonsense.
http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2896005,00.html
> Having
> to model each of those as completely independent types with no relationship
> to "node" simply doesn't work well in a relational database. This is why
> Oracle is now providing a completely separate way of storing XML independent
> of their tables and making a big deal about it.
They are reinventing poor man hierarchical DBMSes.
> If you normalize, you end up with more joins and joins ARE horribly
> expensive.
With a good implementation joins are free. The technology which allows
this is just emerging.
> This is where the model fails.
This is where implementation failed in the past. Models are
independent to performance issues.
> The only way Date suggests to
> make the joins less expensive is to use physical clustering (Bob's "no-op"),
> which ends up violating the "physical independence" even more than using
> pointers does.
It seems you don't understand the concept of data independence.
Thanks to data independence we can do all we want at the physical
level and the logical model will not be afected.
Regards
Alfredo
Jim Melton
> "Paul DeWolf" <pa...@thievesandkings.com> wrote in message
news:<9FSva.302325$Si4.2...@rwcrnsc51.ops.asp.att.net>...
> > expensive.
>
> With a good implementation joins are free. The technology which allows
> this is just emerging.
>
> > This is where the model fails.
>
> This is where implementation failed in the past. Models are
> independent to performance issues.
I'd like to suggest that this is the crux of much of the wasted time on this
newsgroup. Relational purists point the the mathematical foundation of the
relational MODEL and claim that it is the best way to manage data. OO
practitioners point to the problems of relational IMPLEMENTATIONS and claim
that object databases are better.
Both may be right.
To claim that current databases fail to implement the promise of the
relational model (while it may be true) is a red herring for those of us
concerned with fielding software. The state of the art is all we have to
work with. You can criticize the lack of mathematical foundation behind my
implementation all you want, but if I satisfy my customer's requirements,
that is the bottom line.
More precisely, there are applications where the current state of the art in
relational technology is not sufficiently performant, and where an object
database can provide the required performance. You can criticize the lack of
location transparency and the application-centric data organization, but
these defects are acceptable in some cases to achieve the required
performance.
There is a difference between theory and practice. This newsgroup is
concerned with practice.
--
<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 Astronautics
(303) 971-3846
Paul DeWolf
> "Paul DeWolf" <pa...@thievesandkings.com> wrote in message
news:<9FSva.302325$Si4.2...@rwcrnsc51.ops.asp.att.net>...
>
> Hi Paul,
>
> Sorry for the delay. I have not seen your response until now.
>
> > heard that it's packed with useful information. I've also heard that
the
> > model has a couple major flaws that form the reasons that it hasn't been
> > implemented.
> >
> > The biggest flaw is the fact that "pointers" are still not allowed.
>
> It is hardly a flaw, because Date and Darwen have shown that pointer
> based type inheritance is flawed.
Our pointer based type inheritance works great.
> > Everything is still done by query.
>
> I don't understand this.
Query may not be the correct word. Everything is still done by looking up
tuples by attribute.
> > Date's model provides a good method to model inheritance where the
subtypes
> > are more restrictive
>
> It is just common sense.
I'm glad you like it.
> > most common example is having circles inherit from ellipse, where a
circle
> > is a special case of ellipse where the x and y coordinates are the same.
> >
> > Date's model does not provide the means to efficiently define a subclass
of
> > ellipse like "filled ellipse" that would have an extra member like
> > "fillcolor".
>
> And it is an strong point of the model, because "filled ellipse" is
> not a subtype of ellipse. They are disjoint types. You can not fill an
> ellipse, you can fill an elliptical shape.
>
> "Filled elliptical shape" inherits from ellipse is like "thick colored
> drawed point" inherits from "mathematical point"
>
> But with Date & Darwen's model "filled elliptical shape" may be a
> subtype of "elliptical shape"
I'm amused by the suggestion that an ellipse is different from an elliptical
shape. Maybe from some mathematical point of view that my years of calculus
didn't cover there's a subtle difference, but from the point of view of most
software applications, I'd say they're pretty much the same.
Regardless, using inheritance to add attributes and functionality to a base
class is a very important ability in object-oriented programming and should
be supported by the database without sacrificing performance or screwing up
the object model.
Our database supports this and it works great, even if Date and Darwen say
it's not supposed to.
> >Although improper inheritance isn't as improper as some would
> > claim, the other use of inheritance is the more useful form.
> It is funny that OOpists call improper inheritance to the only way of
> proper subtyping.
Perhaps Date and Darwen should write a manifesto to change the C++,
Smalltalk, C# and Java standards to enforce their view of "proper
subtyping".
Whether a subtyping strategy is "proper" or "improper" really depends on how
well it works in the application. The database shouldn't dictate what a
software developer can do any more than it absolutely has to.
> > XML is a great example, where you have 12 different types of nodes.
>
> XML is a great nonsense.
>
>
http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2896005,00.html
You're missing the point. There are lots of data models that need to use
more than 4-5 different classes to derive from the same class. XML is one.
Whether you or the author of that article like what people are doing with
XML is the subject for a different newsgroup. My point was that Oracle's
limitation of 4-5 tables for physical clustering is a serious and
unnecessary one.
> > Having
> > to model each of those as completely independent types with no
relationship
> > to "node" simply doesn't work well in a relational database. This is
why
> > Oracle is now providing a completely separate way of storing XML
independent
> > of their tables and making a big deal about it.
>
> They are reinventing poor man hierarchical DBMSes.
I agree with you there.
> > If you normalize, you end up with more joins and joins ARE horribly
> > expensive.
>
> With a good implementation joins are free. The technology which allows
> this is just emerging.
Right on the heels of the perpetual motion machine.
> > This is where the model fails.
>
> This is where implementation failed in the past. Models are
> independent to performance issues.
That's what's nice about unimplemented models. They're independent of many
issues. I'm all for anyone building a better mousetrap, but so far we've
got a book about how mousetraps should be built based on theory that's been
around for years and years and yet no one has built it.
The fans of the manifesto seem to want everyone to stop actually building
anything and join the cult of slamming all existing tools. For the people
that are actually trying to solve their persistence problems, this isn't
helpful.
Maybe you or someone will create the ideal database and I can make a living
porting data and applications to it. Until then, I'm going to keep working
with my company and its database because it's a really, really good one and
solves problems for people today.
> > The only way Date suggests to
> > make the joins less expensive is to use physical clustering (Bob's
"no-op"),
> > which ends up violating the "physical independence" even more than using
> > pointers does.
>
> It seems you don't understand the concept of data independence.
>
> Thanks to data independence we can do all we want at the physical
> level and the logical model will not be afected.
I do understand the concept of data independence. For one thing, "data
independence" is the ability to access the same data from different
applications. This is different from "physical data independence", which is
the ability to physically move data without affecting the logical interface.
You're talking about the latter, but calling it the former.
Physical data independence is a good thing, but it doesn't make joining
related objects free. I'm still waiting to hear how "properly implemented"
databases can have free joins. I've only heard that one can use physical
clustering. To the extent that will help, it screws up the physical
independence story.
The only way I know to have physical independence and fast joins is to have
a logical to physical lookup somewhere - i.e. a pointer. If you or someone
else can reconcile how to have free joins and physical data independence
without pointers, that will be a useful posting.
andrewst
Originally posted by Paul Dewolf
> is to have
> a logical to physical lookup somewhere - i.e. a pointer. If you
> or someone
> else can reconcile how to have free joins and physical data
> independence
> without pointers, that will be a useful posting.
>
the covers. It is exposing pointers to users that is the issue. If the
DBMS implemented foreign keys by creating pointers somehow hidden away
inside the database, that would provide your "free" joins, would it not?
Alfredo Novoa
> > With a good implementation joins are free. The technology which allows
> > this is just emerging.
> >
> > > This is where the model fails.
> >
> > This is where implementation failed in the past. Models are
> > independent to performance issues.
>
> I'd like to suggest that this is the crux of much of the wasted time on this
> newsgroup. Relational purists point the the mathematical foundation of the
> relational MODEL and claim that it is the best way to manage data. OO
> practitioners point to the problems of relational IMPLEMENTATIONS and claim
> that object databases are better.
It is simply false. OO practicioners are always questioning The
Relational Model, although it is probably true that some of them does
not know the difference between model and implementation.
But even the actual crappy pseudo-relational implementations have
proven that they are better than OODBMSes almost always.
The problems of relational implementations can be solved with better
implementations. OODBMSes were a wrong path, and they are vanishing.
> Both may be right.
But then the OO practicioners are using the language in an
incompletent way.
> To claim that current databases fail to implement the promise of the
> relational model (while it may be true) is a red herring for those of us
> concerned with fielding software.
Why?
> The state of the art is all we have to
> work with.
The state of the art is light years beyond the old pseudo-relational
implementations we have to use.
It is very probable that the things will change a lot in few years, it
is only an investiment problem.
> You can criticize the lack of mathematical foundation behind my
> implementation all you want, but if I satisfy my customer's requirements,
> that is the bottom line.
It is not enough, you must minimize the developement and maintenance
costs.
> More precisely, there are applications where the current state of the art in
> relational technology is not sufficiently performant
It seems you are not aware about the very last advances in relational
technology.
Regards
Alfredo
Alfredo Novoa
> > It is hardly a flaw, because Date and Darwen have shown that pointer
> > based type inheritance is flawed.
>
> Our pointer based type inheritance works great.
Even with circles and ellipses?
> > > Everything is still done by query.
> >
> > I don't understand this.
>
> Query may not be the correct word. Everything is still done by looking up
> tuples by attribute.
But The Third Manifesto's inheritance model does not have any relation
with queries.
> I'm amused by the suggestion that an ellipse is different from an elliptical
> shape.
I am amused by you can not see the difference.
An ellipse is an abstract mathematical concept, and an elliptical
shape is a drawing.
For instance this is a circle representation: X = 5, Y = 5, R = 10
Try to fill it ;-)
> Maybe from some mathematical point of view that my years of calculus
> didn't cover there's a subtle difference, but from the point of view of most
> software applications, I'd say they're pretty much the same.
They are very different. An ellipse does not have: line thick, line
color, line pattern, etc properties.
> Regardless, using inheritance to add attributes and functionality to a base
> class is a very important ability in object-oriented programming
Prove it.
It is only important because it is the only way with current OO
languages.
By the way you can add all the functionality you want to subtypes with
the Date and Darwen's model.
And also you can add new components to a base class when you want.
For instance if you have an apple class and you want to derive a "red
apple" subtype, then you can add a color component to the apple type
and now you can declare the "red apple" subtype using a constraint.
> Our database supports this and it works great, even if Date and Darwen say
> it's not supposed to.
With Date's model it would work greater :-)
> > >Although improper inheritance isn't as improper as some would
> > > claim, the other use of inheritance is the more useful form.
>
> > It is funny that OOpists call improper inheritance to the only way of
> > proper subtyping.
> Perhaps Date and Darwen should write a manifesto to change the C++,
> Smalltalk, C# and Java standards to enforce their view of "proper
> subtyping".
They did that. We are talking about it.
> You're missing the point. There are lots of data models that need to use
> more than 4-5 different classes to derive from the same class. XML is one.
XML is not a data model nor a model.
All about XML is a mess.
And you can derive all the classes you want with The Third Manifesto's
model.
> My point was that Oracle's
> limitation of 4-5 tables for physical clustering is a serious and
> unnecessary one.
Agreed, but it does not have any relation with The Third Manifesto
inheritance model.
> > > If you normalize, you end up with more joins and joins ARE horribly
> > > expensive.
> >
> > With a good implementation joins are free. The technology which allows
> > this is just emerging.
>
> Right on the heels of the perpetual motion machine.
No, it is a technology patented on december 1999. It is still very
young, and it is beeing retarded by legal issues.
It is probably the most important advance in the database camp since
the invention of The Relational Model.
> > > This is where the model fails.
> >
> > This is where implementation failed in the past. Models are
> > independent to performance issues.
>
> That's what's nice about unimplemented models. They're independent of many
> issues. I'm all for anyone building a better mousetrap, but so far we've
> got a book about how mousetraps should be built based on theory that's been
> around for years and years and yet no one has built it.
But this will change in a short time.
> The fans of the manifesto seem to want everyone to stop actually building
> anything and join the cult of slamming all existing tools. For the people
> that are actually trying to solve their persistence problems, this isn't
> helpful.
It is useful because it is never too late for abandoning a wrong path.
> Maybe you or someone will create the ideal database and I can make a living
> porting data and applications to it. Until then, I'm going to keep working
> with my company and its database because it's a really, really good one and
> solves problems for people today.
This can be a reasonible option, but you should know that OODBMSes
does not have future.
> > It seems you don't understand the concept of data independence.
> >
> > Thanks to data independence we can do all we want at the physical
> > level and the logical model will not be afected.
>
> I do understand the concept of data independence. For one thing, "data
> independence" is the ability to access the same data from different
> applications.
It is not data independence.
> This is different from "physical data independence", which is
> the ability to physically move data without affecting the logical interface.
> You're talking about the latter, but calling it the former.
There are two kinds of data independence: logical and physical. When
we say data independence we are probably talking about physical data
independence.
Logical data independence is the ability to change some aspects of the
logical model without afecting the applications.
Disk clustering is clearly a physical issue. It does not have any
relation with the logical model.
> Physical data independence is a good thing, but it doesn't make joining
> related objects free.
But it can do that.
> I'm still waiting to hear how "properly implemented"
> databases can have free joins.
Look for The TransRelational Model and Required Technologies.
> I've only heard that one can use physical
> clustering. To the extent that will help, it screws up the physical
> independence story.
How?
I don't understand how you can say that.
If you store the data of two relations near in the disk in order to
have a good join performance it does not screw anything.
> The only way I know to have physical independence and fast joins is to have
> a logical to physical lookup somewhere - i.e. a pointer. If you or someone
> else can reconcile how to have free joins and physical data independence
> without pointers, that will be a useful posting.
The new technology makes an intensive use of pointers.
The Relational Model does not have any problem with pointers at the
physical level. They are very common even in actual pseudo-relational
implementations.
Regards
Alfredo
Bob Badour
> "Paul DeWolf" <pa...@thievesandkings.com> wrote in message
news:<VjWDa.587989$Si4.5...@rwcrnsc51.ops.asp.att.net>...
>
> > > It is hardly a flaw, because Date and Darwen have shown that pointer
> > > based type inheritance is flawed.
> >
> > Our pointer based type inheritance works great.
>
> Even with circles and ellipses?
>
> > > > Everything is still done by query.
> > >
> > > I don't understand this.
> >
> > Query may not be the correct word. Everything is still done by looking
up
> > tuples by attribute.
>
> But The Third Manifesto's inheritance model does not have any relation
> with queries.
>
> > I'm amused by the suggestion that an ellipse is different from an
elliptical
> > shape.
>
> I am amused by you can not see the difference.
>
> An ellipse is an abstract mathematical concept, and an elliptical
> shape is a drawing.
>
> For instance this is a circle representation: X = 5, Y = 5, R = 10
>
> Try to fill it ;-)
Be careful what you ask for: X = 5, Y = 5, R <= 10
> > Maybe from some mathematical point of view that my years of calculus
> > didn't cover there's a subtle difference, but from the point of view of
most
> > software applications, I'd say they're pretty much the same.
>
> They are very different. An ellipse does not have: line thick, line
> color, line pattern, etc properties.
It also has no handles, no artifacting etc. The fact that--using his
preferred model--Paul has no idea when to use inheritance vs. composition
already proves his model's inferiority.
> > Regardless, using inheritance to add attributes and functionality to a
base
> > class is a very important ability in object-oriented programming
>
> Prove it.
He is correct. For instance, a circle has a center while an ellipse does
not. Basically, a subtype is a subset of the values and a superset of the
operations of a supertype. This is perfectly compatible with Date's and
Darwen's model in TTM.
Note however that the added attributes are not arbitrary but are intrinsic
to the subtype. Combining a geometric shape value, a line-style value, a
fill-style value, a pen value and a brush value using composition creates a
new type that is neither a subtype nor a supertype of shapes, line-styles,
fill-styles, pens or brushes.
> > Our database supports this and it works great, even if Date and Darwen
say
> > it's not supposed to.
>
> With Date's model it would work greater :-)
I agree.
> > My point was that Oracle's
> > limitation of 4-5 tables for physical clustering is a serious and
> > unnecessary one.
>
> Agreed, but it does not have any relation with The Third Manifesto
> inheritance model.
At least use the correct figures. Oracle is limited to 32 tables for
clustering, which is still too small, but is much greater than 4 or 5
tables. Paul's product will suffer the exact same degradation that Oracle
warns against if it tries to cluster 6 or 7 large entities.
> > > > If you normalize, you end up with more joins and joins ARE horribly
> > > > expensive.
> > >
> > > With a good implementation joins are free. The technology which allows
> > > this is just emerging.
> >
> > Right on the heels of the perpetual motion machine.
>
> No, it is a technology patented on december 1999. It is still very
> young, and it is beeing retarded by legal issues.
>
> It is probably the most important advance in the database camp since
> the invention of The Relational Model.
Be careful with hyperbole. I am currently reading the patent and it is
nowhere near as important as RM.
> > Physical data independence is a good thing, but it doesn't make joining
> > related objects free.
>
> But it can do that.
Of course. Paul is simply too ignorant and too lazy to understand what you
are saying.
> > I've only heard that one can use physical
> > clustering. To the extent that will help, it screws up the physical
> > independence story.
>
> How?
>
> I don't understand how you can say that.
Because he is ignorant and lazy. Him saying it does not make it true.
> > The only way I know to have physical independence and fast joins is to
have
> > a logical to physical lookup somewhere - i.e. a pointer. If you or
someone
> > else can reconcile how to have free joins and physical data independence
> > without pointers, that will be a useful posting.
>
> The new technology makes an intensive use of pointers.
>
> The Relational Model does not have any problem with pointers at the
> physical level. They are very common even in actual pseudo-relational
> implementations.
I would like to know how anyone plans to create a B+tree without pointers.
Some people, Paul included, cannot see the obvious.
Paul DeWolf
> "Paul DeWolf" <pa...@thievesandkings.com> wrote in message
news:<VjWDa.587989$Si4.5...@rwcrnsc51.ops.asp.att.net>...
> > Regardless, using inheritance to add attributes and functionality to a
base
> > class is a very important ability in object-oriented programming
>
> Prove it.
>
> It is only important because it is the only way with current OO
> languages.
Current OO languages provide more and better inheritance functionality than
the Date and Darwen manifesto proposes, not less.
> By the way you can add all the functionality you want to subtypes with
> the Date and Darwen's model.
>
> And also you can add new components to a base class when you want.
>
> For instance if you have an apple class and you want to derive a "red
> apple" subtype, then you can add a color component to the apple type
> and now you can declare the "red apple" subtype using a constraint.
This is what I mean. You shouldn't have to add the attribute to the base
class. You should be able to extend the class, not be forced to expand and
then constrain it. Making an overweight base class and then constraining
its subclasses is not the best way to use inheritance.
> > The fans of the manifesto seem to want everyone to stop actually
building
> > anything and join the cult of slamming all existing tools. For the
people
> > that are actually trying to solve their persistence problems, this isn't
> > helpful.
>
> It is useful because it is never too late for abandoning a wrong path.
In favor of no path at all? You're not offering solutions, just theory.
OODBMSs exist now and have been proven to be better (faster, more scalable,
more embeddable, more distributable) than the current RDBMS products for
many applications.
> > Maybe you or someone will create the ideal database and I can make a
living
> > porting data and applications to it. Until then, I'm going to keep
working
> > with my company and its database because it's a really, really good one
and
> > solves problems for people today.
>
> This can be a reasonible option, but you should know that OODBMSes
> does not have future.
Sorry, but I'm not going to take your word for that when you hardly know
anything about our product or our company.
You're sounding like the guy who claimed that aerodynamically bumblebees
can't fly, except that you're actually going on to the bumblebee newsgroup
and trying to convince the bumblebees.
> > I've only heard that one can use physical
> > clustering. To the extent that will help, it screws up the physical
> > independence story.
>
> How?
>
> I don't understand how you can say that.
>
> If you store the data of two relations near in the disk in order to
> have a good join performance it does not screw anything.
What makes joins slow is the logical reconnecting of related objects that
are loosely coupled by examining foreign key attributes as opposed to having
an array of logical pointers to unique IDs. This is particularly true with
many-to-many relationships.
I understand that Date and Darwen improve on existing relational
implementations by allowing arrays within tables, which could be used as
keys to those unique IDs. That can provide a large improvement in
scalability and performance. In that way (and probably others) our database
is closer to the Date and Darwen manifesto than existing relational
databases are.
Still, putting objects closer together on the disk doesn't help the logical
joining unless the search engine does its search in order of physical
proximity. This presents problems when an object is related to more than
one other object.
If objects are all inter-related, there is no clustering method that will
make those logical joins significantly faster, much less free.
Whether you can get "free joins" depends on the data, not just how the
database is implemented or administered. Date and Darwen didn't invent
physically independent data clustering, nor have they made it a panacea.
Paul
Paul DeWolf
> "Alfredo Novoa" <alf...@ncs.es> wrote in message
> news:e4330f45.0306...@posting.google.com...
> > "Paul DeWolf" <pa...@thievesandkings.com> wrote in message
> news:<VjWDa.587989$Si4.5...@rwcrnsc51.ops.asp.att.net>...
>
> clustering, which is still too small, but is much greater than 4 or 5
> tables. Paul's product will suffer the exact same degradation that Oracle
> warns against if it tries to cluster 6 or 7 large entities.
Oracle's documentation states that their clustering becomes ineffective past
4 or 5 tables.
Our product can cluster objects that can be of thousands if not millions of
different types without significant degradation. Unlike Oracle, our
clustering is completely independent of type.
Alfredo Novoa
Bob,
> > For instance this is a circle representation: X = 5, Y = 5, R = 10
> >
> > Try to fill it ;-)
>
> Be careful what you ask for: X = 5, Y = 5, R <= 10
I don't think it is a filled circle in the sense we were talking
about.
> > > Regardless, using inheritance to add attributes and functionality to a
> base
> > > class is a very important ability in object-oriented programming
> >
> > Prove it.
>
> He is correct. For instance, a circle has a center while an ellipse does
> not. Basically, a subtype is a subset of the values and a superset of the
> operations of a supertype. This is perfectly compatible with Date's and
> Darwen's model in TTM.
>
> Note however that the added attributes are not arbitrary but are intrinsic
> to the subtype.
Well, but he was talking about adding any arbitrary property.
> > It is probably the most important advance in the database camp
since
> > the invention of The Relational Model.
>
> Be careful with hyperbole. I am currently reading the patent and it is
> nowhere near as important as RM.
Of course it is not near as important as TRM, but I can not find a
more important advance AFTER TRM and its refinements.
Regards
Alfredo
Alfredo Novoa
> Current OO languages provide more and better inheritance functionality than
> the Date and Darwen manifesto proposes, not less.
You have not provided any argument.
> This is what I mean. You shouldn't have to add the attribute to the base
> class. You should be able to extend the class, not be forced to expand
Adding a new component is not expanding a type. You can expand a type
relaxing its constraint.
> then constrain it. Making an overweight base class and then constraining
> its subclasses is not the best way to use inheritance.
There is not any overweight, all apples have color, and the model is
flaw free.
> In favor of no path at all? You're not offering solutions, just theory.
> OODBMSs exist now and have been proven to be better (faster, more scalable,
> more embeddable, more distributable) than the current RDBMS products for
> many applications.
???
And that is why they have a tiny part of the market share and
decreasing.
With better relational implementations the OODBMS little niches will
be even more reduced.
> > This can be a reasonible option, but you should know that OODBMSes
> > does not have future.
>
> Sorry, but I'm not going to take your word for that when you hardly know
> anything about our product or our company.
If your product is an OODBMS then I know enough.
> I understand that Date and Darwen improve on existing relational
> implementations by allowing arrays within tables, which could be used as
> keys to those unique IDs.
It seems you have not understood anything. Your statement does not
have any sense.
> That can provide a large improvement in
> scalability and performance. In that way (and probably others) our database
> is closer to the Date and Darwen manifesto than existing relational
> databases are.
If you expose pointers to users you are light years far.
> If objects are all inter-related, there is no clustering method that will
> make those logical joins significantly faster, much less free.
You can store the joins, you can use a big RAM, etc.
Alfredo
Neo
This has been my personal experience also. Implementing generic
modelling (ie all data in a few tables) to allow complex/variable
relationships in rdb is impractical due to performance degradation.
Neo
> > up by its OID), it doesn't have to know anything about where those
> > objects are stored.
>
> Except that OID is nothing more than a location even if it specifies a
> location that stores a location. Your statement is a contradiction.
An OID is not a location, just as an ID in a table is not a location.
Each is independent of the actual physical memory location. Each is
translated to physical memory location upon access to related
object/tuple.
Neo
> whether to force users to deal with physical issues directly or whether to
> separate the physical access concern from the expressibility concern.
XDb's implementation allows things (similar to a tuple) to be located
via its creator's (things similar to relation and attributes) names
thus providing the logical independence. However once the desired
thing is found, related things can be located via pointers providing
extreme performance. If the user feels "forced" he can find the same
remaining related things via their creator's names also, albeit with
lower performance.
Neo
> logic and of set algebra to the problem of data management.
Not quite direct(100%), if it was there would be perfect closure with
the fundamental operations of intersection, union, and negation. Such
only occurs in rdm under special cases with relations where the number
and type of attributes involved are compatible.
> All network model and hierarchic model database
> management systems, including OID-based object databases, rely on physical
> location while the relational model prohibits such reliance.
All data models eventually must execute on physical location including
the rdm. Any data model can abstract those locations thus providing
logical independence. The hierarchal and network models are limited
because they don't allow the degree of normalization that rdm does,
not because they can't provide logical independence.
Alfredo Novoa
Bob,
> > Be careful with hyperbole. I am currently reading the patent and it is
> > nowhere near as important as RM.
>
> Of course it is not near as important as TRM, but I can not find a
> more important advance AFTER TRM and its refinements.
It seems that Date agree with me about this:
"The TransRelationaltm Model. In this writer's opinion, the
TransRelational model is likely to prove the most significant advance
in this field since Codd gave us the relational model, nearly 35 years
ago.
"
http://www.pgro.uk7.net/cjd3s_2.htm
Regards
Alfredo
Jim Melton
> "Jim Melton" <jim.m...@lmco.com> wrote in message
news:<bbokn6$14...@cui1.lmms.lmco.com>...
>
> > > With a good implementation joins are free. The technology which allows
> > > this is just emerging.
> > >
> > > > This is where the model fails.
> > >
> > > This is where implementation failed in the past. Models are
> > > independent to performance issues.
> >
> > I'd like to suggest that this is the crux of much of the wasted time on
this
> > newsgroup. Relational purists point the the mathematical foundation of
the
> > relational MODEL and claim that it is the best way to manage data. OO
> > practitioners point to the problems of relational IMPLEMENTATIONS and
claim
> > that object databases are better.
>
> It is simply false. OO practicioners are always questioning The
> Relational Model, although it is probably true that some of them does
> not know the difference between model and implementation.
I think this distinction is not clearly drawn in the discussions and people
often read what they expect to see. I doubt very much that OO practitioners
question the Relational Model (except as the Holy Grail of data management).
Rather, they question relational databases.
> But even the actual crappy pseudo-relational implementations have
> proven that they are better than OODBMSes almost always.
Despite your slip into unsubstantiated hyperbole, the "almost always" part
of the above is telling. If there is ANY class of applications for which an
object database is superior, then the technology has merit and the
Relational Bigots should stop trying to bury that value under misleading
attacks of "you have no mathematical model".
In my experience, for the class of applications that I develop, ODBMS are
superior to RDBMS.
> The problems of relational implementations can be solved with better
> implementations. OODBMSes were a wrong path, and they are vanishing.
And you are falling back into the theory vs. practice trap. Your first
sentence may be right, but I haven't seen it. Your second sentence is an
opinion with which I do not agree.
> > Both may be right.
>
> But then the OO practicioners are using the language in an
> incompletent way.
It's not limited to one side. When an OO-er says "my database does X" and a
relational theorist responds with "but relational theory says Y", there is
miscommunication on both sides.
> > To claim that current databases fail to implement the promise of the
> > relational model (while it may be true) is a red herring for those of us
> > concerned with fielding software.
>
> Why?
Because of the next sentence.
> > The state of the art is all we have to
> > work with.
>
> The state of the art is light years beyond the old pseudo-relational
> implementations we have to use.
This is a non-sequitur. The implementations we have to use ARE the state of
the art (for non-database engine developers).
> It is very probable that the things will change a lot in few years, it
> is only an investiment problem.
>
> > You can criticize the lack of mathematical foundation behind my
> > implementation all you want, but if I satisfy my customer's
requirements,
> > that is the bottom line.
>
> It is not enough, you must minimize the developement and maintenance
> costs.
You have no basis on which to judge whether my costs are higher or lower
than if I were using a relational database. Since my customer's requirements
include cost, if he is satisfied, that IS the bottom line.
> > More precisely, there are applications where the current state of the
art in
> > relational technology is not sufficiently performant
>
> It seems you are not aware about the very last advances in relational
> technology.
And either these advances are more theory, you are similarly uninformed, or
you thought it would otherwise be helpful not to expound in any detail on
these advances.
Alfredo Novoa
> I think this distinction is not clearly drawn in the discussions and people
> often read what they expect to see. I doubt very much that OO practitioners
> question the Relational Model (except as the Holy Grail of data management).
> Rather, they question relational databases.
I don't agree, I have readen hundreds of critiques to the Relational
Model made by OO practicioners.
I am tired of nonsenses like this: "Using tables to store objects is
like driving your car home and then disassembling it to put it in the
garage."
And of course it is not the Holy Grail, it is only the foundation of
modern data management.
> Despite your slip into unsubstantiated hyperbole, the "almost always" part
Compare their market shares. Everybody says that OODBMSes are a niche
technology and SQL DBMSes sales grow faster.
OODBMSes agonize in niches which are not very interesting for SQL DBMS
vendors.
> of the above is telling. If there is ANY class of applications for which an
> object database is superior, then the technology has merit and the
Yes, the technology may have lots of merits. It is the "model" what is
primitive, and you can not go very far with a primitive model.
With a good relational technology like the TransRelational Model and a
good implementation of The Third Manifesto we can be pretty sure that
there is not any application for which an object database is superior.
OODBMSes are a dead end, and RDBMSs are now starting a revolution in
the implementation side.
> Relational Bigots should stop trying to bury that value under misleading
> attacks of "you have no mathematical model".
I don't think we are questioning the implementations. A perfect
implementation of a bubble sort can not compete with a crappy
quicksort implementation in most cases.
> In my experience, for the class of applications that I develop, ODBMS are
> superior to RDBMS.
Why?
If you change RDBMS by SQL DBMS I could agree.
> > The problems of relational implementations can be solved with better
> > implementations. OODBMSes were a wrong path, and they are vanishing.
>
> And you are falling back into the theory vs. practice trap. Your first
> sentence may be right, but I haven't seen it.
See the TransRelational Model.
> Your second sentence is an
> opinion with which I do not agree.
But most people does.
http://www.leavcom.com/db_08_00.htm
> > The state of the art is light years beyond the old pseudo-relational
> > implementations we have to use.
>
> This is a non-sequitur. The implementations we have to use ARE the state of
> the art (for non-database engine developers).
What you call the state of the art is the state of the market. The
state of the art is what the database engine developers and designers
know and what they are developing now.
> > It is not enough, you must minimize the developement and maintenance
> > costs.
>
> You have no basis on which to judge whether my costs are higher or lower
> than if I were using a relational database.
I don't know your project, but we have strong theoretical basis. The
problem is that there are not relational DBMSes avaiable on the
market.
Perhaps you are using the best DBMS avaiable for your project, I am
not questioning that. My point is that if good DBMS developers had
developed a truly RDBMS for your niche it would be a lot superior to
any OODBMS.
> Since my customer's requirements
> include cost, if he is satisfied, that IS the bottom line.
There is a difference between satisfied and very satisfied :-)
And of course the benefit of your employer is also important.
> > > More precisely, there are applications where the current state of the
> art in
> > > relational technology is not sufficiently performant
> >
> > It seems you are not aware about the very last advances in relational
> > technology.
>
> And either these advances are more theory, you are similarly uninformed, or
> you thought it would otherwise be helpful not to expound in any detail on
> these advances.
Google for "value instance connectivity" (quotes included).
The idea is incredibly simple and it is no more a secret.
Regards
Alfredo
Bob Badour
I saw that, and I suspect it is hyperbole too. I still have not finished
reading the entire patent so perhaps I will have a change of heart but I
remain a skeptic at this point.
Paul DeWolf
> "Jim Melton" <jim.m...@lmco.com> wrote in message
news:<bc2i19$qi...@cui1.lmms.lmco.com>...
>
> > I think this distinction is not clearly drawn in the discussions and
people
> > often read what they expect to see. I doubt very much that OO
practitioners
> > question the Relational Model (except as the Holy Grail of data
management).
> > Rather, they question relational databases.
>
> I don't agree, I have readen hundreds of critiques to the Relational
> Model made by OO practicioners.
I'm sure they're predominantly references to relational implementations, not
the model.
> I am tired of nonsenses like this: "Using tables to store objects is
> like driving your car home and then disassembling it to put it in the
> garage."
With the current relational implementations, this statement is very true,
which is why you'll hear it even from people who aren't OODBMS users.
Anyone who has written mapping code from objects to tables and the mapping
code back from the tables to the objects has experienced this.
> And of course it is not the Holy Grail, it is only the foundation of
> modern data management.
Many people think that modern data management doesn't perform very well.
> > Despite your slip into unsubstantiated hyperbole, the "almost always"
part
>
> Compare their market shares. Everybody says that OODBMSes are a niche
> technology and SQL DBMSes sales grow faster.
Which is the basis for my original reply to this thread. It's SQL and its
convenience and ubiquity that's caused people to work so hard to make
current relational databases work with complex models with which they don't
perform well. Even Oracle acknowledges that their tables don't perform very
well when the application requires a lot of traversal.
> OODBMSes agonize in niches which are not very interesting for SQL DBMS
> vendors.
The SQL DBMS vendors are very interested in our "niches". XML, for example
(I know, I know, XML is nonsense). VLDB, for example. They don't compete
much in the embedded market because they'd have to reduce their memory and
disk footprint by many orders of magnitude. To compete where they can, they
spread FUD, leverage the advantages of being their size and come out with
new versions and features that offer to do what we do, but don't.
> > of the above is telling. If there is ANY class of applications for which
an
> > object database is superior, then the technology has merit and the
>
> Yes, the technology may have lots of merits. It is the "model" what is
> primitive, and you can not go very far with a primitive model.
You can't go at all with an unimplemented model.
> With a good relational technology like the TransRelational Model and a
> good implementation of The Third Manifesto we can be pretty sure that
> there is not any application for which an object database is superior.
> OODBMSes are a dead end, and RDBMSs are now starting a revolution in
> the implementation side.
I don't see any evidence of this. Who is participating in this revolution?
None of the big vendors.
> > Relational Bigots should stop trying to bury that value under misleading
> > attacks of "you have no mathematical model".
>
> I don't think we are questioning the implementations. A perfect
> implementation of a bubble sort can not compete with a crappy
> quicksort implementation in most cases.
>
> > In my experience, for the class of applications that I develop, ODBMS
are
> > superior to RDBMS.
>
> Why?
>
> If you change RDBMS by SQL DBMS I could agree.
Then you really should be getting on the relational database newsgroups and
giving them hell for calling themselves RDBMS. They're apparently the ones
who are giving RDBMS a bad name, not the OODBMS community.
> > > The problems of relational implementations can be solved with better
> > > implementations. OODBMSes were a wrong path, and they are vanishing.
> >
> > And you are falling back into the theory vs. practice trap. Your first
> > sentence may be right, but I haven't seen it.
>
> See the TransRelational Model.
>
> > Your second sentence is an
> > opinion with which I do not agree.
>
> But most people does.
Most people don't even know what an OODBMS is. I'm amazed at the number of
people with years of database experience are completely unfamiliar with any
other model than SQL/RDBMS.
There are more OODBMS vendors and products out there than there were a few
years ago, not fewer.
Microsoft Access 2002 for Dummies has sold a whole lot more copies than The
Third Manifesto, but that doesn't mean that it's a better book or a better
model.
> http://www.leavcom.com/db_08_00.htm
>
> > > The state of the art is light years beyond the old pseudo-relational
> > > implementations we have to use.
> >
> > This is a non-sequitur. The implementations we have to use ARE the state
of
> > the art (for non-database engine developers).
>
> What you call the state of the art is the state of the market. The
> state of the art is what the database engine developers and designers
> know and what they are developing now.
That's not the state of the art, that's a wait state.
A decent way to save some disk space, but we're able to do much of the same
thing already. By using a map of attributes to object ID(s), you can
eliminate the attribute from the objects themselves, eliminating redundancy
and space for null values.
It sounds like this "very last advance" in relational technology is
something we've provided for years.
> Regards
> Alfredo
Alfredo Novoa
> > I don't agree, I have readen hundreds of critiques to the Relational
> > Model made by OO practicioners.
>
> I'm sure they're predominantly references to relational implementations, not
> the model.
You are wrong. You only have to make some google queries.
> > I am tired of nonsenses like this: "Using tables to store objects is
> > like driving your car home and then disassembling it to put it in the
> > garage."
>
> With the current relational implementations, this statement is very true,
It is completely false with Oracle, DB2, FirstSQL and others.
And remember that integers and character strings are also objects. You
can store simple objects using any SQL DBMS.
> > And of course it is not the Holy Grail, it is only the foundation of
> > modern data management.
>
> Many people think that modern data management doesn't perform very well.
They are ignorants because they don't distinguish between model and
implementation.
> > Compare their market shares. Everybody says that OODBMSes are a niche
> > technology and SQL DBMSes sales grow faster.
>
> Which is the basis for my original reply to this thread. It's SQL and its
> convenience and ubiquity that's caused people to work so hard to make
> current relational databases work with complex models with which they don't
> perform well.
And the OO solution is to work with primitive models. I don't like
such solution.
But SQL DBMSes perform well in most cases.
> > OODBMSes agonize in niches which are not very interesting for SQL DBMS
> > vendors.
>
> The SQL DBMS vendors are very interested in our "niches". XML, for example
> (I know, I know, XML is nonsense). VLDB, for example.
Most VLDB's are relational.
You have only very special cases of VLDB's
> They don't compete
> much in the embedded market because they'd have to reduce their memory and
> disk footprint by many orders of magnitude.
And that is why the niche is not attractive for them. They should make
strong investiments for a little niche. But perhaps the
Transrelational Model will change this.
> > Yes, the technology may have lots of merits. It is the "model" what is
> > primitive, and you can not go very far with a primitive model.
>
> You can't go at all with an unimplemented model.
You only have to implement it.
> I don't see any evidence of this. Who is participating in this revolution?
It is difficult to know that.
> None of the big vendors.
Can you prove this?
I don't know if they are participating or not, but it is true that
rewriting a DBMS like DB2 from scratch is a difficult decission.
Big vendors often wait and buy upstart companies when their future
success is clear.
> Then you really should be getting on the relational database newsgroups and
> giving them hell for calling themselves RDBMS.
It seems you don't read comp.databases.theory very often.
Very few people there confuse SQL DBMSes with RDBMSes.
> Most people don't even know what an OODBMS is.
IMO a lot of OODBMS developers could be included.
OODBMSes are only maked-up network DBMSes.
> There are more OODBMS vendors and products out there than there were a few
> years ago, not fewer.
But the sum of their sales makes a smaller market percentage than a
few years ago and most of the research in OODBMSes was abandoned.
> > What you call the state of the art is the state of the market. The
> > state of the art is what the database engine developers and designers
> > know and what they are developing now.
>
> That's not the state of the art, that's a wait state.
A wait for end users, but a reality for developers.
We also have to wait several years in order to see the Formula One
state of the art technologies in our cars.
> > The idea is incredibly simple and it is no more a secret.
>
> A decent way to save some disk space, but we're able to do much of the same
> thing already. It sounds like this "very last advance" in relational technology is
> something we've provided for years.
It is evident you have not caugth it.
Alfredo
Jim Melton
> "Jim Melton" <jim.m...@lmco.com> wrote in message
news:<bc2i19$qi...@cui1.lmms.lmco.com>...
>
> > I think this distinction is not clearly drawn in the discussions and
people
> > often read what they expect to see. I doubt very much that OO
practitioners
> > question the Relational Model (except as the Holy Grail of data
management).
> > Rather, they question relational databases.
>
> I don't agree, I have readen hundreds of critiques to the Relational
> Model made by OO practicioners.
How many "OO practitioners"? People tend to see what they are looking for. I
myself could have been accused of critiquing the Relational Model, based on
a google search, but I assure you that I have not done so. The
misunderstanding in language I am talking about is very much at issue
(especially when folks from comp.databases.theory troll in
comp.databases.object).
Good communication is very much about understanding the intention of the
speaker (writer), and not so much picking his words apart. Grace must be
given to compensate for differing communication skills. The relational
theorists have a particular vocabulary (as any specialty does) and they (as
a group) tend to assume that everyone else invests the same meaning in their
words as they do. Within the realm of comp.databases.theory, that is a
reasonable assumption. Outside, it is false and leads to misunderstanding
and miscommunication.
> I am tired of nonsenses like this: "Using tables to store objects is
> like driving your car home and then disassembling it to put it in the
> garage."
How then do you address the very real issue that it is necessary to copy,
attribute by attribute, the returned rows from a query into programming
language constructs (objects)? I have read (unsubstantiated) estimates that
20% of an application's code is accounted for in this mapping layer. It is
very tedious to write and adds no value.
> > Despite your slip into unsubstantiated hyperbole, the "almost always"
part
>
> Compare their market shares. Everybody says that OODBMSes are a niche
> technology and SQL DBMSes sales grow faster.
Again, watch the hyperbole. Everybody is a very exclusive set. However, I
will not even dispute your point here. So what if ODBMS is a niche
technology? Niches exist because there are classes of users or applications
that require them. To borrow from one of your later analogies, Formula One
racing is a niche, but it still exists. Their sales are not anywhere near
the sales of econobox sedans. So what?
> OODBMSes agonize in niches which are not very interesting for SQL DBMS
> vendors.
OK. So leave us alone in our niche.
> > of the above is telling. If there is ANY class of applications for which
an
> > object database is superior, then the technology has merit and the
>
> Yes, the technology may have lots of merits. It is the "model" what is
> primitive, and you can not go very far with a primitive model.
In theory, there is no difference between theory and practice. In practice,
there usually is. I don't give a hoot how good your model is if it is not
implementable or has not been implemented. Show me a commercial
implementation of a pure relational model database that blows the socks off
my object database *in my application* and I'll be happy to switch.
I don't give a hoot about OLTP benchmarks.
> With a good relational technology like the TransRelational Model and a
> good implementation of The Third Manifesto we can be pretty sure that
> there is not any application for which an object database is superior.
> OODBMSes are a dead end, and RDBMSs are now starting a revolution in
> the implementation side.
And you are just as guilty of the hype that ODBMS vendors engaged in when
their technology was nascent.
> > Relational Bigots should stop trying to bury that value under misleading
> > attacks of "you have no mathematical model".
>
> I don't think we are questioning the implementations. A perfect
> implementation of a bubble sort can not compete with a crappy
> quicksort implementation in most cases.
That is all we are questioning. Users of databases (not developers of
database engines) don't get to affect the implementation, they have to live
with what they can buy. Beyond that, theory is an interesting mental
exercise, but the pragmatist must live at the intersection of theory and
implementation.
> > In my experience, for the class of applications that I develop, ODBMS
are
> > superior to RDBMS.
>
> Why?
I don't know.
> If you change RDBMS by SQL DBMS I could agree.
See above. Oracle will bill itself as RDBMS. If in your theoretical world,
you prefer to call what the rest of us have access to SQL DBMS, that is
fine, but "everybody" else will still call it RDBMS.
> > > The problems of relational implementations can be solved with better
> > > implementations. OODBMSes were a wrong path, and they are vanishing.
> >
> > And you are falling back into the theory vs. practice trap. Your first
> > sentence may be right, but I haven't seen it.
>
> See the TransRelational Model.
Model == Theory.
Show me a commercial implementation.
> > Your second sentence is an
> > opinion with which I do not agree.
>
> But most people does.
So? I'm not a lemming. I make my own decisions. I use a Macintosh and prefer
SGI over Sun. I use the technology that best solves the particular problem
at hand.
>
> http://www.leavcom.com/db_08_00.htm
A three-year-old article from a marketing communications company. That
particular opinion is not difficult to find. However, it is still the "most
people will be buying" argument, not based on any technical basis, or
evaluation of the requirements of any class of applications.
> > > The state of the art is light years beyond the old pseudo-relational
> > > implementations we have to use.
> >
> > This is a non-sequitur. The implementations we have to use ARE the state
of
> > the art (for non-database engine developers).
>
> What you call the state of the art is the state of the market. The
> state of the art is what the database engine developers and designers
> know and what they are developing now.
Fine. Call it the state of the market if you wish. It is still all that
application developers have to work with. I think I made that point quite
clearly (see the parenthetical clause you quoted above).
> > You have no basis on which to judge whether my costs are higher or lower
> > than if I were using a relational database.
>
> I don't know your project, but we have strong theoretical basis. The
> problem is that there are not relational DBMSes avaiable on the
> market.
And we come full circle. If there is no relational DBMS on the market, then
you are talking theory. People who use ODBMSs (products that ARE on the
market) are talking practice. We must agree on the frame of reference if
communication is going to occur.
> Perhaps you are using the best DBMS avaiable for your project, I am
> not questioning that. My point is that if good DBMS developers had
> developed a truly RDBMS for your niche it would be a lot superior to
> any OODBMS.
A supposition in which I have no interest.
> > > It seems you are not aware about the very last advances in relational
> > > technology.
> >
> > And either these advances are more theory, you are similarly uninformed,
or
> > you thought it would otherwise be helpful not to expound in any detail
on
> > these advances.
>
> Google for "value instance connectivity" (quotes included).
>
> The idea is incredibly simple and it is no more a secret.
Thank you for the reference. I'm not sure this addresses the "niche" of
complex data types and relationships. I won't claim to be any kind of
database theorist, but what I was able to glean from the patent application
looks like nothing more than storing values in index (value) tables (only)
and reconstituting rows at runtime from the associated value tables.
Alfredo Novoa
> > I am tired of nonsenses like this: "Using tables to store objects is
> > like driving your car home and then disassembling it to put it in the
> > garage."
>
> How then do you address the very real issue that it is necessary to copy,
> attribute by attribute, the returned rows from a query into programming
> language constructs (objects)?
Using an SQL DBMS which permits complex types like: Oracle, DB2,
FirstSQL, Postgres, etc.
> I have read (unsubstantiated) estimates that
> 20% of an application's code is accounted for in this mapping layer. It is
> very tedious to write and adds no value.
In lots of cases I have seen, the object model does not add value
either.
A lot of people create "business" class hierarchies with classes like
"employee", "product", "invoice", etc. And it is an horrible blunder.
Later a lot of code is required due to such mistake.
OODBMSes does not have anything to do in business systems.
> > Compare their market shares. Everybody says that OODBMSes are a niche
> > technology and SQL DBMSes sales grow faster.
>
> Again, watch the hyperbole. Everybody is a very exclusive set. However, I
> will not even dispute your point here. So what if ODBMS is a niche
> technology?
It does not have a lot of future.
> Niches exist because there are classes of users or applications
> that require them. To borrow from one of your later analogies, Formula One
> racing is a niche
It is not a niche, it is an experimentation bank mixed with show
business.
Niche is a term used for obsolescent sectors and technologies. They
are a refuge where obsolescent sectors/technologies make the last cash
before the death.
At least it is what I have learnt in sectorial economy classes.
> > OODBMSes agonize in niches which are not very interesting for SQL DBMS
> > vendors.
>
> OK. So leave us alone in our niche.
This group is not comp.databases.oodbmses
Oracle, DB2, FirstSQL, Dataphor, etc are also "object" DBMSes.
They are sometimes called Object-Relational DBMSes, and OODBMSes could
be called Object-Network DBMSes.
> And you are just as guilty of the hype that ODBMS vendors engaged in when
> their technology was nascent.
It is a different case because there is a sound theoretical foundation
behind RDBMSes.
> > > In my experience, for the class of applications that I develop, ODBMS
> are
> > > superior to RDBMS.
> >
> > Why?
>
> I don't know.
It is like saying you don't understand what you do.
> > If you change RDBMS by SQL DBMS I could agree.
>
> See above. Oracle will bill itself as RDBMS.
Because they are interested in spreading ignorance, and they are very
eficient doing that job.
> > See the TransRelational Model.
>
> Model == Theory.
I agree it is a bad name for a technology.
> particular opinion is not difficult to find. However, it is still the "most
> people will be buying" argument, not based on any technical basis, or
> evaluation of the requirements of any class of applications.
It reflects the fact that SQL DBMSes are better than OODBMSes for most
systems.
Most of the people who were imprudent enough to try OODBMSes in
business systems have learnt the lesson.
> And we come full circle. If there is no relational DBMS on the market, then
> you are talking theory.
But we are talking about very special cases. The norm is that SQL
DBMSes are better.
The problem is that a lot of people use ODBMSes where SQL DBMSes are
superior.
E.g. business systems.
> A supposition in which I have no interest.
It is not my problem.
> Thank you for the reference. I'm not sure this addresses the "niche" of
> complex data types and relationships.
RDBMSes have the same problems with complex data types as OODBMSes.
They were not a lot of technological problems there.
I don't know what you meant with complex relationships, but with this
technology you can forget all the performance problems of relational
queries.
> database theorist, but what I was able to glean from the patent application
> looks like nothing more than storing values in index (value) tables (only)
> and reconstituting rows at runtime from the associated value tables.
You can get any information you want from the database very
eficiently. You can make your logical relational designs forgeting
performance issues.
Regards
Alfredo
Jim Melton
> "Jim Melton" <jim.m...@lmco.com> wrote in message
news:<bc7q72$dn...@cui1.lmms.lmco.com>...
>
> > > I am tired of nonsenses like this: "Using tables to store objects is
> > > like driving your car home and then disassembling it to put it in the
> > > garage."
> >
> > How then do you address the very real issue that it is necessary to
copy,
> > attribute by attribute, the returned rows from a query into programming
> > language constructs (objects)?
>
> Using an SQL DBMS which permits complex types like: Oracle, DB2,
> FirstSQL, Postgres, etc.
For example, suppose the application has a Person class. Surely you don't
recommend storing a Person object (domain?) as a column of a table? I can
see creating simple types, like GeoLocation (lat/lon/eep), but with more
complex types, it would seem that the distinction between domain and
relation would be crossed.
> > I have read (unsubstantiated) estimates that
> > 20% of an application's code is accounted for in this mapping layer. It
is
> > very tedious to write and adds no value.
>
> In lots of cases I have seen, the object model does not add value
> either.
FUD.
> A lot of people create "business" class hierarchies with classes like
> "employee", "product", "invoice", etc. And it is an horrible blunder.
> Later a lot of code is required due to such mistake.
Class hierarchies that improperly use inheritance will always cause trouble.
Any improper data design will cause trouble. Because you have seen unskilled
people do bad things does not condemn a technology. I've seen bad database
designs that required massive rework, affecting lots of code as well. So
what?
> OODBMSes does not have anything to do in business systems.
This statement is too general to be supportable, although I agree with you
in the main. Classical OLTP is well suited to relational (or SQL) databases
and should be implemented by such.
> > Again, watch the hyperbole. Everybody is a very exclusive set. However,
I
> > will not even dispute your point here. So what if ODBMS is a niche
> > technology?
>
> It does not have a lot of future.
Predicting the future is a valuable skill. I presume you are rich by now?
> > Niches exist because there are classes of users or applications
> > that require them. To borrow from one of your later analogies, Formula
One
> > racing is a niche
[...]
> Niche is a term used for obsolescent sectors and technologies. They
> are a refuge where obsolescent sectors/technologies make the last cash
> before the death.
>
> At least it is what I have learnt in sectorial economy classes.
Then you learned poorly. From the dictionary
(http://dictionary.reference.com/search?q=niche):
a..
1.. A situation or activity specially suited to a person's interests,
abilities, or nature: found her niche in life.
2.. A special area of demand for a product or service: "One niche that is
approaching mass-market proportions is held by regional magazines" (Brad
Edmondson).
> > > OODBMSes agonize in niches which are not very interesting for SQL DBMS
> > > vendors.
> >
> > OK. So leave us alone in our niche.
>
> This group is not comp.databases.oodbmses
O = Object
DB = Database
comp.databases.object
What do you think the charter of this NG is/should be?
> Oracle, DB2, FirstSQL, Dataphor, etc are also "object" DBMSes.
You don't believe that any more than you believe they are "relational"
databases, do you?
> > And you are just as guilty of the hype that ODBMS vendors engaged in
when
> > their technology was nascent.
>
> It is a different case because there is a sound theoretical foundation
> behind RDBMSes.
Hype is hype.
> > > > In my experience, for the class of applications that I develop,
ODBMS
> > are
> > > > superior to RDBMS.
> > >
> > > Why?
> >
> > I don't know.
>
> It is like saying you don't understand what you do.
No, it is saying that I can't tell you what makes one technology superior to
another. I can't discuss the merits of the Wankel rotary engine versus the
V-6 versus the box 4. But I could tell you which car I like to drive better.
> > particular opinion is not difficult to find. However, it is still the
"most
> > people will be buying" argument, not based on any technical basis, or
> > evaluation of the requirements of any class of applications.
>
> It reflects the fact that SQL DBMSes are better than OODBMSes for most
> systems.
Is "most" based on number of deployed systems (e.g., "most" people use
Windows) or on a survey of all classes of applications that use databases or
just FUD? The article makes opinionated statements. The opinions may be
widely held, but the only arguments presented were market share.
> Most of the people who were imprudent enough to try OODBMSes in
> business systems have learnt the lesson.
The right tool for the job.
> > And we come full circle. If there is no relational DBMS on the market,
then
> > you are talking theory.
>
> But we are talking about very special cases. The norm is that SQL
> DBMSes are better.
>
> The problem is that a lot of people use ODBMSes where SQL DBMSes are
> superior.
And you have persisted in writing responses without reading the antecedant.
I have been very careful to qualify everything I have said about ODBMSs. In
some applications. In my experience. Et cetera.
The problem is that people talk without understanding or without listening.
The thesis of this sub-thread (where I came in) was that much of the ranting
on this newsgroup is between people who confuse theory with implementation.
You are now guilty of that as well.
The fact that you like your theory better than my implementation is
irrelevant. The fact that my implementation doesn't conform to your theory
is also irrelevant, unless you can offer me an implementation that does
conform to your theory AND which satisfies all my other requirements.
> E.g. business systems.
And the world is a bigger place than business systems.
> You can get any information you want from the database very
> eficiently. You can make your logical relational designs forgeting
> performance issues.
This is total nonsense. You can NEVER design forgetting performance issues.
On any level. Performance issues must be understood and accounted for as
soon as possible, or you run the risk of significant rework. The performance
issues with your technology may be different than traditional "SQL"
databases (I'll humor you), but they still exist and must be accounted for
in the design.
Paul DeWolf
> "Paul DeWolf" <pa...@thievesandkings.com> wrote in message
news:<IXvFa.97073$d51.163333@sccrnsc01>...
<snip>
> > > OODBMSes agonize in niches which are not very interesting for SQL DBMS
> > > vendors.
> >
> > The SQL DBMS vendors are very interested in our "niches". XML, for
example
> > (I know, I know, XML is nonsense). VLDB, for example.
>
> Most VLDB's are relational.
It depends on your definition of "VL". Most VLDB's are not public and you
don't know about them.
What relational "VLDB"s there are use files external to the database to hold
large BLOBs, effectively using crude object-oriented techniques.
OODBMS is much more of a niche in terms of market share than in technology.
Database users will go to extraordinary lengths to hang on to the SQL
security blanket and other legacies. Applications that would perform faster
and less expensively in an OODBMS will be implemented and maintained in
SQL/RDBMS.
Other users decide to build their own home-grown database so they can avoid
the cost and dependency on a small vendor.
In terms of the amount of data that exists, as opposed to the amount of
money that's spent, RDBMS doesn't dominate.
> You have only very special cases of VLDB's
The VL ones.
<snip>
> Alfredo
Paul DeWolf
Well maybe they can, but they certainly can't fly very well.
Bumblebees should read about aerodynamics so they can really appreciate how
poorly they fly.
In fact, they should stop hanging around with each other acting and talking
like they can fly because eventually they won't be able to fly anymore.
They should look at companies like Boeing and McDonnell Douglas to provide
their flight for them.
They shouldn't say they tried that and it didn't work, because they clearly
don't understand how to use their products. Bumblebees don't have a good
model for flight.
Well, maybe for the particular kind of flying they do, but their kind of
flying really has no value.
Anything that Boeing and McDonnell Douglas are missing in providing flight
to bumblebees can be solved with more compliance to aerodynamics.
Aerodynamics is the foundation of all modern flight.
Aerodynamic engineers determined that big bodies and short wings that move
up and down are an incorrect way to build air transportation. Bumblebees
shouldn't do it.
Soon all aerodynamic principles will be fully applied, instead of just
partially applied by the big aircraft makers. We'll have a new
implementation that will revolutionize flight and previous flight by any
existing species including Boeing's and McDonnell Douglas' will be rendered
obsolete.
Paul
Carl Rosenberger
Superb, Paul, a great read and laugh, thanks!
This article will get famous as "Tutorial B".
Cheers,
Carl
"Paul DeWolf" <pa...@thievesandkings.com> wrote in message news:tm5Ga.964884$Zo.219579@sccrnsc03...
Alfredo Novoa
> > Using an SQL DBMS which permits complex types like: Oracle, DB2,
> > FirstSQL, Postgres, etc.
>
> For example, suppose the application has a Person class.
Then probably the application should be redesigned, a Person class is
a bad design if Person has relations with other entities.
> Surely you don't
> recommend storing a Person object (domain?) as a column of a table?
I don't recomend a Person object.
> see creating simple types, like GeoLocation (lat/lon/eep), but with more
> complex types, it would seem that the distinction between domain and
> relation would be crossed.
The differences between domain (type) and relation variable are huge.
> > In lots of cases I have seen, the object model does not add value
> > either.
>
> FUD.
Your Person class is a good example.
> > A lot of people create "business" class hierarchies with classes like
> > "employee", "product", "invoice", etc. And it is an horrible blunder.
> > Later a lot of code is required due to such mistake.
>
> Class hierarchies that improperly use inheritance will always cause trouble.
It is not only an inproper use of inheritance, it is an inproper use
of "encapsulation".
All such entities should be "unencapsulated" in tables.
> Any improper data design will cause trouble. Because you have seen unskilled
> people do bad things does not condemn a technology.
No, but OODBMSes are promoted using bad designs. OODBMS advocates show
an horrible design and they say: this design is not easy to implement
with SQL DBMSes therefere you should move to OODBMSes.
> > > will not even dispute your point here. So what if ODBMS is a niche
> > > technology?
> >
> > It does not have a lot of future.
>
> Predicting the future is a valuable skill. I presume you are rich by now?
No, but not having a lot of future is inherent to the niche concept.
Niches are in cemeteries.
> Then you learned poorly. From the dictionary
> (http://dictionary.reference.com/search?q=niche):
>
> a..
> 1.. A situation or activity specially suited to a person's interests,
> abilities, or nature: found her niche in life.
> 2.. A special area of demand for a product or service: "One niche that is
> approaching mass-market proportions is held by regional magazines" (Brad
> Edmondson).
Unfortunately dictionaries are not a good source for technical jargon
too often.
Not any market segment is a niche. The necrological connotation is
intentional.
"Finding a niche" is a well known term for a typical strategy in
declining markets. A good example of niche are matrix printers used
for delivery notes. Sometimes the niches persists, but they are always
marginal.
But it is true that the term is very often mis/overused at practice.
> > This group is not comp.databases.oodbmses
>
> O = Object
> DB = Database
>
> comp.databases.object
>
> What do you think the charter of this NG is/should be?
About "object issues" in databases.
Object-Relational databases are also object databases.
By the way Object-Relational database is a bad synonym for Relational
database.
A good SQLDBMS or RDBMS must support complex scalar values (objects)
and probably type inheritance also.
> > Oracle, DB2, FirstSQL, Dataphor, etc are also "object" DBMSes.
>
> You don't believe that any more than you believe they are "relational"
> databases, do you?
I don't follow you. Dataphor is relational and the others don't but
FirstSQL is closer, but all of them support object values.
> > It is a different case because there is a sound theoretical foundation
> > behind RDBMSes.
>
> Hype is hype.
And science is science.
> > > > > In my experience, for the class of applications that I develop,
> ODBMS
> are
> > > > > superior to RDBMS.
> > > >
> > > > Why?
> > >
> > > I don't know.
> >
> > It is like saying you don't understand what you do.
>
> No, it is saying that I can't tell you what makes one technology superior to
> another. I can't discuss the merits of the Wankel rotary engine versus the
> V-6 versus the box 4. But I could tell you which car I like to drive better.
My question was why do you like to drive it better. You should know
it.
> > It reflects the fact that SQL DBMSes are better than OODBMSes for most
> > systems.
>
> Is "most" based on number of deployed systems (e.g., "most" people use
> Windows) or on a survey of all classes of applications that use databases or
> just FUD? The article makes opinionated statements. The opinions may be
> widely held, but the only arguments presented were market share.
There are lots of theroretical arguments, market share is only a sign.
But it should be an important sign for the people who reject
theoretical arguments.
> And you have persisted in writing responses without reading the antecedant.
> I have been very careful to qualify everything I have said about ODBMSs. In
> some applications. In my experience. Et cetera.
I am not writing only about your case.
Perhaps in your case the flaws of the SQL DBMS implementations are
more important than the inherent flaws of OODBMSes. I don't know.
My point is that the common complaints against RDBMSes can be solved
and are being solved, but the complaints against OODBMses can not
because they are not only technological problems they are foundational
problems.
Fixing a building with corrupt foundations is very hard, but
relational foundations are rock solid. Object DBMSes must be founded
on The Relational Model. The contrary is a dead end.
> The fact that my implementation doesn't conform to your theory
> is also irrelevant, unless you can offer me an implementation that does
> conform to your theory AND which satisfies all my other requirements.
It is irrelevant for you but not for me.
You can stop the discussion when you want.
> > You can get any information you want from the database very
> > eficiently. You can make your logical relational designs forgeting
> > performance issues.
>
> This is total nonsense. You can NEVER design forgetting performance issues.
It is a fundamental part of the relational promise. I know it is
difficult to understand if you don't have a grasp on data management
theory.
Alfredo
Bob Badour
news:<bca7tc$iu...@cui1.lmms.lmco.com>...
>
> > > Using an SQL DBMS which permits complex types like: Oracle, DB2,
> > > FirstSQL, Postgres, etc.
> >
> > For example, suppose the application has a Person class.
>
> Then probably the application should be redesigned, a Person class is
> a bad design if Person has relations with other entities.
You need to be careful what you say. The last sentence above is absurd.
> > Surely you don't
> > recommend storing a Person object (domain?) as a column of a table?
>
> I don't recomend a Person object.
Why not? Person is a perfectly acceptable type.
> > > > will not even dispute your point here. So what if ODBMS is a niche
> > > > technology?
> > >
> > > It does not have a lot of future.
> >
> > Predicting the future is a valuable skill. I presume you are rich by
now?
>
> No, but not having a lot of future is inherent to the niche concept.
> Niches are in cemeteries.
In 1994, the internet was a small niche. Viagra is a niche product.
> > Then you learned poorly. From the dictionary
> > (http://dictionary.reference.com/search?q=niche):
> >
> > a..
> > 1.. A situation or activity specially suited to a person's interests,
> > abilities, or nature: found her niche in life.
> > 2.. A special area of demand for a product or service: "One niche that
is
> > approaching mass-market proportions is held by regional magazines" (Brad
> > Edmondson).
>
> Unfortunately dictionaries are not a good source for technical jargon
> too often.
>
> Not any market segment is a niche. The necrological connotation is
> intentional.
>
> "Finding a niche" is a well known term for a typical strategy in
> declining markets. A good example of niche are matrix printers used
> for delivery notes. Sometimes the niches persists, but they are always
> marginal.
>
> But it is true that the term is very often mis/overused at practice.
I studied some economics, and even a little marketing. I don't recall ever
encountering your definition of "niche". Plenty of niches are vibrant and
growing. At one time, personal computers were a niche market for hobbyists.
Similarly. at one time, automobiles were a niche market for the rich and
adventurous.
Bob Badour
> "Alfredo Novoa" <alf...@ncs.es> wrote in message
> news:e4330f45.03061...@posting.google.com...
> > "Jim Melton" <jim.m...@lmco.com> wrote in message
> news:<bc7q72$dn...@cui1.lmms.lmco.com>...
> >
> > > > I am tired of nonsenses like this: "Using tables to store objects is
> > > > like driving your car home and then disassembling it to put it in
the
> > > > garage."
> > >
> > > How then do you address the very real issue that it is necessary to
> copy,
> > > attribute by attribute, the returned rows from a query into
programming
> > > language constructs (objects)?
> >
> > Using an SQL DBMS which permits complex types like: Oracle, DB2,
> > FirstSQL, Postgres, etc.
>
> For example, suppose the application has a Person class. Surely you don't
> recommend storing a Person object (domain?) as a column of a table? I can
> see creating simple types, like GeoLocation (lat/lon/eep), but with more
> complex types, it would seem that the distinction between domain and
> relation would be crossed.
If you have a real need to do that, why not? Actually, Fabian Pascal
discusses the option in _Practical Issues in Database Management: A
Reference for the Thinking Practitioner_
> > > I have read (unsubstantiated) estimates that
> > > 20% of an application's code is accounted for in this mapping layer.
It
> is
> > > very tedious to write and adds no value.
> >
> > In lots of cases I have seen, the object model does not add value
> > either.
>
> FUD.
Yes, I agree the unsubstantiated estimate you gave was nothing more than
FUD.
> > > > OODBMSes agonize in niches which are not very interesting for SQL
DBMS
> > > > vendors.
> > >
> > > OK. So leave us alone in our niche.
> >
> > This group is not comp.databases.oodbmses
>
> O = Object
> DB = Database
>
> comp.databases.object
>
> What do you think the charter of this NG is/should be?
Not all object databases are network model, while the term oodbms has become
basically synonymous with the network model. The relational model supports
user-defined types of arbitrary complexity as well as type inheritance
graphs.
> > Oracle, DB2, FirstSQL, Dataphor, etc are also "object" DBMSes.
>
> You don't believe that any more than you believe they are "relational"
> databases, do you?
What, exactly, about Dataphor makes it neither relational nor object?
> > > > > In my experience, for the class of applications that I develop,
> ODBMS
> > > are
> > > > > superior to RDBMS.
> > > >
> > > > Why?
> > >
> > > I don't know.
> >
> > It is like saying you don't understand what you do.
>
> No, it is saying that I can't tell you what makes one technology superior
to
> another.
With all due respect, that means you cannot evaluate whether one technology
is superior to another.
> I can't discuss the merits of the Wankel rotary engine versus the
> V-6 versus the box 4. But I could tell you which car I like to drive
better.
If you want to say that network model oodbms has psychological advantages
and not technological advantages, we would have an entirely different
conversation. I would not agree with you, but so far you have presented your
arguments as technical arguments and not psychological arguments. Why the
sudden switch?
> > > And we come full circle. If there is no relational DBMS on the market,
> then
> > > you are talking theory.
> >
> > But we are talking about very special cases. The norm is that SQL
> > DBMSes are better.
> >
> > The problem is that a lot of people use ODBMSes where SQL DBMSes are
> > superior.
>
> And you have persisted in writing responses without reading the
antecedant.
> I have been very careful to qualify everything I have said about ODBMSs.
In
> some applications. In my experience. Et cetera.
What property of those applications makes using relations and types to
express the data management needs inappropriate or ineffective?
> The problem is that people talk without understanding or without
listening.
I agree that a too many people do not understand and too few listen. I
listen. I understand. As for the others, I can bring the horse to water but
I cannot make it drink.
Bob Badour
With all due respect, Jim, the vocabulary of databases applies in all of
comp.databases.*
> > I am tired of nonsenses like this: "Using tables to store objects is
> > like driving your car home and then disassembling it to put it in the
> > garage."
>
> How then do you address the very real issue that it is necessary to copy,
> attribute by attribute, the returned rows from a query into programming
> language constructs (objects)?
It is not generally necessary to copy attribute by attribute. How do you
address the very real issue that it is similarly necessary to copy the
returned objects from an OODBMS query into a computer's memory address
space?
> I have read (unsubstantiated) estimates that
> 20% of an application's code is accounted for in this mapping layer. It is
> very tedious to write and adds no value.
As you say, it is unsubstantiated and in fact not necessary. I am sure I can
find OO programmes where a "mapping layer" accounts for 0% of an
application's code and other OO programmes where it accounts for more than
50% of an application's code.
People naturally resist blaming the consequences of their arbitrary design
decisions on their own arbitrary design decisions.
> > > Despite your slip into unsubstantiated hyperbole, the "almost always"
> part
> >
> > Compare their market shares. Everybody says that OODBMSes are a niche
> > technology and SQL DBMSes sales grow faster.
>
> Again, watch the hyperbole. Everybody is a very exclusive set. However, I
> will not even dispute your point here. So what if ODBMS is a niche
> technology? Niches exist because there are classes of users or
applications
> that require them. To borrow from one of your later analogies, Formula One
> racing is a niche, but it still exists. Their sales are not anywhere near
> the sales of econobox sedans. So what?
Niches are not inherently good nor are they inherently bad. The niche for
loud, fast, entertaining, competitive sports exists independent of Formula
One.
An rdbms would better serve the needs of the niches that oodbms/network
model now serves--just as Formula One better serves the needs of its niche
than the technologies that preceded it. Surely, given the employer you
identify in your sig line, you understand importance of improving technology
to better serve a niche.
> > OODBMSes agonize in niches which are not very interesting for SQL DBMS
> > vendors.
>
> OK. So leave us alone in our niche.
Do you think it is rational to ask for your needs to be underserved?
> > > of the above is telling. If there is ANY class of applications for
which
> an
> > > object database is superior, then the technology has merit and the
> >
> > Yes, the technology may have lots of merits. It is the "model" what is
> > primitive, and you can not go very far with a primitive model.
>
> In theory, there is no difference between theory and practice. In
practice,
> there usually is. I don't give a hoot how good your model is if it is not
> implementable or has not been implemented.
Given that you and your employer suffer harm from having no commercially
available rdbms, you should give a hoot. Of course, nothing forces you to
act in your own best interest.
> > > Relational Bigots should stop trying to bury that value under
misleading
> > > attacks of "you have no mathematical model".
> >
> > I don't think we are questioning the implementations. A perfect
> > implementation of a bubble sort can not compete with a crappy
> > quicksort implementation in most cases.
>
> That is all we are questioning.
Your sentence above is not clear. Are you questioning only whether a bubble
sort can compete with a quicksort?
> > > In my experience, for the class of applications that I develop, ODBMS
> are
> > > superior to RDBMS.
> >
> > Why?
>
> I don't know.
Shouldn't we conclude from the above that you are proselytizing faith-based
ignorance in preference to science?
> > If you change RDBMS by SQL DBMS I could agree.
>
> See above. Oracle will bill itself as RDBMS. If in your theoretical world,
> you prefer to call what the rest of us have access to SQL DBMS, that is
> fine, but "everybody" else will still call it RDBMS.
And I will continue to correct their ignorance. They don't have to enjoy the
correction.
> > http://www.leavcom.com/db_08_00.htm
>
> A three-year-old article from a marketing communications company. That
> particular opinion is not difficult to find. However, it is still the
"most
> people will be buying" argument, not based on any technical basis, or
> evaluation of the requirements of any class of applications.
I agree. However, my arguments are based on technical merits and on
evaluation of the requirements of any application requiring data management. I
make my evaluations on the basis of principle and theory, and I try to
communicate both principle and theory to others so they can likewise comprehend
the evaluation. You seem to criticize and to ridicule the use and the
communication of principle and theory.
If not principle and theory, on what basis do you make your evaluations?
> > > > The state of the art is light years beyond the old pseudo-relational
> > > > implementations we have to use.
> > >
> > > This is a non-sequitur. The implementations we have to use ARE the
state
> of
> > > the art (for non-database engine developers).
> >
> > What you call the state of the art is the state of the market. The
> > state of the art is what the database engine developers and designers
> > know and what they are developing now.
>
> Fine. Call it the state of the market if you wish. It is still all that
> application developers have to work with.
And you apparently oppose any attempt to bring the state of the art to
market and any attempt to educate the market about the state of the art.
Why do you find your opposition worthwhile? Is the payoff psychological?
> > Perhaps you are using the best DBMS avaiable for your project, I am
> > not questioning that. My point is that if good DBMS developers had
> > developed a truly RDBMS for your niche it would be a lot superior to
> > any OODBMS.
>
> A supposition in which I have no interest.
In other words, you have no interest in learning how to better serve your
employer and customer. I find that attitude quite typical if ugly.
Bob Badour
news:<bca7tc$iu...@cui1.lmms.lmco.com>...
>
> > > Using an SQL DBMS which permits complex types like: Oracle, DB2,
> > > FirstSQL, Postgres, etc.
> >
> > For example, suppose the application has a Person class.
>
> Then probably the application should be redesigned, a Person class is
> a bad design if Person has relations with other entities.
You need to be careful what you say. The last sentence above is absurd.
> > Surely you don't
> > recommend storing a Person object (domain?) as a column of a table?
>
> I don't recomend a Person object.
Why not? Person is a perfectly acceptable type.
> > > > will not even dispute your point here. So what if ODBMS is a niche
> > > > technology?
> > >
> > > It does not have a lot of future.
> >
> > Predicting the future is a valuable skill. I presume you are rich by
now?
>
> No, but not having a lot of future is inherent to the niche concept.
> Niches are in cemeteries.
In 1994, the internet was a small niche. Viagra is a niche product.
> > Then you learned poorly. From the dictionary
> > (http://dictionary.reference.com/search?q=niche):
> >
> > a..
> > 1.. A situation or activity specially suited to a person's interests,
> > abilities, or nature: found her niche in life.
> > 2.. A special area of demand for a product or service: "One niche that
is
> > approaching mass-market proportions is held by regional magazines" (Brad
> > Edmondson).
>
> Unfortunately dictionaries are not a good source for technical jargon
> too often.
>
> Not any market segment is a niche. The necrological connotation is
> intentional.
>
> "Finding a niche" is a well known term for a typical strategy in
> declining markets. A good example of niche are matrix printers used
> for delivery notes. Sometimes the niches persists, but they are always
> marginal.
>
> But it is true that the term is very often mis/overused at practice.
I studied some economics, and even a little marketing. I don't recall ever
encountering your definition of "niche". Plenty of niches are vibrant and
growing. At one time, personal computers were a niche market for hobbyists.
Similarly, at one time, automobiles were a niche market for the rich and
adventurous.
Alfredo Novoa
> > > Surely you don't
> > > recommend storing a Person object (domain?) as a column of a table?
> >
> > I don't recomend a Person object.
>
> Why not? Person is a perfectly acceptable type.
Because in most cases specially in business systems the queries and
integrity constraints will be more complex without any gain.
See TTM page 382. "[Encapsulated objects] omit the all important
attribute names".
> > No, but not having a lot of future is inherent to the niche concept.
> > Niches are in cemeteries.
> I studied some economics, and even a little marketing. I don't recall ever
> encountering your definition of "niche". Plenty of niches are vibrant and
> growing. At one time, personal computers were a niche market for hobbyists.
> Similarly, at one time, automobiles were a niche market for the rich and
> adventurous.
I reviewed then concept and I was wrong, niche is used when the demand
of a small group is not satisfied by the main stream products or
companies.
In the case of personal computers, cars and the internet the demand
was huge but unknown or unsatisfiable it that age. In the case of
Viagra, the demand is big and the maker is a main stream company.
Regards
Alfredo
Alfredo Novoa
> > a Person class is
> > a bad design if Person has relations with other entities.
>
> You need to be careful what you say. The last sentence above is absurd.
Perhaps not clear, but not absurd.
If in a conceptual design the entity Person has relationships with
another entities like Employer, Address, etc, then a Person scalar
type is a bad design.
Regards
Alfredo
Jim Melton
> "Jim Melton" <jim.m...@lmco.com> wrote in message
> news:bca7tc$iu...@cui1.lmms.lmco.com...
> > "Alfredo Novoa" <alf...@ncs.es> wrote in message
> > news:e4330f45.03061...@posting.google.com...
>
> Not all object databases are network model, while the term oodbms has
become
> basically synonymous with the network model. The relational model supports
> user-defined types of arbitrary complexity as well as type inheritance
> graphs.
We are back to the disconnect that started this thread. I do not dispute the
relational model in the least. And I am not interested in discussing the
theory behind relational (or SQL) databases and object databases.
I think you have proven in the past that no one can/will answer your call
for an "object database theory" to stand in opposition to relational theory.
However, the fact remains that the *products* sold as ODBMSs -- in some
cases -- outperform the *products* sold as RDBMSs. This is my area of
interest. Whether the bumblebee should be able to fly or not, it does.
> > > > > > In my experience, for the class of applications that I develop,
> > ODBMS
> > > > are
> > > > > > superior to RDBMS.
> > > > >
> > > > > Why?
> > > >
> > > > I don't know.
> > >
> > > It is like saying you don't understand what you do.
> >
> > No, it is saying that I can't tell you what makes one technology
superior
> to
> > another.
>
> With all due respect, that means you cannot evaluate whether one
technology
> is superior to another.
OK, I'll try to make this more clear. In the original context, I took "Why"
as "what are the underlying causes of this superiority", not "what measures
did you use". My measures were basic performance metrics modelled around the
actual data use patterns of our application. Why is the ODBMS faster for our
usage patterns? I can't say.
> > > The problem is that a lot of people use ODBMSes where SQL DBMSes are
> > > superior.
> >
> > And you have persisted in writing responses without reading the
> antecedant.
> > I have been very careful to qualify everything I have said about ODBMSs.
> In
> > some applications. In my experience. Et cetera.
>
> What property of those applications makes using relations and types to
> express the data management needs inappropriate or ineffective?
You are asking a theory question in response to my practice statement. I
have no doubt that ANY application could be implemented using relations and
types. I'm just not sure about the performance costs using available
products.
Jim Melton
for. I
> > myself could have been accused of critiquing the Relational Model, based
on
> > a google search, but I assure you that I have not done so. The
> > misunderstanding in language I am talking about is very much at issue
> > (especially when folks from comp.databases.theory troll in
> > comp.databases.object).
> >
> > Good communication is very much about understanding the intention of the
> > speaker (writer), and not so much picking his words apart. Grace must be
> > given to compensate for differing communication skills. The relational
> > theorists have a particular vocabulary (as any specialty does) and they
(as
> > a group) tend to assume that everyone else invests the same meaning in
their
> > words as they do. Within the realm of comp.databases.theory, that is a
> > reasonable assumption. Outside, it is false and leads to
misunderstanding
> > and miscommunication.
>
> With all due respect, Jim, the vocabulary of databases applies in all of
> comp.databases.*
Perhaps. I believe (and you can dispute me at your pleasure) that one can be
a competent database designer and not have read <jargon>TTM</jargon>.
> > How then do you address the very real issue that it is necessary to
copy,
> > attribute by attribute, the returned rows from a query into programming
> > language constructs (objects)?
>
> It is not generally necessary to copy attribute by attribute. How do you
> address the very real issue that it is similarly necessary to copy the
> returned objects from an OODBMS query into a computer's memory address
> space?
We've been over this before. Both the RDBMS and the ODBMS "copy" data from
persistent storage to computer memory. In a classic client/server model, the
data is then copied again across the network into the memory of the client.
In the case of the RDBMS, the data must then be copied once more from the
result table row to a construct available for the application (except in the
most trivial of cases). In the ODBMS case, the "row" of the "result table"
*is* a construct available for the application.
As an aside, Objectivity/DB is implemented such that the access from
persistent storage to computer memory happens at the client, potentially
saving at least one copy.
> Niches are not inherently good nor are they inherently bad. The niche for
> loud, fast, entertaining, competitive sports exists independent of Formula
> One.
>
> An rdbms would better serve the needs of the niches that oodbms/network
> model now serves--just as Formula One better serves the needs of its niche
> than the technologies that preceded it. Surely, given the employer you
> identify in your sig line, you understand importance of improving
technology
> to better serve a niche.
I have no complaint about improving technology. It is just outside my power.
I must implement systems with the tools available at my disposal *today*.
> > > OODBMSes agonize in niches which are not very interesting for SQL DBMS
> > > vendors.
> >
> > OK. So leave us alone in our niche.
>
> Do you think it is rational to ask for your needs to be underserved?
You address this from a completely different perspective than Alfredo. You
lobby for the state of the practice in relational databases to rise to the
full promise of the relational model. I make no attempt to hinder that
effort.
Alfredo was criticizing the existence of ODBMSs without accepting the
reality that *today* there are classes of applications better served by
object databases.
> > > > of the above is telling. If there is ANY class of applications for
> which
> > an
> > > > object database is superior, then the technology has merit and the
> > >
> > > Yes, the technology may have lots of merits. It is the "model" what is
> > > primitive, and you can not go very far with a primitive model.
> >
> > In theory, there is no difference between theory and practice. In
> practice,
> > there usually is. I don't give a hoot how good your model is if it is
not
> > implementable or has not been implemented.
>
> Given that you and your employer suffer harm from having no commercially
> available rdbms, you should give a hoot. Of course, nothing forces you to
> act in your own best interest.
You are mistaken. Unless I am willing to undertake implementation of the
model, I cannot afford the energy to worry about what is not. Show me a
viable implementation, and I'll be happy to evaluate its suitability for my
applications.
> > > > Relational Bigots should stop trying to bury that value under
> misleading
> > > > attacks of "you have no mathematical model".
> > >
> > > I don't think we are questioning the implementations. A perfect
> > > implementation of a bubble sort can not compete with a crappy
> > > quicksort implementation in most cases.
> >
> > That is all we are questioning.
>
> Your sentence above is not clear. Are you questioning only whether a
bubble
> sort can compete with a quicksort?
We are questioning implementations of databases, not theory. Since the
analogy did not assign database technology to the sort algorithms, I didn't
put much stock in it.
> > > http://www.leavcom.com/db_08_00.htm
> >
> > A three-year-old article from a marketing communications company. That
> > particular opinion is not difficult to find. However, it is still the
> "most
> > people will be buying" argument, not based on any technical basis, or
> > evaluation of the requirements of any class of applications.
>
> I agree. However, my arguments are based on technical merits and on
> evaluation of the requirements of any application requiring data
management. I
> make my evaluations on the basis of principle and theory, and I try to
> communicate both principle and theory to others so they can likewise
comprehend
> the evaluation. You seem to criticize and to ridicule the use and the
> communication of principle and theory.
Your response is orthogonal. Alfredo offered the cited article as "proof"
that object databases were "dead". I disputed that it was proof of anything.
> If not principle and theory, on what basis do you make your evaluations?
Theory, principle, and reality.
> > > > > The state of the art is light years beyond the old
pseudo-relational
> > > > > implementations we have to use.
> > > >
> > > > This is a non-sequitur. The implementations we have to use ARE the
> state
> > of
> > > > the art (for non-database engine developers).
> > >
> > > What you call the state of the art is the state of the market. The
> > > state of the art is what the database engine developers and designers
> > > know and what they are developing now.
> >
> > Fine. Call it the state of the market if you wish. It is still all that
> > application developers have to work with.
>
> And you apparently oppose any attempt to bring the state of the art to
> market and any attempt to educate the market about the state of the art.
Orthogonal again. See the subject line. The point of this thread is that
these arguments too often arise from one person propounding theory in
response to an implementation.
I have no opposition to bringing anything to market. But don't claim that
vaporware will obviate existing products.
> > > Perhaps you are using the best DBMS avaiable for your project, I am
> > > not questioning that. My point is that if good DBMS developers had
> > > developed a truly RDBMS for your niche it would be a lot superior to
> > > any OODBMS.
> >
> > A supposition in which I have no interest.
>
> In other words, you have no interest in learning how to better serve your
> employer and customer. I find that attitude quite typical if ugly.
Then you didn't pay attention. Read Alfredo's post again: "My point is that
IF ..." (emphasis added). I have no interest in what might have been or what
may be true. When theory becomes reality, I'll be happy to entertain it.
--
<disclaimer>
Opinions posted are those of the author.
My company doesn't pay me enough to speak for them.
</disclaimer>
--
Bob Badour
> "Bob Badour" <bba...@golden.net> wrote in message
> news:cd3b3cf.03061...@posting.google.com...
> > "Jim Melton" <jim.m...@lmco.com> wrote in message
> > news:bca7tc$iu...@cui1.lmms.lmco.com...
> > > "Alfredo Novoa" <alf...@ncs.es> wrote in message
> > > news:e4330f45.03061...@posting.google.com...
> > > What do you think the charter of this NG is/should be?
> >
> > Not all object databases are network model, while the term oodbms has
> become
> > basically synonymous with the network model. The relational model
supports
> > user-defined types of arbitrary complexity as well as type inheritance
> > graphs.
>
> We are back to the disconnect that started this thread. I do not dispute
the
> relational model in the least. And I am not interested in discussing the
> theory behind relational (or SQL) databases and object databases.
>
> I think you have proven in the past that no one can/will answer your call
> for an "object database theory" to stand in opposition to relational
theory.
>
> However, the fact remains that the *products* sold as ODBMSs -- in some
> cases -- outperform the *products* sold as RDBMSs. This is my area of
> interest. Whether the bumblebee should be able to fly or not, it does.
With all due respect, Jim, what does any of that have to do with the charter
of this newsgroup or whether Alfredo and I have business here?
> > > > > > > In my experience, for the class of applications that I
develop,
> > > ODBMS
> > > > > are
> > > > > > > superior to RDBMS.
> > > > > >
> > > > > > Why?
> > > > >
> > > > > I don't know.
> > > >
> > > > It is like saying you don't understand what you do.
> > >
> > > No, it is saying that I can't tell you what makes one technology
> superior
> > to
> > > another.
> >
> > With all due respect, that means you cannot evaluate whether one
> technology
> > is superior to another.
>
> OK, I'll try to make this more clear. In the original context, I took
"Why"
> as "what are the underlying causes of this superiority", not "what
measures
> did you use". My measures were basic performance metrics modelled around
the
> actual data use patterns of our application. Why is the ODBMS faster for
our
> usage patterns? I can't say.
In other (accurate) words, you chose a specific OODBMS product because it
offered you physical storage options not offered by the other products you
examined. Those physical storage options were sufficiently important to your
application that you willingly accepted the extraordinary development and
maintenance costs of the OODBMS product.
That does not make OODBMS superior to RDBMS, because the difference between
OODBMS and RDBMS have nothing to do with physical storage options and
everything to do with expressibility. Both OODBMS and RDBMS can offer
exactly the same physical storage options.
Unless you intentionally want to talk past others, I suggest you use
accurate terminology. You have already identified the problem as your
refusal to make a real effort to communicate. All you have to do to solve
the problem is make a real effort to say what you actually mean. That only
requires you use the correct words for what you mean to say.
> > > > The problem is that a lot of people use ODBMSes where SQL DBMSes are
> > > > superior.
> > >
> > > And you have persisted in writing responses without reading the
> > antecedant.
> > > I have been very careful to qualify everything I have said about
ODBMSs.
> > In
> > > some applications. In my experience. Et cetera.
> >
> > What property of those applications makes using relations and types to
> > express the data management needs inappropriate or ineffective?
>
> You are asking a theory question in response to my practice statement.
You made a statement about your experience of logical data models and not
about your experience of physical storage structures. In response, I asked
you a question pertinent to logical data models and about their actual use
in practice. If you take the trouble to actually read the antecedent
yourself, you will see that my question asks nothing about theory and asks
only about issues of practice: ie. about appropriateness and about
effectiveness.
If you want to communicate, you can. Or you can continue to refuse to
communicate and to complain about the lack of communication.
Bob Badour
Since many competent database designers predate TTM, your statement is
trivially true. However, no competent database designer in the last quarter
century has been ignorant of relations, of normal forms or of the
differences between conceptual, logical and physical design.
> > > How then do you address the very real issue that it is necessary to
> copy,
> > > attribute by attribute, the returned rows from a query into
programming
> > > language constructs (objects)?
> >
> > It is not generally necessary to copy attribute by attribute. How do you
> > address the very real issue that it is similarly necessary to copy the
> > returned objects from an OODBMS query into a computer's memory address
> > space?
>
> We've been over this before. Both the RDBMS and the ODBMS "copy" data from
> persistent storage to computer memory. In a classic client/server model,
the
> data is then copied again across the network into the memory of the
client.
And this is as true for client/server OODBMS as for any other classic
client/server model.
> In the case of the RDBMS, the data must then be copied once more from the
> result table row to a construct available for the application (except in
the
> most trivial of cases).
Again, your statement is not generally true and does nothing to address the
fact that OODBMS must copy data from buffer memory to application memory.
> In the ODBMS case, the "row" of the "result table"
> *is* a construct available for the application.
Yet again, your statement is not generally true.
> > > > OODBMSes agonize in niches which are not very interesting for SQL
DBMS
> > > > vendors.
> > >
> > > OK. So leave us alone in our niche.
> >
> > Do you think it is rational to ask for your needs to be underserved?
>
> You address this from a completely different perspective than Alfredo. You
> lobby for the state of the practice in relational databases to rise to the
> full promise of the relational model. I make no attempt to hinder that
> effort.
I disagree. By continuing to criticise the logical model because specific
products fail to offer you the physical storage options you demand, you
hinder that effort.
> Alfredo was criticizing the existence of ODBMSs without accepting the
> reality that *today* there are classes of applications better served by
> object databases.
Unless you have evaluated every dbms product in existence, you have no way
to support your assertion. No class of application requiring data management
is better served by network model object databases. Classes of applications
are better served by physical storage options often offered by network model
products.
> > > > > of the above is telling. If there is ANY class of applications for
> > which
> > > an
> > > > > object database is superior, then the technology has merit and the
> > > >
> > > > Yes, the technology may have lots of merits. It is the "model" what
is
> > > > primitive, and you can not go very far with a primitive model.
> > >
> > > In theory, there is no difference between theory and practice. In
> > practice,
> > > there usually is. I don't give a hoot how good your model is if it is
> not
> > > implementable or has not been implemented.
> >
> > Given that you and your employer suffer harm from having no commercially
> > available rdbms, you should give a hoot. Of course, nothing forces you
to
> > act in your own best interest.
>
> You are mistaken. Unless I am willing to undertake implementation of the
> model, I cannot afford the energy to worry about what is not. Show me a
> viable implementation, and I'll be happy to evaluate its suitability for
my
> applications.
By refusing to communicate your needs to vendors and by insisting the
vendors tell you what you need, you are abdicating your responsibility to
yourself and to your employer.
> > > > > Relational Bigots should stop trying to bury that value under
> > misleading
> > > > > attacks of "you have no mathematical model".
> > > >
> > > > I don't think we are questioning the implementations. A perfect
> > > > implementation of a bubble sort can not compete with a crappy
> > > > quicksort implementation in most cases.
> > >
> > > That is all we are questioning.
> >
> > Your sentence above is not clear. Are you questioning only whether a
> bubble
> > sort can compete with a quicksort?
>
> We are questioning implementations of databases, not theory.
Then use vocabulary that expresses implementations of databases and not
vocabulary that expresses theory.
> > If not principle and theory, on what basis do you make your evaluations?
>
> Theory, principle, and reality.
Reality goes without saying. However, one cannot evaluate whether one
product is better than another if one does not know the direction of good.
> > > > > > The state of the art is light years beyond the old
> pseudo-relational
> > > > > > implementations we have to use.
> > > > >
> > > > > This is a non-sequitur. The implementations we have to use ARE the
> > state
> > > of
> > > > > the art (for non-database engine developers).
> > > >
> > > > What you call the state of the art is the state of the market. The
> > > > state of the art is what the database engine developers and
designers
> > > > know and what they are developing now.
> > >
> > > Fine. Call it the state of the market if you wish. It is still all
that
> > > application developers have to work with.
> >
> > And you apparently oppose any attempt to bring the state of the art to
> > market and any attempt to educate the market about the state of the art.
>
> Orthogonal again. See the subject line. The point of this thread is that
> these arguments too often arise from one person propounding theory in
> response to an implementation.
I disagree. These arguments arise from one person refusing to accept that
vocabulary describing logical models describes logical models and that one
must use vocabulary describing physical structures to descrive physical
structures.
> I have no opposition to bringing anything to market.
Then what is your objection to trying to educate the market on the state of
the art as Alfredo tries to do?
> But don't claim that
> vaporware will obviate existing products.
If the vaporware would obviate existing products, why not say it would? What
specifically is your objection to speaking the truth?
> > > > Perhaps you are using the best DBMS avaiable for your project, I am
> > > > not questioning that. My point is that if good DBMS developers had
> > > > developed a truly RDBMS for your niche it would be a lot superior to
> > > > any OODBMS.
> > >
> > > A supposition in which I have no interest.
> >
> > In other words, you have no interest in learning how to better serve
your
> > employer and customer. I find that attitude quite typical if ugly.
>
> Then you didn't pay attention. Read Alfredo's post again: "My point is
that
> IF ..." (emphasis added). I have no interest in what might have been or
what
> may be true. When theory becomes reality, I'll be happy to entertain it.
As I said, you have no interest in learning how to better serve your
Jim Melton
I don't see what your question has to do with the quoted text? The reply to
"what should the charter be" did not answer the question. Never have I said
that you don't have any business here. Certainly not in the above quoted
text. It does (I hope) try to point the discussion back to my central
thesis.
> > > With all due respect, that means you cannot evaluate whether one
> > technology
> > > is superior to another.
> >
> > OK, I'll try to make this more clear. In the original context, I took
"Why"
> > as "what are the underlying causes of this superiority", not "what
measures
> > did you use". My measures were basic performance metrics modelled around
the
> > actual data use patterns of our application. Why is the ODBMS faster for
our
> > usage patterns? I can't say.
>
> In other (accurate) words, you chose a specific OODBMS product because it
> offered you physical storage options not offered by the other products you
> examined. Those physical storage options were sufficiently important to
your
> application that you willingly accepted the extraordinary development and
> maintenance costs of the OODBMS product.
No, those words are not accurate. I chose a specific ODBMS after
benchmarking a few of them. As a class, they were able to achieve greater
performance than the non-ODBMS products available. What their physical
storage options were was a level of detail not of acute interest to us. The
development and maintenance costs have proven no greater (if not less) than
our previous experience with non-ODBMS products.
> That does not make OODBMS superior to RDBMS, because the difference
between
> OODBMS and RDBMS have nothing to do with physical storage options and
> everything to do with expressibility. Both OODBMS and RDBMS can offer
> exactly the same physical storage options.
You seem to want to draw an absolute, once and for all "winner" conclusion.
I certainly have never made any such claim. I said "In my experience, for
the class of applications that I develop, ODBMS are superior to RDBMS." This
speaks nothing to the underlying models and everything to the
implementations available.
> Unless you intentionally want to talk past others, I suggest you use
> accurate terminology. You have already identified the problem as your
> refusal to make a real effort to communicate. All you have to do to solve
> the problem is make a real effort to say what you actually mean. That only
> requires you use the correct words for what you mean to say.
Bob, I respect your knowledge and intellect, if not your social skills. As
I've said before, I've learned a lot from crossing swords with you before.
But communication does not mean telling people what you want them to have
said. I said what I meant and used words that were accurate to me. You can
play Humpty Dumpty if you like. That's not conducive to communication.
> > > What property of those applications makes using relations and types to
> > > express the data management needs inappropriate or ineffective?
> >
> > You are asking a theory question in response to my practice statement.
>
> You made a statement about your experience of logical data models and not
> about your experience of physical storage structures. In response, I asked
> you a question pertinent to logical data models and about their actual use
> in practice. If you take the trouble to actually read the antecedent
> yourself, you will see that my question asks nothing about theory and asks
> only about issues of practice: ie. about appropriateness and about
> effectiveness.
The logical data model is an implementation artifact. You build a logical
model so you can implement it (or at least, I presume you would, using a
truly relational database).
You cannot address implementation (e.g., performance) issues from the
logical side, devoid of implementation, unless you are speaking only
theoretically.
So, to answer your original question in concrete, straightforward,
black-and-white words for you, there is no property of those applications
(of which I am aware) that makes using relations and types to express the
data management needs inappropriate or ineffective. There only do not exist
suffiently performant implementations using relations and types.
(The theory is fine. The implementation is not)
> If you want to communicate, you can. Or you can continue to refuse to
> communicate and to complain about the lack of communication.
Communication is always a two way street. You seem to delight in refusing to
make an effort to understand what was meant unless the words are precisely
the ones you would have chosen yourself. That is the equivalent of putting
up a "One Way" sign.
Bob Badour
I disagree. The charter of the newsgroup seems clear enough from its name,
and my reply to the question described what I think that charter covers.
> Never have I said
> that you don't have any business here. Certainly not in the above quoted
> text. It does (I hope) try to point the discussion back to my central
> thesis.
Your thesis basically complains about your own inaccurate use of
terminology, which seems somehow pointless to me.
I don't see how the above sentence contradicts what I said.
> As a class, they were able to achieve greater
> performance than the non-ODBMS products available.
Again, as a class, they offered you physical storage options not offered by
the other products you examined. Those physical storage options were
sufficiently important to your application that you willingly accepted the
extraordinary development and maintenance costs of the specific OODBMS
product you chose.
> What their physical
> storage options were was a level of detail not of acute interest to us.
Then why did you base your decision solely on those options? After all, by
"benchmarking a few" you measured only physical storage options.
> The
> development and maintenance costs have proven no greater (if not less)
than
> our previous experience with non-ODBMS products.
I have no doubt you would spent a lot trying to get adequate performance
from any product that does not offer the specific physical storage options
you required. However, I have worked with network model dbmses in the past,
and I fully comprehend the relative costs involved in that choice of logical
data model.
> > That does not make OODBMS superior to RDBMS, because the difference
> between
> > OODBMS and RDBMS have nothing to do with physical storage options and
> > everything to do with expressibility. Both OODBMS and RDBMS can offer
> > exactly the same physical storage options.
>
> You seem to want to draw an absolute, once and for all "winner"
conclusion.
No, I want only to accurately communicate the issues. You would not want
anyone to make a costly decision on the basis of inaccurate information,
would you?
> I certainly have never made any such claim. I said "In my experience, for
> the class of applications that I develop, ODBMS are superior to RDBMS."
By your choice of vocabulary, you state the network logical data model is
superior to the relational logical data model, and logical data models are
means of expression. The choice of logical data model has no impact on
performance, per se; the physical storage structures determine performance.
The choice of logical data model impacts only what one can express and how
one expresses it.
What, exactly, about the relational data model makes it inappropriate or
ineffective for expressing your application's data management needs?
If you want to compare products on the basis of physical storage structures,
do that. I cannot read your mind; I can only read your words. If your words
reference only logical data models, I have no way as the reader to know you
really mean physical storage structures. If your words reference logical
data models, my replies will too.
> This
> speaks nothing to the underlying models and everything to the
> implementations available.
I disagree. Your words speak only to the logical data models and not at all
to the implementations. If you really want to speak to the implementations,
you are welcome to start doing so at any time by choosing words that speak
to them.
> > Unless you intentionally want to talk past others, I suggest you use
> > accurate terminology. You have already identified the problem as your
> > refusal to make a real effort to communicate. All you have to do to
solve
> > the problem is make a real effort to say what you actually mean. That
only
> > requires you use the correct words for what you mean to say.
>
> Bob, I respect your knowledge and intellect, if not your social skills. As
> I've said before, I've learned a lot from crossing swords with you before.
> But communication does not mean telling people what you want them to have
> said. I said what I meant and used words that were accurate to me. You can
> play Humpty Dumpty if you like. That's not conducive to communication.
Schizophrenics use words that are accurate to them too, but that doesn't
make what they say comprehensible. Neither I nor anyone else can read your
mind. If you want to get your meaning across, I suggest you use words that
mean what you want to say. If you use words that mean something else, you
won't get your meaning across.
> > > > What property of those applications makes using relations and types
to
> > > > express the data management needs inappropriate or ineffective?
> > >
> > > You are asking a theory question in response to my practice statement.
> >
> > You made a statement about your experience of logical data models and
not
> > about your experience of physical storage structures. In response, I
asked
> > you a question pertinent to logical data models and about their actual
use
> > in practice. If you take the trouble to actually read the antecedent
> > yourself, you will see that my question asks nothing about theory and
asks
> > only about issues of practice: ie. about appropriateness and about
> > effectiveness.
>
> The logical data model is an implementation artifact.
I disagree. The logical data model is an artifact of human intellect
existing independent of any physical manifestation. Your statement is
equivalent to stating that mathematics is an artifact of calculators.
> You build a logical
> model so you can implement it (or at least, I presume you would, using a
> truly relational database).
>
> You cannot address implementation (e.g., performance) issues from the
> logical side, devoid of implementation, unless you are speaking only
> theoretically.
If you want to address implementation (e.g. physical data structures) use
language that describes implementations and not language that describes
logical data models.
> So, to answer your original question in concrete, straightforward,
> black-and-white words for you, there is no property of those applications
> (of which I am aware) that makes using relations and types to express the
> data management needs inappropriate or ineffective. There only do not
exist
> suffiently performant implementations using relations and types.
How do you propose to corroborate your final assertion above? I think the
best you can really say is: None of the specific products you benchmarked
offered the physical storage options you required to achieve adequate
performance.
> (The theory is fine. The implementation is not)
Which implementation is that?
> > If you want to communicate, you can. Or you can continue to refuse to
> > communicate and to complain about the lack of communication.
>
> Communication is always a two way street. You seem to delight in refusing
to
> make an effort to understand what was meant unless the words are precisely
> the ones you would have chosen yourself.
I have no facility to read minds. I accept my limitation. If you refuse to
say what you mean, expect others to misunderstand you.
On usenet, communication is more like a busy quadrangle with traffic moving
in all directions than like a two-way street. Even if you and I were to
speak to each other using your idiosynchratic definitions of words, we would
not really be communicating to the larger community of readers.
Paul DeWolf
> I disagree. The charter of the newsgroup seems clear enough from its name,
> and my reply to the question described what I think that charter covers.
The charter of this newsgroup is obviously to discuss oodbms and ordbms
technology and solutions. This doesn't extend to a discussion of whether or
not they should exist, any more than comp.databases discusses whether or not
databases are a good or a bad thing.
To argue otherwise is to be purposely dense. The very first posting to the
newsgroup was in 1993 and titled "An OODBMS is....... ".
You're suggesting that because "object" is in the name of the newsgroup,
this is the place to trash OODBMS. You could also go to Burger King, yell
that eating red meat is evil, then explain that you were just there for the
french fries.
There are other newsgroups that are perfect forums for pontificating about
the virtues of The Third Manifesto. You and Alfredo respond to just about
any posting from OODBMS practitioners stating that OODBMS is nonsense, that
the posters are misinformed or worse and that the only true way to
enlightenment is through The Third Manifesto and the relational model.
Nobody can stop you from doing this without starting a moderated group, but
I think it's totally inappropriate. To simply respond to a question from an
OODBMS point of view, one apparently has to re-justify the entire existence
of OODBMS.
There are certain premises that newsgroups tend to accept as part of their
mandate, without which the newsgroup becomes useless except as a playground
for off-topic discussions, stupid arguments and/or games of semantics.
People who aren't interested in getting caught in an off-topic flame war
just to get a question answered get driven away. I'm sure this is a great
satisfaction to you and Alfredo, but I think it's a shame.
Paul
nob...@nobody.com
I agree wholeheartedly with Paul's observations. I'm tired of trying
to hold a discussion about OODBMS technology only to have a troll come
in and tell everyone they're full of shit for using OO.
Its either time to moderate this group, or surrender it to the
Relational crispies...
Bill
Alfredo Novoa
> The charter of this newsgroup is obviously to discuss oodbms and ordbms
> technology and solutions. This doesn't extend to a discussion of whether or
> not they should exist
Why not?
>, any more than comp.databases discusses whether or not
> databases are a good or a bad thing.
Then why comp.databases.object don't discusses whether or not object
databases are a good or a bad thing?
> To argue otherwise is to be purposely dense. The very first posting to the
> newsgroup was in 1993 and titled "An OODBMS is....... ".
But in 2003 ORDBMSes are the leading object DBMSes.
> the virtues of The Third Manifesto. You and Alfredo respond to just about
> any posting from OODBMS practitioners stating that OODBMS is nonsense
It is not true.
>, that
> the posters are misinformed
If I think that a poster is misinformed I am free to express my
opinion.
Alfredo
Bob Badour
> news:oKuHa.32$5t5.6...@mantis.golden.net...
>
> > I disagree. The charter of the newsgroup seems clear enough from its name,
> > and my reply to the question described what I think that charter covers.
>
> The charter of this newsgroup is obviously to discuss oodbms and ordbms
> technology and solutions. This doesn't extend to a discussion of whether or
> not they should exist, any more than comp.databases discusses whether or not
> databases are a good or a bad thing.
>
> To argue otherwise is to be purposely dense.
Whether one product or another--or even one product type or
another--has merit is an absolutely valid and valuable topic for
discussion in a public forum. The vendor who sells a meritless product
will no doubt wish that were not so and will naturally try to stifle
any such discussion.
> The very first posting to the
> newsgroup was in 1993 and titled "An OODBMS is....... ".
And if one actually reads that message, the author starts by observing
that the concepts were only beginning to evolve and basically
concludes at the outset that nobody knows what an OODBMS is. He then
proceeds to express his opinion of what it meant to him in 1993.
> You're suggesting that because "object" is in the name of the newsgroup,
> this is the place to trash OODBMS.
If one equates OODBMS products to network logical data model products
only, then it is only fair to point out the well-known deficiencies of
that logical data model. While inconvenient to some vendors, the
discussion is actually informative.
If one includes all dbms products that leverage the essential concepts
of objects in the definition of oodbms, then I have yet to see anyone
trash oodbms in this newsgroup. On the contrary, I have seen plenty of
vendors trash knowledge and education.
> You could also go to Burger King, yell
> that eating red meat is evil, then explain that you were just there for the
> french fries.
This is a usenet newsgroup and not a commercial enterprise. I agree
that entering a privately owned commercial enterprise only to badmouth
it misuses the commercial enterprise's property. Likewise, one limits
what one does or says in a person's home. Other appropriate places
exist for candid discussion that do not misuse anyone's property. A
public forum is exactly the appropriate place for candid discussion.
comp.databases.object is a public forum.
> There are other newsgroups that are perfect forums for pontificating about
> the virtues of The Third Manifesto.
Since nobody has pontificated, I observe that the above is nothing
more than a vendor's mudslinging to silence valid criticism.
If you bother to actually read the first message posted to this
newsgroup in 1993, you will see that it specifically references the
"Object oriented database manifesto" (sic). I would say that makes
this newsgroup the perfect forum to discuss any intellectual work that
explicitly responds to the "Object oriented database manifesto"(sic).
Wouldn't you?
Given that Date and Darwen wrote _The Third Manifesto_ as a response
to the "Object Oriented Database System Manifesto" (and in fact gots
its name from the two preceding manifestos of which the above is only
one: "The Object Oriented Database System Manifesto" and "The
Third-Generation Database System Manifesto",) I suggest this is
exactly the perfect forum to discuss _The Third Manifesto_ and the
important points it raises.
By suggesting otherwise, you are once again promoting ignorance as is
the wont of all the active vendors in this forum.
> You and Alfredo respond to just about
> any posting from OODBMS practitioners stating that OODBMS is nonsense
When one equates OODBMS to network model products only, as many people
do, then it is nonsense. The flaws of the network model are well
known, and it is only ignorance that perpetuates the market for these
flawed products.
> that
> the posters are misinformed or worse
In the case of vendors, such as yourself, the trend seems to be
"worse". The widespread misinformation of vendors' victims is not
really their fault. I find it only predictable that a vendor would
attempt to silence those who undo the misinformation they spread.
> and that the only true way to
> enlightenment is through The Third Manifesto and the relational model.
The only way to knowledge is through education and discovery. While
enlightenment can mean knowledge, it is a heavily overloaded word that
you obviously chose to mislead people into confusing knowledge with
religion. Shame on you.
> Nobody can stop you from doing this without starting a moderated group, but
> I think it's totally inappropriate. To simply respond to a question from an
> OODBMS point of view, one apparently has to re-justify the entire existence
> of OODBMS.
I disagree. If one wants to promote or to advocate the network logical
data model, one must accept the burden of addressing the well-known
flaws of that logical data model. We abandoned it thirty years ago for
very good reasons. To ask us to embrace it once again, you must
address all of those reasons. I know widespread ignorance makes things
convenient for vendors like yourself, but I don't care about the
convenience of vendors.
> There are certain premises that newsgroups tend to accept as part of their
> mandate
Given that the flaws of the network model have been widely known three
decades among database practitioners, I suggest one must acknowledge
those flaws as basic premises in any comp.databases.* newsgroup until
someone demonstrates solutions to those flaws or at least some new
compensating benefit to offset them. Pretending those flaws do not
exist amounts to ignorance and/or denial.
>, without which the newsgroup becomes useless
I suggest a public forum that prohibits candid discussion and that
operates in ignorance and denial is useless. At least, it is useless
as a public forum; although, I can see the value to salesmen and to
product marketers.
> People who aren't interested in getting caught in an off-topic flame war
> just to get a question answered get driven away.
I have never seen anyone asking a simple question get caught in a
flame war in this newsgroup. If the ignorant, malicious or duplicitous
insist on pushing their personal or commercial agendas ad nauseum, a
"flame war" may ensue, but nobody has to read such garbage. Certainly,
nobody asking a simple question has to participate.
If you succeed in silencing those who provide accurate, informed,
educated answers, those asking simple questions may never initiate a
flame war, but they won't get accurate answers to their questions
either.
> I'm sure this is a great
> satisfaction to you and Alfredo, but I think it's a shame.
I only infrequently get any satisfaction from helping people learn,
and I am sure vendors like yourself find it very frustrating to have
your misinformation debunked.
Bob Badour
Well Nobody,
While I am not a particularly suspicious person, I have to wonder at
the motives of anonymous posters who support the censorship of candid,
informed discussion in public forums in favour of the misinformed
double-speak of salesmen and marketers.
Do you honestly see the legitimacy of this forum only as an
advertising medium?
Bob
Paul DeWolf
> "Paul DeWolf" <pa...@thievesandkings.com> wrote in message
news:<nLvHa.4736$hz1.6752@sccrnsc01>...
> > "Bob Badour" <bba...@golden.net> wrote in message
> > news:oKuHa.32$5t5.6...@mantis.golden.net...
> >
> > > I disagree. The charter of the newsgroup seems clear enough from its
name,
> > > and my reply to the question described what I think that charter
covers.
> >
> > The charter of this newsgroup is obviously to discuss oodbms and ordbms
> > technology and solutions. This doesn't extend to a discussion of
whether or
> > not they should exist, any more than comp.databases discusses whether or
not
> > databases are a good or a bad thing.
> >
> > To argue otherwise is to be purposely dense.
>
> Whether one product or another--or even one product type or
> another--has merit is an absolutely valid and valuable topic for
> discussion in a public forum. The vendor who sells a meritless product
> will no doubt wish that were not so and will naturally try to stifle
> any such discussion.
I'm sorry, Bob. I was wrong. You weren't being dense on purpose.
> > The very first posting to the
> > newsgroup was in 1993 and titled "An OODBMS is....... ".
>
> And if one actually reads that message, the author starts by observing
> that the concepts were only beginning to evolve and basically
> concludes at the outset that nobody knows what an OODBMS is. He then
> proceeds to express his opinion of what it meant to him in 1993.
Yes, I read it and lots of others. You'll notice that it's mostly a bunch
of vendors discussing how to implement databases based on the o-o manifesto.
What a good, constructive idea. Far better than going on to
comp.databases.whatever and telling them that their models suck.
I don't mind if people in comp.databases.oracle or comp.databases.theory say
that OODBMS solutions are lousy and why they think so. I certainly wouldn't
jump in and start arguing with them, even if I thought they had their facts
wrong, especially if the topic wasn't about OODBMS in the first place.
> > You're suggesting that because "object" is in the name of the newsgroup,
> > this is the place to trash OODBMS.
>
> If one equates OODBMS products to network logical data model products
> only, then it is only fair to point out the well-known deficiencies of
> that logical data model. While inconvenient to some vendors, the
> discussion is actually informative.
To equate OODBMS products to "network logical data model products only" is
not only totally incorrect, it's not the subject of this or any other recent
thread.
> If one includes all dbms products that leverage the essential concepts
> of objects in the definition of oodbms, then I have yet to see anyone
> trash oodbms in this newsgroup. On the contrary, I have seen plenty of
> vendors trash knowledge and education.
To "include all dbms products that leverage the essential concepts of
objects in the definition of oodbms" is obviously not the purpose of this
newsgroup. That's for comp.databases. There's a reason that the "object"
subgroup was created, and it was obviously for OODBMS and ORDBMS.
> > You could also go to Burger King, yell
> > that eating red meat is evil, then explain that you were just there for
the
> > french fries.
>
> This is a usenet newsgroup and not a commercial enterprise. I agree
> that entering a privately owned commercial enterprise only to badmouth
> it misuses the commercial enterprise's property. Likewise, one limits
> what one does or says in a person's home. Other appropriate places
> exist for candid discussion that do not misuse anyone's property. A
> public forum is exactly the appropriate place for candid discussion.
> comp.databases.object is a public forum.
Being an ass in public is no better than being an ass in a privately-owned
public establishment.
> > There are other newsgroups that are perfect forums for pontificating
about
> > the virtues of The Third Manifesto.
>
> Since nobody has pontificated, I observe that the above is nothing
> more than a vendor's mudslinging to silence valid criticism.
>
> If you bother to actually read the first message posted to this
> newsgroup in 1993, you will see that it specifically references the
> "Object oriented database manifesto" (sic). I would say that makes
> this newsgroup the perfect forum to discuss any intellectual work that
> explicitly responds to the "Object oriented database manifesto"(sic).
> Wouldn't you?
No, I wouldn't. You'll notice that the poster didn't post to
comp.databases.oracle.
> Given that Date and Darwen wrote _The Third Manifesto_ as a response
> to the "Object Oriented Database System Manifesto" (and in fact gots
> its name from the two preceding manifestos of which the above is only
> one: "The Object Oriented Database System Manifesto" and "The
> Third-Generation Database System Manifesto",) I suggest this is
> exactly the perfect forum to discuss _The Third Manifesto_ and the
> important points it raises.
I wouldn't go to soc.religion.christian and assume that that's a good place
to argue the superiority of the Koran just because they mention the Bible.
It's only a perfect forum for you because it's a place for you to start
arguments.
> By suggesting otherwise, you are once again promoting ignorance as is
> the wont of all the active vendors in this forum.
>
> > You and Alfredo respond to just about
> > any posting from OODBMS practitioners stating that OODBMS is nonsense
>
> When one equates OODBMS to network model products only, as many people
> do, then it is nonsense. The flaws of the network model are well
> known, and it is only ignorance that perpetuates the market for these
> flawed products.
The market for our products has been perpetuated by success in applications
like Jim's and many others. Nobody buys Objectivity without building a
prototype and checking references.
> > that
> > the posters are misinformed or worse
>
> In the case of vendors, such as yourself, the trend seems to be
> "worse". The widespread misinformation of vendors' victims is not
> really their fault. I find it only predictable that a vendor would
> attempt to silence those who undo the misinformation they spread.
I don't mind disagreement, of which there's quite a bit between OODBMS
vendors. This newsgroup was created mostly by vendors to discuss how to
build good OODBMS products. I'm not a sales guy and I'm not here to sell
anything.
Like Jim, I have learned from your posts, but what I've said still stands.
Relational databases don't allow you to scope queries as well as an OODBMS
does. I don't think SQL could ever work well with an OODBMS and XQuery or
XPath may work better.
Apparently, other OODBMS people disagree, and I'm much more interested in
hearing their arguments than your vitriol against OODBMS technology.
> > and that the only true way to
> > enlightenment is through The Third Manifesto and the relational model.
>
> The only way to knowledge is through education and discovery. While
> enlightenment can mean knowledge, it is a heavily overloaded word that
> you obviously chose to mislead people into confusing knowledge with
> religion. Shame on you.
You come to this newsgroup pounding your manifesto, telling people that they
should should abandon their ignorant and evil OODBMS thoughts and
evangelizing what you think is knowledge but really is faith.
Much of religion is about presenting a model of behavior that's ideal in the
abstract, but is very hard to implement. Like religious tomes, your ideal
is also full of contradictions. They come up as soon as Date and Darwen try
to use an example. It's in the implementations that the contradictions and
holes become strikingly apparent.
There's nothing wrong with discussing the ideals from different points of
view, except that you're in the wrong group.
If you start a newsgroup dedicated to the implementation of the principles
of Manifesto 3, I promise not to post to it saying you're full of crap. You
can even insist on saying that OODBMSs are the same as network-model
databases and I'll let you have your way.
> > Nobody can stop you from doing this without starting a moderated group,
but
> > I think it's totally inappropriate. To simply respond to a question
from an
> > OODBMS point of view, one apparently has to re-justify the entire
existence
> > of OODBMS.
>
> I disagree. If one wants to promote or to advocate the network logical
> data model, one must accept the burden of addressing the well-known
> flaws of that logical data model. We abandoned it thirty years ago for
> very good reasons. To ask us to embrace it once again, you must
> address all of those reasons. I know widespread ignorance makes things
> convenient for vendors like yourself, but I don't care about the
> convenience of vendors.
I'm not asking you to embrace anything except possibly another newsgroup.
This newsgroup wasn't and isn't intended to sell OODBMS to you or Alfredo or
anyone else for that matter.
> > There are certain premises that newsgroups tend to accept as part of
their
> > mandate
>
> Given that the flaws of the network model have been widely known three
> decades among database practitioners, I suggest one must acknowledge
> those flaws as basic premises in any comp.databases.* newsgroup until
> someone demonstrates solutions to those flaws or at least some new
> compensating benefit to offset them. Pretending those flaws do not
> exist amounts to ignorance and/or denial.
Your suggestion is wrong. All models have flaws. All implementations have
flaws. Just like a preacher, you're expecting your congregation to confess
their original sin so that you can grant them redemption before they can go
on with their lives.
This isn't your congregation. You're not even in the right church.
> >, without which the newsgroup becomes useless
>
> I suggest a public forum that prohibits candid discussion and that
> operates in ignorance and denial is useless. At least, it is useless
> as a public forum; although, I can see the value to salesmen and to
> product marketers.
I'm sure people who post here simply to sell products will be slammed as
badly as I'm slamming you. Personally, I'd really rather discuss OODBMS
techniques with other OODBMS vendors, even though we probably wouldn't
agree.
I doubt a sales guy from our company has ever ventured anywhere close to
this newsgroup. Certainly not since I've been with them.
> > People who aren't interested in getting caught in an off-topic flame war
> > just to get a question answered get driven away.
>
> I have never seen anyone asking a simple question get caught in a
> flame war in this newsgroup. If the ignorant, malicious or duplicitous
> insist on pushing their personal or commercial agendas ad nauseum, a
> "flame war" may ensue, but nobody has to read such garbage. Certainly,
> nobody asking a simple question has to participate.
This very thread is an example. I was advised to ignore you as a troll, and
I should have taken that advice. I will take that advice in the future.
> If you succeed in silencing those who provide accurate, informed,
> educated answers, those asking simple questions may never initiate a
> flame war, but they won't get accurate answers to their questions
> either.
>
> > I'm sure this is a great
> > satisfaction to you and Alfredo, but I think it's a shame.
>
> I only infrequently get any satisfaction from helping people learn,
> and I am sure vendors like yourself find it very frustrating to have
> your misinformation debunked.
Paul
Kazuhiro Nakao
> superior to the relational logical data model, and logical data models are
> means of expression. The choice of logical data model has no impact on
> performance, per se; the physical storage structures determine performance.
> The choice of logical data model impacts only what one can express and how
> one expresses it.
The choice of logical data model does have impact on performance.
I've done various performance tests between relational databases
and object database. Result is, generally speaking,
when a query involves one table (class), there is no significant
difference.
when a query involves more than two tables (classes), the query
for object database is usualy 10x to 50x faster than the relational
one. This is because relationship between objects can serve as
"pre-computed" join and this type of query (for object database) can
take advantage of it.
--
Kazuhiro Nakao
Matisse Software Inc.