On Mon, 28 Mar 2005 08:54:48 +0900, samuel_x_winters_x / hotmail.com <samuel_x_winters_x / hotmail.com> wrote: > "Austin Ziegler" <halostatue / 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. -austin -- Austin Ziegler * halostatue / gmail.com * Alternate: austin / halostatue.ca