object databases
in [OOP]
|
From: H. S. Lahman on 1 Nov 2006 15:00 Responding to Sasa... > I posted this to comp.databases, but then it came to me that you guys > might provide some suggestions, sorry if this is an OT: > > So after years of using strictly relational databases, I've begun to > consider an alternative. Object databases seem compelling, especially > since the data in the project I'm mostly involved in is highly > hierarchical. So the questions: Actually, an ODBMS is not inherently well suited to hierarical relations. The OO paradigm is actually designed to eliminate them. OTOH, one can map something like a tree in either one through relationships. IOW, the Data Model looks the same for both: 0..* parent of [Node] ---------------+ | 0..1 | | child of | R1 | | +------------------+ > 1) When would you recommend ODBMS, and when RDBMS? If the relationships among tuples of data are complex and more naturally expressed directly between tuples, then and ODBMS is a better choice. For example, most road map applications use a ODBMS because every item usually has a host of fixed relationships to other items of different types AND the number of items involved in a specific relationship is usually a tiny subset of all the items. Perhaps more important, one always navigates the relationships in exactly the same way (i.e., the relationships are defined tailored to the problem in hand). An ODBMS will also usually be more efficient if you have a lot of navigation from the 1-side of 1:* relationships (which is also common in road map applications). An RDBMS is better suited to situations where relationships between tuples are fairly simple and the individual tuples are related in an arbitrary manner. An RDBMS shines in processing ad hoc queries where one cannot predict exactly what subsets of data will be accessed. For an online airline reservation system one has a relatively few relationships whose navigation can be optimized by a few indices in order to access arbitrary tuples in simple joins. Bottom line: an ODBMS works well when the data needs to be modeled for a very specific purpose or one routinely needs very complex join. Meanwhile an RDBMS works well when the data is accessed in an ad hoc manner and joins are relatively simple. > 2) Which ODBMS would you recommend? Sorry, I've only used one (ObjectStore) and that was many moons ago so I don't have comparative data. > 3) The application I work on is single user desktop application. The > data resides on the user's computer. Is there any ODBMS suitable for > this (something like equivalent to MSDE, Access, etc.). Is there any > "lightweight" object database suitable for this, or would you recommend > something else instead? If it is for a single application, that suggests that the data model can be tailored to a particular problem solution, which /might/ make an ODBMS a better choice. But it would still depend on how complex the relationships were and the nature of the joins. You can get ODBMSes for desktops, particularly the memory-mapped ones like ObjectStore that directly support persistence in OO applications fairly transparently. But they tend to be pricey. (An ODB engine, particularly a memory-mapped one, is inherently more complex than an RDB engine.) Note that a memory-mapped ODBMS has a downside for its convenience in managing persistence in an OO application. The application is littered everywhere with infrastructure statements that are specific to the ODBMS and that tends to marry one to a particular vendor. That is in contrast to an RDBMS where one can encapsulate the access mechanisms like SQL in a single client subsystem. ************* There is nothing wrong with me that could not be cured by a capful of Drano. H. S. Lahman hsl(a)pathfindermda.com Pathfinder Solutions http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman "Model-Based Translation: The Next Step in Agile Development". Email info(a)pathfindermda.com for your copy. Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php. (888)OOA-PATH
From: Frans Bouma on 2 Nov 2006 03:14 aloha.kakuikanu wrote: > Sasa wrote: > > I posted this to comp.databases, but then it came to me that you > > guys might provide some suggestions, sorry if this is an OT: > > > > So after years of using strictly relational databases, I've begun to > > consider an alternative. Object databases seem compelling, > > especially since the data in the project I'm mostly involved in is > > highly hierarchical. So the questions: > > 1) When would you recommend ODBMS, and when RDBMS? > > 2) Which ODBMS would you recommend? > > 3) The application I work on is single user desktop application. The > > data resides on the user's computer. Is there any ODBMS suitable for > > this (something like equivalent to MSDE, Access, etc.). Is there any > > "lightweight" object database suitable for this, or would you > > recommend something else instead? > > Are you aware that object databases failed miserably to gain any > acceptance? Hmm, what the conclusion of this trivial fact might be? > Use relational database always? > > There are numerous ignoramuses around (some with pretty loud names) > who would fight this obvious truth, but the fact of the matter is > that you as a computer developer professional just can't skip > fundamentals of data management class. And if you learn data > fundamentals, then you know why the concept of object database is a > misnomer. I don't see why the fact of not being widely accepted means that the technique is THUS bad. It's a niche, and within the niche they function very well. Fact is, relational databases have drawbacks too, which aren't present in OODB's. For example, working with objects in the code consuming the database's data is more efficient if you use an OODB as you then don't have to convert OO to relational and back. Of course, using an OODB has drawbacks as I described in my post in this thread, but if you don't run into them, which is often in a program which is targeting a niche or has specialistic features, an OODB doesn't have to be a bad choice. FB -- ------------------------------------------------------------------------ Lead developer of LLBLGen Pro, the productive O/R mapper for .NET LLBLGen Pro website: http://www.llblgen.com My .NET blog: http://weblogs.asp.net/fbouma Microsoft MVP (C#) ------------------------------------------------------------------------
From: Frans Bouma on 2 Nov 2006 03:23 H. S. Lahman wrote: > Responding to Sasa... > > > I posted this to comp.databases, but then it came to me that you > > guys might provide some suggestions, sorry if this is an OT: > > > > So after years of using strictly relational databases, I've begun > > to consider an alternative. Object databases seem compelling, > > especially since the data in the project I'm mostly involved in is > > highly hierarchical. So the questions: > > Actually, an ODBMS is not inherently well suited to hierarical > relations. The OO paradigm is actually designed to eliminate them. > OTOH, one can map something like a tree in either one through > relationships. IOW, the Data Model looks the same for both: > > 0..* parent of > [Node] ---------------+ > | 0..1 | > | child of | R1 > | | > +------------------+ In relational databases, storing hierarchies is one of the things which isn't very efficient, when you use the model you described. The thing is that you can't use a single select statement to get a subset of the hierarchy as SELECT isn't recursive and can't fetch adjacency lists in one go, it's set based, and this is a nested set oriented problem, so it can't be solved with a single select unless the datamodel is adjusted to get the nested sets out in one set oriented operation. So the model can't be the same. So in relational databases, other solutions are preferred. One is what I'd call the CELKO method: http://groups.google.com/group/comp.databases.theory/msg/25acd5da2a3110e 7?dmode=source Another one is to introduce a helper table with hierarchy information which can be joined into the set to get a single hierarchy out of the db. OODB's aren't used with SQL, they're used with an OO language so they don't run (necessarily) into this problem per se. FB -- ------------------------------------------------------------------------ Lead developer of LLBLGen Pro, the productive O/R mapper for .NET LLBLGen Pro website: http://www.llblgen.com My .NET blog: http://weblogs.asp.net/fbouma Microsoft MVP (C#) ------------------------------------------------------------------------
From: H. S. Lahman on 2 Nov 2006 12:06 Responding to Bouma... >>Actually, an ODBMS is not inherently well suited to hierarical >>relations. The OO paradigm is actually designed to eliminate them. >>OTOH, one can map something like a tree in either one through >>relationships. IOW, the Data Model looks the same for both: >> >> 0..* parent of >>[Node] ---------------+ >> | 0..1 | >> | child of | R1 >> | | >> +------------------+ > > > In relational databases, storing hierarchies is one of the things > which isn't very efficient, when you use the model you described. The > thing is that you can't use a single select statement to get a subset > of the hierarchy as SELECT isn't recursive and can't fetch adjacency > lists in one go, it's set based, and this is a nested set oriented > problem, so it can't be solved with a single select unless the > datamodel is adjusted to get the nested sets out in one set oriented > operation. So the model can't be the same. My point was that the ODBMS has no particular benefit for hierarchical structure over an RDB. Neither has any convenient mechanism for "walking" the tree or extracting it in bulk and the developer needs to tailor that explicitly. ************* There is nothing wrong with me that could not be cured by a capful of Drano. H. S. Lahman hsl(a)pathfindermda.com Pathfinder Solutions http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman "Model-Based Translation: The Next Step in Agile Development". Email info(a)pathfindermda.com for your copy. Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php. (888)OOA-PATH
From: AndyW on 2 Nov 2006 17:46
On 1 Nov 2006 11:14:11 -0800, "aloha.kakuikanu" <aloha.kakuikanu(a)yahoo.com> wrote: >Sasa wrote: >> I posted this to comp.databases, but then it came to me that you guys >> might provide some suggestions, sorry if this is an OT: >> >> So after years of using strictly relational databases, I've begun to >> consider an alternative. Object databases seem compelling, especially >> since the data in the project I'm mostly involved in is highly >> hierarchical. So the questions: >> 1) When would you recommend ODBMS, and when RDBMS? >> 2) Which ODBMS would you recommend? >> 3) The application I work on is single user desktop application. The >> data resides on the user's computer. Is there any ODBMS suitable for >> this (something like equivalent to MSDE, Access, etc.). Is there any >> "lightweight" object database suitable for this, or would you recommend >> something else instead? > >Are you aware that object databases failed miserably to gain any >acceptance? Hmm, what the conclusion of this trivial fact might be? Use >relational database _always_? > >There are numerous ignoramuses around (some with pretty loud names) who >would fight this obvious truth, but the fact of the matter is that you >as a computer developer professional just can't skip fundamentals of >data management class. And if you learn data fundamentals, then you >know why the concept of object database is a misnomer. I would suggest that before making what see as 'glorified hail mary' statements like that, you may like to try implementing a parts catalog (with diagrams) in an OO database and an RDB first. I will find it interesting to see how you handle the concept of parts diagrams within parts diagrams (schema within schema) to the n-th level. I would also find it interesting to see how efficient a distributed real time billing system would be for a large telco network that you would implemented using an RDB - something that is considerably difficult, even for a small telco only generating say 500 million call data records per day. |