OO database concepts...
Hal Fulton
used such a beast. In fact, I am not sure that OOD even exist
in the sense that I would like.
Here's one thing I'm thinking about...
When one class inherits from another, we take it for granted
that they are "type compatible." Anywhere a Mammal can be
used, we can specify a Dog. (Insert standard discussion of
duck typing here.)
I'm thinking of the usual paradigm where a table is an ordered
sequence of fields. Neglecting the methods (which is another
issue entirely), we can think of the fields as instance vars.
But if a have a database table of Mammals... I can't store a
Dog in it. Hmm. I think I wish I could?
And don't get me started on singletons. Basically, the traditional
relational model assumes a fixed set of fields; but Ruby makes no
such assumption. Even objects of the same class may have different
attributes and methods.
Would it make sense to create a database that modeled Ruby's
paradigm more closely? Am I talking nonsense?
Thanks,
Hal
Aredridel
Postgresql has some features like that: each class gets its own table,
essentially, but its members show up in parent tables:
CREATE TABLE mammals (
legs integer not null default 2
);
CREATE TABLE dogs (
fur varchar(255) default 'Long and dirty',
) INHERITS mammals;
insert into dogs(legs, fur) values (4, 'Silky smooth');
select * from mammals;
# => 4
There's quirks (bugs, I'd say) with IDs and such, but it's workable in
some cases.
Ari
Asfand Yar Qazi
There are loads of OO databases for that bloody 'J' language - but
none for any scripting languages! Not even for Python! I find that
utterly surprising. E.g. http://www.garret.ru/~knizhnik/perst.html
Perhaps Ruby needs to be the innovator in this field, shipping a full
file storage based OODBMS system with the standard library in the
future? :-)
vruz
> file storage based OODBMS system with the standard library in the
> future? :-)
There has been Aruna DB around for a while.
http://www.arunadb.org
Not sure how widely use it is, performance or quality of the codebase
ignored too.
It seems like it hasn't been actively developed lately. (but that may
be a good reason for someone to pick the project up if you happen to
like it)
If it's your current subject of research, maybe you can have a look at
it and tell us what you find.
cheers,
vruz
gabriele renzi
> There are loads of OO databases for that bloody 'J' language - but none
> for any scripting languages! Not even for Python! I find that utterly
> surprising. E.g. http://www.garret.ru/~knizhnik/perst.html
In pythonland they have a concept of OODB wich includes "atop", "zodb"
and something else. It does not seem to fit with what ODMG says is an
OODB, anyway.
> Perhaps Ruby needs to be the innovator in this field, shipping a full
> file storage based OODBMS system with the standard library in the
> future? :-)
maybe just a binding to GOODS :)
Avi Bryant
Hal Fulton wrote:
> I've been thinking about OO databases -- never having really
> used such a beast. In fact, I am not sure that OOD even exist
> in the sense that I would like.
>
> Here's one thing I'm thinking about...
>
> When one class inherits from another, we take it for granted
> that they are "type compatible." Anywhere a Mammal can be
> used, we can specify a Dog. (Insert standard discussion of
> duck typing here.)
>
> I'm thinking of the usual paradigm where a table is an ordered
> sequence of fields. Neglecting the methods (which is another
> issue entirely), we can think of the fields as instance vars.
>
> But if a have a database table of Mammals... I can't store a
> Dog in it. Hmm. I think I wish I could?
Hal, you're thinking too much in the relational model still. Real
OODBs don't have tables, they have graphs of objects, just like in
memory. They tend to use persistence by reachability, which means that
they have a defined root object, and any object that you can get to
from that root object - regardless of type - gets stored in the
database. The only "table" of Mammals would be if you hung an array of
them off of the root, and you could stick whatever you wanted in that
array. This means the database has to be strongly, dynamically typed:
each object record knows what its own class is, and thus which fields
it has.
Note that this makes it much harder for the database to do automatic
indexing the way RDBMS do. Depending on the OODB, you may well have to
take care of this yourself, making sure that you have appropriate data
structures so that you can access any object by traversing a minimum of
pointer references and using as few large objects as possible (it's
usually a good idea to use trees of some kind for lookup rather than
massive hashtables, for example).
Gabriele mentioned GOODS. That's a reasonable open source choice if
you want a large-scale networked OODB, although you have to be very
careful about performance because every object access goes over the
network. I've written client libraries for both Squeak and Python (on
contract) for this, and porting the same design to Ruby would be very
doable - although the lack of a real WeakReference implementation will
make performance suffer. If you're careful, you can achieve
cross-language data sharing with this (I've done simple demos of having
Java, Python, and Squeak all accessing the same object data).
The author of GOODS also has a simpler on-disk OODB called DyBase that
there are already Ruby bindings to, that you might want to take a look
at for smaller-scale projects.
If you have more questions about OODBs, my general advice is to find a
Smalltalker - for whatever reason, in the Smalltalk world they're still
the default industrial choice (often in the form of GemStone, but
that's an expensive package targeted at big business; some of the heavy
users are JP Morgan, Washington Mutual, and the OOCL container lines).
Cheers,
Avi
Austin Ziegler
> There are loads of OO databases for that bloody 'J' language - but
> none for any scripting languages! Not even for Python! I find that
> utterly surprising. E.g. http://www.garret.ru/~knizhnik/perst.html
>
> Perhaps Ruby needs to be the innovator in this field, shipping a full
> file storage based OODBMS system with the standard library in the
> future? :-)
There's no such thing as a good OODBMS.
Period.
-austin
--
Austin Ziegler * halos...@gmail.com
* Alternate: aus...@halostatue.ca
Glenn Parker
>
> There's no such thing as a good OODBMS.
>
> Period.
+1
--
Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoil.com/>
Austin Ziegler
There are three fundamental problems with OODBMSs -- and they stem
from the theory of OODBMS, not just the implementation. Avi just
pointed out the first -- the indexing on OODBMSs utterly sucks,
which means that the performance has to come from your object model,
whereas an RDBMS or ORDBMS can have additional indexing applied or
derived from how the application uses the data. The performance for
an OODBMS will therefore suffer far quicker than the performance for
an (O)RDBMS; this is due to the second fundamental problem.
Avi also suggests the second, but it's not clearly stated as a
fundamental problem: persistence by reachability. This specifically
means that they are very Pythonic: there's only *ONE* way to get at
a particular set of data. In a traditional RDBMS, you can access
data from many directions. Consider the typical example of "owned"
data, an order and its itemised details (e.g., the items on the
order). In an OODBMS, the only way to determine how many Widgets you
sold last month is to either (1) traverse the object graph for all
orders last month and visit the order details or (2) store the data
in both details and elsewhere, doubling your data storage for that
information. In an (O)RDBMS, you can simply query the order details
table without having to visit the orders themselves. This makes your
data much more accessible, and usable for ways that may not have
been envisioned by the original architects or designers. An OODBMS
locks you into a particular object model to access the data, leading
directly to the third problem.
Portability. If you need to change the object model at all in an
object database, you have to go through a full-scale migration of
the entire data store. In an (O)RDBMS, you have only to go through a
migration (and sometimes not even that) only on the tables affected.
If you want to change your OODBMS implementation, it's infinitely
harder than the already difficult problem of migrating (O)RDBMS
implementations.
OODBs are crap -- and always will be.
Doug Beaver
[ snip good summary of three fundmanetal problems of OODBMSs (hard to
index, rigid access paterns, poor portability) ]
> OODBs are crap -- and always will be.
the nice thing is that if you want to enforce a type hierarchy or
support different numbers of columns for a given class of objects, an
object-relational mapping layer will give you 80% of what the OODBMS is
giving you, without all the OODBMS baggage. "dynamic" columns are
pretty easy to setup with a RDBMS, as long as you don't mind reading in
multiple rows in order to recreate an object, along with a cheap join
against a domain table holding the column definitions. with modern
databases, it ends up being pretty fast.
i think ORM is already a de facto third class of database (as weird as
that sounds at first glance), and the ORM domain of solutions are only
going to get better at caching, prediction, and performance. i've been
working with hibernate lately and am pretty impressed with all the
optimizations it can make, my hand-coded database layers almost matched
its performance, and took literally dozens of hours longer to implement.
doug
p.s. i think the OODBMS manifesto is a good read, if anyone wants to
learn the motivations that led to creating them in the first place.
http://www-2.cs.cmu.edu/People/clamen/OODBMS/Manifesto/htManifesto/Manifesto.html
--
"Contrary to what most people say, the most dangerous animal in the
world is not the lion or the tiger or even the elephant. It's a shark
riding on an elephant's back, just trampling and eating everything they
see." -- Jack Handey
gabriele renzi
> Avi also suggests the second, but it's not clearly stated as a
> fundamental problem: persistence by reachability. This specifically
> means that they are very Pythonic: there's only *ONE* way to get at
> a particular set of data. In a traditional RDBMS, you can access
> data from many directions. Consider the typical example of "owned"
> data, an order and its itemised details (e.g., the items on the
> order). In an OODBMS, the only way to determine how many Widgets you
> sold last month is to either (1) traverse the object graph for all
> orders last month and visit the order details or (2) store the data
> in both details and elsewhere, doubling your data storage for that
> information. In an (O)RDBMS, you can simply query the order details
> table without having to visit the orders themselves. This makes your
> data much more accessible, and usable for ways that may not have
> been envisioned by the original architects or designers. An OODBMS
> locks you into a particular object model to access the data, leading
> directly to the third problem.
I think there is a need to clarify (at least for me, since I'm dumb and
I generally don't understand things).
There is one kind of things going under the name of OODB wich seem to
meet your description, but there is another one, the one advocated from
ODMG wich seem to collide.
For example, the Object Query Language seem to allow the same kind of
access to objects that you could get via SQL.
Also I'm not sure I understand: once you have access to the root object,
if you want to have different views of the data could'nt you just create
an object wich actually is this view ?
Glenn Parker
>
> There are three fundamental problems with OODBMSs
Maybe four. Austin mentions poor indexing, searching limited by
navigation, and resistance to change. I would throw in another issue
that may be more related to particular implementations, but so far I've
seen it in every OODBMS.
That problem is granularity of data access. With an OODBMS, the minimal
unit of access is the object. If your design needs large objects with
many fields, you get to load large objects all the time. With a RDBMS,
the unit of access is an arbitrary subset of columns in a row. The
impact of this difference on real-world performance can be orders of
magnitude, and there's little you can do other than redesign your system
from the ground up to make it more "compatible" with your particular
OODBMS's philosophy.
> OODBs are crap -- and always will be.
Ah, how do you _really_ feel? :)
itsme213
> Avi also suggests the second, but it's not clearly stated as a
> fundamental problem: persistence by reachability. This specifically
> means that they are very Pythonic: there's only *ONE* way to get at
> a particular set of data.
Is that true with queries (both OO method and OQL-like queries)? Indexes are
duplicate data whose coherence is maintained by the dbms. OQL surely allows
that?
> In an (O)RDBMS, you can simply query the order details
> table without having to visit the orders themselves.
Is that different from querying the extent of the OrderDetails class?
> This makes your
> data much more accessible, and usable for ways that may not have
> been envisioned by the original architects or designers. An OODBMS
> locks you into a particular object model to access the data, leading
> directly to the third problem.
>
> Portability. If you need to change the object model at all in an
> object database, you have to go through a full-scale migration of
> the entire data store. In an (O)RDBMS, you have only to go through a
> migration (and sometimes not even that) only on the tables affected.
> If you want to change your OODBMS implementation, it's infinitely
> harder than the already difficult problem of migrating (O)RDBMS
> implementations.
Have you considered Views? Relational views are of limited use (in some
domains) due to their data modeling limitations and view update problems.
Views in an ODB are richer, and can help localize schema evolution and data
migration.
And then again, the tradeoff looks quite different if you really need more
duck typing. Views can be helpful here too, as they let you say
"let's look at X as though it were a Y"
instead of only
"define X as a Y"
No silver bullet, I guess ...
Avi Bryant
Austin Ziegler wrote:
> Avi also suggests the second, but it's not clearly stated as a
> fundamental problem: persistence by reachability. This specifically
> means that they are very Pythonic: there's only *ONE* way to get at
> a particular set of data. In a traditional RDBMS, you can access
> data from many directions. Consider the typical example of "owned"
> data, an order and its itemised details (e.g., the items on the
> order). In an OODBMS, the only way to determine how many Widgets you
> sold last month is to either (1) traverse the object graph for all
> orders last month and visit the order details or (2) store the data
> in both details and elsewhere, doubling your data storage for that
> information.
I'm not going to address all of your points right now, though if you
like I can write some when I have more time, as someone who has done
major projects with both OODMS and RDBMS, about why I don't think the
issues are as clearcut as you're making them out to be. However, the
statement above is simply wrong. It doesn't "double your data
storage", because OODBs reference objects internally by ID, not by
value. Even if (as would be common) the details are referenced both
from the order and from some index elsewhere, the detail objects
themselves are still only stored once. It's like claiming that there's
"double the data storage" in an RDBMS because one primary key appears
as a foreign key in multiple other tables.
Yes, the indices themselves take up room, but I have no idea why you
would count this room for an OODB and not for an RDB. Are RDB indices
somehow magic, and take up zero space? Your OODB will be using exactly
the same kinds of data structures - BTrees, ternary search trees, etc -
that a relational database would, giving it very similar performance
and space characteristics, it's just that these structures are directly
available as part of the object model for you to introspect and tune to
your own needs, rather than hidden away as an implementation detail.
Yes, that's a tradeoff, but I'm not convinced it's one with an obvious
right answer.
Avi
Austin Ziegler
Five minutes ago, I knew nothing about OQL. Now that I know the
barest amount about OQL, I'm aghast that the OODBMS community would
come up with this bastardized SQL-like language that completely
misses the point of using SQL or any other relational(-like)
language. OQL does nothing to help with the fundamental problems
presented -- object databases are optimized for a particular access
path. That is, if I have:
class Order
attr_accessor :details
...
end
class OrderDetails
...
end
Under a relational database[1], these would be separate tables, so
that I could logically do:
SELECT COUNT(*)
FROM order_details
WHERE widget_no = 12345;
Under an active (in-memory) object model, an object database, or a
hierarchical database[2], the only way that I can find how many
12345 widgets have been sold is to traverse *all* of my orders --
*UNLESS* I keep the information separate, but I have then lost at
least some of the encapsulation that makes this model so useful in
most object cases.
Objects are not the most important thing about an application. It's
the *data* involved that's the most important thing about the
application. Objects are often an efficient[3] way of representing
that data for manipulation, but they are certainly not the only nor
always the best way to do this.
A good ORM like Og or ActiveRecord can make a huge difference in the
usability of an RDBMS for programmers who choose not to understand
the relational model. I've written custom ORMs for applications, and
they're not hard to deal with when you understand both your object
model and your data model -- and understand that your data model has
to have primacy, because the object model is application-specific,
while the data model is business-specific (and may cross several
applications, including many you have not yet even dreamt of doing
for a given set of data).
All that said, I'm quite impressed with what was shown regarding
PostgresQL's INHERITS feature. This seems like an idea that really
should be considered; it doesn't *quite* fit with RDBMS and
relational theory, but it looks very practical and usable. It should
be possible to emulate on Oracle with views and INSTEAD OF triggers.
> Also I'm not sure I understand: once you have access to the root
> object, if you want to have different views of the data couldn't
> you just create an object wich actually is this view ?
Um. Under an RDBMS, yes. Under an OODBMS, not really. Not without
duplicating data, which is evil.
-austin
[1] I tend to agree with the analysis, if not the stridency, of CJ
Date and Fabian Pascal. The SQL databases we have now are NOT
relational databases, but they are certainly usable and they are
orders of magnitude better for most problems than OO databases
or hierarchical databases will *ever* be. There are times
when a hierarchical database is appropriate; it's rare.
[2] An object database, really, is a specialised case of a
hierarchical database with a few features that make it nominally
possible to traverse the resulting object graph a bit more
freely.
[3] Efficient for the programmer more than the computer.
Austin Ziegler
>> Portability. If you need to change the object model at all in an
>> object database, you have to go through a full-scale migration of
>> the entire data store. In an (O)RDBMS, you have only to go
>> through a migration (and sometimes not even that) only on the
>> tables affected. If you want to change your OODBMS
>> implementation, it's infinitely harder than the already difficult
>> problem of migrating (O)RDBMS implementations.
> Have you considered Views? Relational views are of limited use (in
> some domains) due to their data modeling limitations and view
> update problems. Views in an ODB are richer, and can help localize
> schema evolution and data migration.
I think that you're looking at RDBMS from a while back. As I
understand it, both Oracle and SQL Server have solved the view
update problems, but in diffferent ways.
samuel_x_...@hotmail.com
> Five minutes ago, I knew nothing about OQL. Now that I know the
> barest amount about OQL, ...
Some relevant bits of OQL you seem to have overlooked are:
- Every class can have an extent and queries can start here
- Indices can be declared and automatically maintained
- Queries are declarative
- Query optimization exploits indices and object structure
So I'm having a hard time with the basis for some of your points. Could
you clarify which of the above items fall short?
Sam
Austin Ziegler
<samuel_x_...@hotmail.com> wrote:
> "Austin Ziegler" <halos...@gmail.com > wrote in message
>> Five minutes ago, I knew nothing about OQL. Now that I know the
>> barest amount about OQL, ...
> Some relevant bits of OQL you seem to have overlooked are:
> - Every class can have an extent and queries can start here
If I understand this ("extent" appears to mean something different
to the makers and unfortunate users of OO databases than it does to
the rest of the universe), this is dependent upon the design of the
database schema, whereas with relational databases, this is inherent
in the nature of the database concept. If one is going to go to the
effort of doing that much separation, then one is probably better
off with an RDBMS.
OQL can paper over this, to some degree, but it can't fix the
underlying problem that relational databases were invented to solve
because hierarchical databases *cannot* solve this.
> - Indices can be declared and automatically maintained
Fair enough. The objects can be indexed. That doesn't change that
object traversal is restricted by the folks who first implement an
object database schema. Trust me: they're not bright enough to do it
right. Neither are the people who first implement a relational
schema for a program, but it's far easier to manage the relational
schema and adapt it for alternative uses than an object database.
> - Queries are declarative
This is a meaningless statement. Please expand so that it has
meaning.
> - Query optimization exploits indices and object structure
Implementation detail, probably brought on because OODBs weren't
even remotely capable of competing against a proper RDBMS with a
good ORM.
> So I'm having a hard time with the basis for some of your points.
> Could you clarify which of the above items fall short?
I maintain that OODBMS are essentially hierarchical database
systems and that the performance for them outside of the precise
hierarchy in which the schema were defined will be questionable, at
best, without importing some relational database concepts. OQL is a
cheap imitation of SQL (which is a cheap imitation of real
relational database concepts, at that). I would question the sanity
of anyone who stores critical business data in an OODBMS, as they
pretty much require that the original implementers be brilliant at
all times. I know that I'm not.
I'll point to something else that Avi said: "if one is careful," one
can use a particular object database (GOODS?) both cross-language
and cross-platform. Sorry, but without being careful, I can use
pretty much any relational database cross-language, and many of them
cross-platform. This strongly suggests perhaps the biggest problem
with OODBMS: vendor lock-in is much stronger under an object
database than it will ever be with SQL databases.
-austin
Avi Bryant
Austin Ziegler wrote:
> Fair enough. The objects can be indexed. That doesn't change that
> object traversal is restricted by the folks who first implement an
> object database schema. Trust me: they're not bright enough to do it
> right. Neither are the people who first implement a relational
> schema for a program, but it's far easier to manage the relational
> schema and adapt it for alternative uses than an object database.
Austin, this seems to be the core of your point: that it's easier to
adapt a relational database to changing requirements than an object
database. You haven't presented any evidence for it, and I'd say that
in my personal experience precisely the opposite is true. Data
migrations have, in the applications I've built and maintained, been
less frequently needed and much less painful on OODBs than on
relational databases. If you have some rationale behind this
assertion, please present it, so that I can try to understand why your
belief or experience is so at odds with mine.
> I'll point to something else that Avi said: "if one is careful," one
> can use a particular object database (GOODS?) both cross-language
> and cross-platform. Sorry, but without being careful, I can use
> pretty much any relational database cross-language, and many of them
> cross-platform. This strongly suggests perhaps the biggest problem
> with OODBMS: vendor lock-in is much stronger under an object
> database than it will ever be with SQL databases.
You're misquoting me - GOODS happens to be very easy to use cross
platform, without any particular care needed; certainly easier than any
of the major relational databases I know. However, you absolutely do
need care to use it cross-language, and that is a major and very real
point in favor of using a relational database. If you need to support
multiple applications written in different languages with the same
data, a relational database is almost certainly the right choice.
Ditto if you want to take advantage of existing reporting tools like
DataVision. Ditto if you have SQL-savvy users and want to provide them
with ad-hoc query access to the database. Ditto if, for some reason,
you fear that you will have to change database vendors midstream.
There are, in fact, lots of great reasons for using relational
databases, and based on the needs of an individual project I often
recommend them to my clients. It's also true, however, that of the
three major projects I'm working on at the moment, all three of them
are using object databases. Why? Because for these projects, we're
getting better performance, easier migration, and faster development
time with an OODB than we would with an RDB.
Avi
samuel_x_...@hotmail.com
"Austin Ziegler" <halos...@gmail.com> wrote in message
> > - Every class can have an extent and queries can start here
>
> If I understand this ("extent" appears to mean something different
> to the makers and unfortunate users of OO databases than it does to
> the rest of the universe),
Perhaps you have a different notion of "rest of the universe", but it
is "extent" is certainly not a new concept, and entirely consistent in
ODBs.
In an ODB the OrderDetail class has an extent, which is the set of all
OrderDetail instances. The OrderDetail class also defines its
relationships. Here is a bit of the object schema definition (also ODMG
standards based):
class OrderDetail (extent Order_Details key ... )
{ attribute string quantity;
relationship Product product inverse Product::order_details
}
Your queries can start at the extent Order_Details, which is no
different from your cited example of SQL:
SELECT COUNT(*) FROM order_details
> this is dependent upon the design of the database schema,
> whereas with relational databases, this is inherent
> in the nature of the database concept.
Not true. If you have order_details as a table in an RDB your queries
can start there. If you have OrderDetail as a class in an ODB, your
queries can start there. Absolutely nothing advantageous inherent in
either model.
> OQL can paper over this, to some degree, but it can't fix the
> underlying problem that relational databases were invented to solve
> because hierarchical databases *cannot* solve this.
Very interesting claim. But an ODB is not a hierarchical database
(assuming your definition of hierarchical database is reasonably
standard).
> > - Indices can be declared and automatically maintained
>
> Fair enough. The objects can be indexed.
All interesting collections of objects can be indexed, including (but
not limited in any way to) class extents. Also, fyi, ODB collection
types include sets, bags, list, array, and dictionary (map).
> That doesn't change that
> object traversal is restricted by the folks who first implement an
> object database schema. Trust me: they're not bright enough to do it
> right. Neither are the people who first implement a relational
> schema for a program, but it's far easier to manage the relational
> schema and adapt it for alternative uses than an object database.
>
> > - Queries are declarative
>
> This is a meaningless statement. Please expand so that it has
> meaning.
Errr, I think you "it is a meaningless statement *to you*.
A query is declarative means that any logical expressions or paths used
to express a query are NOT necessarily the same as the paths traversed
to execute the query after the query is optimized.
This also means that there is *MORE* than one way to express the same
query, including more than one logical path traversal. Just as with
SQL. And contrary to your earlier claims.
> > - Query optimization exploits indices and object structure
>
> Implementation detail, probably brought on because OODBs weren't
> even remotely capable of competing against a proper RDBMS with a
> good ORM.
These are quite astonishing claims, and I don't see any real substance
to back them up. A "proper RDBMS" certainly does use query optimization
exploiting indices to gain performance and allow for different
formulations of the same query to be all executed efficiently.
> I would question the sanity
> of anyone who stores critical business data in an OODBMS, as they
> pretty much require that the original implementers be brilliant at
> all times. I know that I'm not.
Pretty strong statements.
If I can summarize your claims:
1. ODBs need more brilliant up-front definition than RDBs
2. ODBs don't perform like RDBs
3. ODBs are hierarchical
4. ODBs make data migration more difficult
5. ODBs make schema change more difficult
6. ODBs take an applications stovepipe view, RDBs are business view
7. ODBs are less cross-language than (SQL-based) RDBs
Certainly 7 is a valid point if your ODBs do not support some standard
like the ODMG (ODL + OQL). I have not seen any real evidence from you
about 1-6. Maybe you can help back these up?
Thanks.
Austin Ziegler
<samuel_x_...@hotmail.com> wrote:
> "Austin Ziegler" <halos...@gmail.com > wrote in message
>>> - Every class can have an extent and queries can start here
>> If I understand this ("extent" appears to mean something
>> different to the makers and unfortunate users of OO databases
>> than it does to the rest of the universe),
> Perhaps you have a different notion of "rest of the universe", but
> it is "extent" is certainly not a new concept, and entirely
> consistent in ODBs.
And as you've used it, it means something entirely different than it
does to the relational database world.
An extent in relational databases has nothing to do with the logical
structure of the database. It has everything to do with the physical
structure below the SQL layer -- it's something that *only* the
person who has to maintain the physical database layout need concern
himself with.
As I've said, "extent" appears to mean something entirely different
to users of object databases. Unfortunate, because it means that the
discussion becomes that much harder.
>> this is dependent upon the design of the database schema, whereas
>> with relational databases, this is inherent in the nature of the
>> database concept.
> Not true. If you have order_details as a table in an RDB your
> queries can start there. If you have OrderDetail as a class in an
> ODB, your queries can start there. Absolutely nothing advantageous
> inherent in either model.
Wrong. The advantage always goes to relational databases here,
because the access path is not constrained in any way *ever*. It's
always a problem when you design your data model to match your
object model, because I guarantee that your object model won't be
the right one for all applications, whereas a proper relational
model -- and I'll be the first to admit that a lot of people are
lazy and don't bother to understand what power the relational model
provides because it isn't covered well (if at all) in much of
computer science and is looked on with disdain by a lot of major OO
"leading lights", meaning that there's a lot of bad models out there
-- will be easily adaptable for pretty much any application you have
with it.
>> OQL can paper over this, to some degree, but it can't fix the
>> underlying problem that relational databases were invented to solve
>> because hierarchical databases *cannot* solve this.
> Very interesting claim. But an ODB is not a hierarchical database
> (assuming your definition of hierarchical database is reasonably
> standard).
Yes, they are hierarchical. If there's a root object, there's a
hierarchy. There might be additional entry points possible, but the
moment you have a root object, you have a hierarchy.
>>> - Queries are declarative
>> This is a meaningless statement. Please expand so that it has
>> meaning.
> Errr, I think you "it is a meaningless statement *to you*.
>
> A query is declarative means that any logical expressions or paths
> used to express a query are NOT necessarily the same as the paths
> traversed to execute the query after the query is optimized.
>
> This also means that there is *MORE* than one way to express the
> same query, including more than one logical path traversal. Just
> as with SQL. And contrary to your earlier claims.
In other words, object database vendors discovered that their
products were impossible to use and had to come up with a cheap SQL
knock-off without understanding the relational model in the least.
>>> - Query optimization exploits indices and object structure
>> Implementation detail, probably brought on because OODBs weren't
>> even remotely capable of competing against a proper RDBMS with a
>> good ORM.
> These are quite astonishing claims, and I don't see any real
> substance to back them up. A "proper RDBMS" certainly does use
> query optimization exploiting indices to gain performance and
> allow for different formulations of the same query to be all
> executed efficiently.
I'll be honest: I haven't played with an object database in several
years. Maybe the object database vendors have finally figured out
that they screwed up and implemented relational-like features. The
model for object databases is fundamentally wrong, however, and that
part won't change. You want support for that statement? Do a search
for "Fabian Pascal object databases." He doesn't have much good to
say about SQL database vendors, either, but he has absolutely
NOTHING good to say about the theoretical garbage that lies behind
object databases.
http://www.dbazine.com/codd.shtml
http://www.dbazine.com/pascal5.html
http://www.dbdebunk.com/page/page/1835439.htm
http://www.dbdebunk.com/page/page/1115004.htm
http://www.dbdebunk.com/page/page/1147345.htm
http://www.inconcept.com/JCM/December2003/pascal.htm
http://www.dbdebunk.com/page/page/806631.htm
http://www.dbdebunk.com/page/page/754911.htm
(The inconcept article is particularly good.)
Ultimately, my problem with OODBMS is that they *aren't* useful for
multiple applications accessing the same data in different
(sometimes contradictory ways), and my experience with data suggests
that no one is smart enough to get it right for all possible
applications of the data. SQL databases don't quite provide the full
power they should, but they're far better than anything remotely
hierarchical that requires graph navigation.
Bill Kelly
> lazy and don't bother to understand what power the relational model
> provides because it isn't covered well (if at all) in much of
> computer science and is looked on with disdain by a lot of major OO
> "leading lights", meaning that there's a lot of bad models out there
Maybe we need a way to combine double-entry bookkeeping,
relational databases, and table-oriented programming !
<grin>
SCNR,
Bill
Austin Ziegler
I understand the latter two quite well (well, SQL databases at least
;), although I call the last "data-oriented" programming. I'm not
quite insane enough to understand double-entry bookkeeping ;)
samuel_x_...@hotmail.com
Austin Ziegler wrote:
> And as you've used it, it means something entirely different than it
> does to the relational database world.
And if that were the "rest of the universe", you earlier sweeping claim
about "extent" would be right.
> Wrong. The advantage always goes to relational databases here,
> because the access path is not constrained in any way *ever*.
This would be truly amazing. In every RDB I have ever worked with,
access paths available to my queries have been 100% constrained by what
keys and foreign keys are defined in the schema. No different than OQL
access paths being constrained by relationships in the ODL. Oops, I
repeat myself ...
> It's
> always a problem when you design your data model to match your
> object model,
With a narrow preconceived notion of
object model = OOP view of one application logic
you would be right by definition. But that's an empty argument.
> lazy and don't bother to understand what power the relational model
Ummm. I'll resist :-)
> Yes, they are hierarchical. If there's a root object, there's a
> hierarchy. There might be additional entry points possible, but the
> moment you have a root object, you have a hierarchy.
The fixed root object in an RDB is the rdb. The fixed root object in an
ODB is the odb. Both give you ways to start from there. Both allow you
to go from there to tables (rdb) or class extents (odb) or individual
objects (odb). Seems pretty clear to me, but it's fine if you don't see
it that way.
> > A query is declarative means that any logical expressions or paths
> > used to express a query are NOT necessarily the same as the paths
> > traversed to execute the query after the query is optimized.
> >
> > This also means that there is *MORE* than one way to express the
> > same query, including more than one logical path traversal. Just
> > as with SQL. And contrary to your earlier claims.
>
> In other words, object database vendors discovered that their
> products were impossible to use and had to come up with a cheap SQL
> knock-off without understanding the relational model in the least.
Your rephrasings are remarkable. You may note (otoh, maybe not) that
very similar things could be said about the transition from RDB to
(O)RDB.
I notice too that you did not refute my observation that your earlier
claims about multiple traversal paths for RDBs and not for ODBs were
incorrect. Or refute my observation about query optimization.
And while O(RDB)s are certainly an improvement over RDBs, there is a
lot of FUD around how well the objects are integrated. For example, the
query machinery and optimizer, the indexing, etc. really don't know how
to handle the object types declaratively or invisibly to the user. And
object-related queries in SQL3 have been shown to be very error prone,
even to experienced SQL people.
But, of course, it's fine if you don't see those aspects. I have my
biases too :-)
Sam