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?
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?
> 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
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? :-)
> 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 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? :-)
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).
On Fri, 25 Mar 2005 15:24:47 +0900, Asfand Yar Qazi <ay1...@qazi.f2s.com> wrote:
> 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? :-)
> 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).
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.
On Sat, Mar 26, 2005 at 01:56:53AM +0900, Austin Ziegler wrote:
[ 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.
-- "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
> 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 ?
> 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.
"Austin Ziegler" <halosta...@gmail.com> wrote in message > 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"
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.
<surrender...@remove-yahoo.it> 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. >> 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.
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 * halosta...@gmail.com * Alternate: aus...@halostatue.ca
On Sat, 26 Mar 2005 04:50:03 +0900, itsme213 <itsme...@hotmail.com> wrote: >> 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.
"Austin Ziegler" <halosta...@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 - 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?
On Sun, 27 Mar 2005 09:29:46 +0900, samuel_x_winter...@hotmail.com
<samuel_x_winter...@hotmail.com> wrote: > "Austin Ziegler" <halosta...@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 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.
"Austin Ziegler" <halosta...@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):
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?
On Mon, 28 Mar 2005 08:54:48 +0900, samuel_x_winter...@hotmail.com
<samuel_x_winter...@hotmail.com> wrote: > "Austin Ziegler" <halosta...@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.
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.
> 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
Maybe we need a way to combine double-entry bookkeeping, relational databases, and table-oriented programming !
On Tue, 29 Mar 2005 04:41:37 +0900, Bill Kelly <bi...@cts.com> wrote: > > 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 > Maybe we need a way to combine double-entry bookkeeping, > relational databases, and table-oriented programming !
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 ;)
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 :-)
|
