From: Avi Bryant Date: 2005-03-26T05:54:49+09:00 Subject: Re: OO database concepts... 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