object databases
in [OOP]
|
From: Alvin Ryder on 2 Nov 2006 21:49 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? > > Thanks, > Sasa All the projects I've seen that used OODBMS suffered badly. They solved their problems by switching to Oracle. Not sure if that's worth anything to you but I wouldn't rush into it and I certainly wouldn't believe what the "glossy brochures" say. Cheers.
From: aloha.kakuikanu on 3 Nov 2006 16:47 Frans Bouma wrote: > 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. Well, I never understood the so called "impedance mismatch" problem. Calling SQL from say java code is one of the easiest tasks in mordern programming. Getting results back is straightforward as well. What I also never has been able to grasp is why would you discard this simple idea lightly in favor of learning obscure 20 something mapping rules (TopLink). > 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. You have to tell what niche it is. Somebody mentioned bill of materials, but are they really familiar with hierarchical query facilities in SQL?
From: Frans Bouma on 4 Nov 2006 05:31 aloha.kakuikanu wrote: > Frans Bouma wrote: > > 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. > > Well, I never understood the so called "impedance mismatch" problem. > Calling SQL from say java code is one of the easiest tasks in mordern > programming. Getting results back is straightforward as well. What I > also never has been able to grasp is why would you discard this simple > idea lightly in favor of learning obscure 20 something mapping rules > (TopLink). that's simple. take the following small code snippet. using(DataAccessAdapter adapter = new DataAccessAdapter()) { adapter.SaveEntity(myCustomer); } this line of code saves: - the Customer entity instance myCustomer - its related Order entities - its related order detail entities - and other related entities to these. all in the right order, it syncs pks with fk's, it pulls back the new PK's from the db if the pk's are identity/sequenced, performs pre-/post save validation etc. etc. etc. effectively 2 lines of code. Now, tell me, you can do all that with 2 lines of code with SQL strings etc. ? No, you can't. Another thing: it's type save. CustomerEntity c = new CustomerEntity(); c.CompanyName = "MyCompany Inc."; c.ContactPerson = "Joe Smith"; //.. save the entity, using the mechanism of the o/r mapper, e.g.: c.Save(); // or: using(DataAccessAdapter adapter = new DataAccessAdapter()) { adapter.SaveEntity(c); } // or if your o/r mapper uses a central session/context: session.Attach(c); session.PersistChanges(); If something changes in the db, e.g. ContactPerson becomes Contact, it still works, OR your code breaks at COMPILE TIME, while your sql string misery breaks at runtime and turns into an unmaintainable nightmare. Take the example above even further: OrderEntity o = new OrderEntity(); o.OrderDate = DateTime.Now; OrderDetailEntity od = new OrderDetailEntity(); od.Price = 10.0f; od.Quantity = 1; od.ProductId = 10; o.OrderDetails.Add(od); CustomerEntity c = new CustomerEntity(); c.CompanyName = "MyCompany Inc."; c.ContactPerson = "Joe Smith"; o.Customer = c; Let's save the order, as that's what we're interested in: o.Save(); // or: using(DataAccessAdapter adapter = new DataAccessAdapter()) { adapter.SaveEntity(o); } // or whatever mechanism the o/r mapper uses. All entities have sequenced PK's. As we're saving the order, recursively, the customer has to be saved first, as order depends on customer. The graph thus has to be sorted, so a DAG sorting algo has to be used, taking into account which entities are affected by fk updates etc. The pk's have to be synced with the fk's relying on them, so when customer is saved, the pk it got of the sequence has to be synced with the fk in order, which then has to be saved and after that the order details, which receives the pk of order. All I did was write some typed, compile time checked code which is simple to follow, easy to update and maintain (!) and everything is taken care of. Can you do that easily with the same # of code I wrote? I doubt it, as sorting graphs and have pk-fk syncing isn't easy. So you've to build that into the code you write. But that will then be very fragile code as one change will perhaps break everything up and you've to reschedule all the saves and pk-syncs. I.o.w.: you're doing a lot of plumbing code which comes for free with an o/r mapper. That's the advantage of using a persistence layer which solves the impedance mismatch as it abstracts away the relational aspects of the persistant storage. > > 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. > > You have to tell what niche it is. Somebody mentioned bill of > materials, but are they really familiar with hierarchical query > facilities in SQL? an application without a lot of lists build from attributes of various entities is suitable for an OODB. 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: frebe73 on 4 Nov 2006 06:44 > > Well, I never understood the so called "impedance mismatch" problem. > > Calling SQL from say java code is one of the easiest tasks in mordern > > programming. Getting results back is straightforward as well. What I > > also never has been able to grasp is why would you discard this simple > > idea lightly in favor of learning obscure 20 something mapping rules > > (TopLink). > > that's simple. > take the following small code snippet. > using(DataAccessAdapter adapter = new DataAccessAdapter()) > { > adapter.SaveEntity(myCustomer); > } > > this line of code saves: > - the Customer entity instance myCustomer > - its related Order entities > - its related order detail entities > - and other related entities to these. > > all in the right order, it syncs pks with fk's, it pulls back the new > PK's from the db if the pk's are identity/sequenced, performs pre-/post > save validation etc. etc. etc. > > effectively 2 lines of code. > > Now, tell me, you can do all that with 2 lines of code with SQL > strings etc. ? No, you can't. But what about DataAccessAdapter? If it is a generic framework class I guess that you have to supply som O/R mapping descriptions that is longer than 2 lines. And there are numerous known problem with O/R mapping that limits the way you can use a RDBMS. If DataAccessAdapter is a custom class I guess you have a lot of SQL code inside it. And you didn't provide the Customer, Order and OrderDetail classes. Using a SQL-based approach, these classes are not necessary. > Another thing: it's type save. If you embedded SQL like SQLJ you will also get type safety. > CustomerEntity c = new CustomerEntity(); > c.CompanyName = "MyCompany Inc."; > c.ContactPerson = "Joe Smith"; > //.. save the entity, using the mechanism of the o/r mapper, e.g.: > c.Save(); insert into company (name, contactperson) values ('MyCompanyInc','Joe Smith') My SQL-based approach did it in only one line. > If something changes in the db, e.g. ContactPerson becomes Contact, it > still works, OR your code breaks at COMPILE TIME, while your sql string > misery breaks at runtime and turns into an unmaintainable nightmare. Use embedded SQL. > Take the example above even further: > OrderEntity o = new OrderEntity(); > o.OrderDate = DateTime.Now; > OrderDetailEntity od = new OrderDetailEntity(); > od.Price = 10.0f; > od.Quantity = 1; > od.ProductId = 10; > o.OrderDetails.Add(od); > CustomerEntity c = new CustomerEntity(); > c.CompanyName = "MyCompany Inc."; > c.ContactPerson = "Joe Smith"; > o.Customer = c; > > Let's save the order, as that's what we're interested in: > o.Save(); > > // or: > using(DataAccessAdapter adapter = new DataAccessAdapter()) > { > adapter.SaveEntity(o); > } insert into customer (companyname, contactperson) values ('MyCompany Inc', 'Joe Smith') customerid = insert_id(); insert into order (orderdate, customerid) values (now(), customerid); orderid = insert_id(); insert into orderdetail (orderid, price, quantity, productid) values (orderid, 10, 1, 10); Your solution is still more verbose than a SQL-based approach. > The pk's have to be synced with the fk's relying on them, so when > customer is saved, the pk it got of the sequence has to be synced with > the fk in order, which then has to be saved and after that the order > details, which receives the pk of order. This problem only exists when you use domain objects. A SQL-based solution has no problems with this. > All I did was write some typed, compile time checked code which is > simple to follow, easy to update and maintain (!) and everything is > taken care of. My code compile time checked, simple to follow easy to update and maintain. > Can you do that easily with the same # of code I wrote? I doubt it, Yes, but with less # of code. > I.o.w.: you're doing a lot of plumbing code which comes for free with > an o/r mapper. That's the advantage of using a persistence layer which > solves the impedance mismatch as it abstracts away the relational > aspects of the persistant storage. If you try to map classes to tables, you have an impedance mismatch. But if you map classes to datatypes (date, SSN, etc) the relational model and OO lives happy together. Fredrik Bertilsson http://frebe.php0h.com
From: frebe73 on 4 Nov 2006 06:54
> Well, I never understood the so called "impedance mismatch" problem. > Calling SQL from say java code is one of the easiest tasks in mordern > programming. Getting results back is straightforward as well. The major problem is that SQL statements are written as strings in Java. And in Java you can't write a string that spans multiple lines. You need use + operator or StringBuffer append. Even in languages with proper string features, the strings are not compiled until runtime. But embedded SQL is the solution to that problem. Unfortunately embedded SQL for java, SQLJ, is very rarely used. In other languages like COBOL or C it is much more common. > What I > also never has been able to grasp is why would you discard this simple > idea lightly in favor of learning obscure 20 something mapping rules > (TopLink). It is based on the misconception that the network model (object graphs) are better suited for data management, than the relational model (set theory and predicate logic). If you prefer object graphs, you need verbose O/R mapping. Fredrik Bertilsson http://frebe.php0h.com |