DB4O

Posts   
1  /  2
 
    
davisg avatar
davisg
User
Posts: 113
Joined: 27-Feb-2005
# Posted on: 08-Aug-2005 10:46:07   

http://www.db4o.com

I know this product is really going against the grain of LLBLGen and I don't want to upset anybody by mentioning it but if possible I do want to know what Fran's take is of using an object database over and above an O/R mapper such as LLBLGen? I am sure this question must have been asked at some point. Where are the pitfalls, seems to good to be true and most importantly where does LLBLGen shine above them.

Geoff

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 08-Aug-2005 11:09:08   

It's an OO database, not a relational database. This means that you don't have the power of a relational database available, so no dyn lists for example.

Frans Bouma | Lead developer LLBLGen Pro
Eric
User
Posts: 1
Joined: 09-Aug-2005
# Posted on: 09-Aug-2005 01:31:58   

Otis wrote:

It's an OO database, not a relational database. This means that you don't have the power of a relational database available, so no dyn lists for example.

The lack of dynamic lists is very minor issue when comparing object-oriented databases and O/R mappers. Imagine not having to update your database schema to handle a new permutation or derivation of a data object? Or using type-safe query syntax. Most O/R mappers don't even take advantage of the true power of relational databases. Why use a mapper when you can store/retrieve objects natively without having to go through the process of mapping each record into objects. Many times, objects require data from 2 or 3 tables which implies multiple queries per object.

Object-Oriented databases have many advantages and fewer drawbacks to relational databases when compared to O/R mapping systems.

sparmar2000 avatar
Posts: 341
Joined: 30-Nov-2003
# Posted on: 09-Aug-2005 07:09:27   

I believe that commercial reasons play a very large part in extensive use of RDBMS instead of OODBMS. There are a lot of business critical applications that currently heavily rely on Relational DB’s.

Until the likes of MS or Oracle ‘popularise’ OODBMS, we will continue down the current road using ‘tradition’ architecture.

20 years ago, the issue with OODBMS was cost, performance and query language (no SQL like) just to name the a few top reasons.

Seems to me that the cost issue might now have been addressed – just looked at the list price of db4o, but I wonder how it would perform in an enterprise environment.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 09-Aug-2005 09:43:13   

Eric wrote:

Otis wrote:

It's an OO database, not a relational database. This means that you don't have the power of a relational database available, so no dyn lists for example.

The lack of dynamic lists is very minor issue when comparing object-oriented databases and O/R mappers. Imagine not having to update your database schema to handle a new permutation or derivation of a data object? Or using type-safe query syntax. Most O/R mappers don't even take advantage of the true power of relational databases. Why use a mapper when you can store/retrieve objects natively without having to go through the process of mapping each record into objects. Many times, objects require data from 2 or 3 tables which implies multiple queries per object.

Oh, that's very true. Though that's just one side of the story.

Object-Oriented databases have many advantages and fewer drawbacks to relational databases when compared to O/R mapping systems.

... if you solely work with objects, but in a lot of applications, you have to use aggregated lists as well, things which are hard(er) to do with objects than with relational database based code. For example a list of orders and the 'companyname' from the related customer object. In theory, an OO database requires you to fetch both object types, as there is no concept of 'half an object'. Of course, oo databases implemented shortcuts for this, as some relational databases implemented shortcut for drawbacks of relational systems as well.

Frans Bouma | Lead developer LLBLGen Pro
JimFoye avatar
JimFoye
User
Posts: 656
Joined: 22-Jun-2004
# Posted on: 09-Aug-2005 15:53:18   

What happens when you have to write a report against an OO database?

JimFoye avatar
JimFoye
User
Posts: 656
Joined: 22-Jun-2004
# Posted on: 09-Aug-2005 17:43:27   

Also what about referential integrity?

I don't know a whole lot about OO databases, this is a legitimate question.

dvorme
User
Posts: 4
Joined: 10-Aug-2005
# Posted on: 10-Aug-2005 05:27:12   

Well, I contract for db4o part-time so I'll bite. simple_smile

JimFoye wrote:

Also what about referential integrity?

I don't know a whole lot about OO databases, this is a legitimate question.

An OO database lets you persist your .net objects as they are. Since it is impossible to have a reference to an object that has been previously deallocated in .net, this is not an issue. Basically, referential integrity is guaranteed by modern garbage-collected programming languages, so you get it for free.

Similarly, if you have an object containing a collection of other objects and set your reference to the parent object to null, assuming that nobody else holds a reference to the collection, it will automatically be deallocated for you. So you get cascading deletes for free too.

JimFoye wrote:

What happens when you have to write a report against an OO database?

Right now there's not a good way to do that with db4o using mainstream reporting solutions. We have investigated several solutions and are working on this. Basically we are looking at:

1) implementing a read-only reverse O-R mapper and a SQL driver so you can use your native SQL-based reporting tools on your native .net objects

2) implementing a replication bridge to nHibernate (I know that might be a dirty word around here) so you can easily replicate your object data into any arbitrary SQL database and report on it from there.

Of course we'd love feedback. simple_smile

Regards,

Dave Orme

dvorme
User
Posts: 4
Joined: 10-Aug-2005
# Posted on: 10-Aug-2005 05:34:48   

Object-Oriented databases have many advantages and fewer drawbacks to relational databases when compared to O/R mapping systems.

... if you solely work with objects, but in a lot of applications, you have to use aggregated lists as well, things which are hard(er) to do with objects than with relational database based code. For example a list of orders and the 'companyname' from the related customer object. In theory, an OO database requires you to fetch both object types, as there is no concept of 'half an object'. Of course, oo databases implemented shortcuts for this, as some relational databases implemented shortcut for drawbacks of relational systems as well.

Personally, I don't consider encapsulation to be a drawback. It has saved me from shooting myself in the foot a lot of times. :-)

And any modern data binding framework will automatically follow the references for you when you've got 1-1 or 1-M relationships in your objects, so as a practical matter, I haven't found this to be an issue.

For reporting, well, I answered candidly that we don't handle this as gracefully as we'd like to yet. Your thoughts on the matter would be helpful.

Best,

Dave Orme

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 10-Aug-2005 09:40:21   

dvorme wrote:

JimFoye wrote:

What happens when you have to write a report against an OO database?

Right now there's not a good way to do that with db4o using mainstream reporting solutions. We have investigated several solutions and are working on this. Basically we are looking at:

1) implementing a read-only reverse O-R mapper and a SQL driver so you can use your native SQL-based reporting tools on your native .net objects

2) implementing a replication bridge to nHibernate (I know that might be a dirty word around here) so you can easily replicate your object data into any arbitrary SQL database and report on it from there.

Isn't that thus the same as using a relational database with an O/R mapper: in some situations you use the database' native way of dealing with data, and in other situations you don't and need a conversion layer?

dvorme wrote:

Object-Oriented databases have many advantages and fewer drawbacks to relational databases when compared to O/R mapping systems.

... if you solely work with objects, but in a lot of applications, you have to use aggregated lists as well, things which are hard(er) to do with objects than with relational database based code. For example a list of orders and the 'companyname' from the related customer object. In theory, an OO database requires you to fetch both object types, as there is no concept of 'half an object'. Of course, oo databases implemented shortcuts for this, as some relational databases implemented shortcut for drawbacks of relational systems as well.

Personally, I don't consider encapsulation to be a drawback. It has saved me from shooting myself in the foot a lot of times. :-)

And any modern data binding framework will automatically follow the references for you when you've got 1-1 or 1-M relationships in your objects, so as a practical matter, I haven't found this to be an issue.

It will be if you have a lot of related objects to load. The example I gave is typical for a lot of applications. In a relational database, you can simply setup a list using a select statement and pull the data and show it, as we exploit in the TypedList feature. With objects, that's a little bit of a struggle, as your core element to work with is the object, not an attribute (entity field). So creating 'new' entities on the fly by a select statement isn't an option of an OO db. This doesn't have to be a problem per-se, but it can hurt in some areas. And not that little I'm afraid. simple_smile

Frans Bouma | Lead developer LLBLGen Pro
dvorme
User
Posts: 4
Joined: 10-Aug-2005
# Posted on: 10-Aug-2005 16:32:36   

Otis wrote:

dvorme wrote:

JimFoye wrote:

What happens when you have to write a report against an OO database?

Right now there's not a good way to do that with db4o using mainstream reporting solutions. We have investigated several solutions and are working on this. Basically we are looking at:

1) implementing a read-only reverse O-R mapper and a SQL driver so you can use your native SQL-based reporting tools on your native .net objects

2) implementing a replication bridge to nHibernate (I know that might be a dirty word around here) so you can easily replicate your object data into any arbitrary SQL database and report on it from there.

Isn't that thus the same as using a relational database with an O/R mapper: in some situations you use the database' native way of dealing with data, and in other situations you don't and need a conversion layer?

At the end of the day you want to be able to report on your data and you want to be able to manipulate objects inside your .net application. So in this sense, yes, it's the same idea.

dvorme wrote:

Object-Oriented databases have many advantages and fewer drawbacks to relational databases when compared to O/R mapping systems.

... if you solely work with objects, but in a lot of applications, you have to use aggregated lists as well, things which are hard(er) to do with objects than with relational database based code. For example a list of orders and the 'companyname' from the related customer object. In theory, an OO database requires you to fetch both object types, as there is no concept of 'half an object'. Of course, oo databases implemented shortcuts for this, as some relational databases implemented shortcut for drawbacks of relational systems as well.

Personally, I don't consider encapsulation to be a drawback. It has saved me from shooting myself in the foot a lot of times. :-)

And any modern data binding framework will automatically follow the references for you when you've got 1-1 or 1-M relationships in your objects, so as a practical matter, I haven't found this to be an issue.

It will be if you have a lot of related objects to load. The example I gave is typical for a lot of applications. In a relational database, you can simply setup a list using a select statement and pull the data and show it, as we exploit in the TypedList feature. With objects, that's a little bit of a struggle, as your core element to work with is the object, not an attribute (entity field). So creating 'new' entities on the fly by a select statement isn't an option of an OO db. This doesn't have to be a problem per-se, but it can hurt in some areas. And not that little I'm afraid. simple_smile

Whenever I create a new instance of a class, my constructructor automatically creates and populates the dependant objects. This is true no matter if I'm using an O/R mapper or if I'm using an OO database. So I don't see the pain here (or the difference).

The win from an OO database is that there is no mapping layer to maintain, fewer moving parts to break, and so on. So you can use your refactoring IDE to change your classes without worrying about if you broke the mapping to your database, for example.

Regards,

Dave

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 11-Aug-2005 10:58:32   

dvorme wrote:

(snip) Whenever I create a new instance of a class, my constructructor automatically creates and populates the dependant objects. This is true no matter if I'm using an O/R mapper or if I'm using an OO database. So I don't see the pain here (or the difference).

Well, the difference is that with the O/R mapper, you can leave the performance intensive stuff, reports and aggregate queries, over to the database system.

The win from an OO database is that there is no mapping layer to maintain, fewer moving parts to break, and so on. So you can use your refactoring IDE to change your classes without worrying about if you broke the mapping to your database, for example.

Interesting comment simple_smile . What I wondered after reading this was: what if I alter a class to remove 1 existing column and add 2 new ones. What happens to the data in the DB? IMHO it has to convert the data in the DB, so refactoring isn't free here, on the contrary.

Frans Bouma | Lead developer LLBLGen Pro
dvorme
User
Posts: 4
Joined: 10-Aug-2005
# Posted on: 11-Aug-2005 17:10:36   

Otis wrote:

dvorme wrote:

(snip) Whenever I create a new instance of a class, my constructructor automatically creates and populates the dependant objects. This is true no matter if I'm using an O/R mapper or if I'm using an OO database. So I don't see the pain here (or the difference).

Well, the difference is that with the O/R mapper, you can leave the performance intensive stuff, reports and aggregate queries, over to the database system.

Reports: once we have a SQL driver: no difference (as you pointed out previously).

Aggregate queries: Only to the extent that the OO querying tool in the OODBMS doesn't support it. Right now your criticsm would be correct. But there is no reason that an OO querying tool couldn't permit selection of specific object attributes, provide summary operations, etc. (We haven't had demand for this yet so we haven't added it yet, but we've spec'd out how some of this could work.)

The win from an OO database is that there is no mapping layer to maintain, fewer moving parts to break, and so on. So you can use your refactoring IDE to change your classes without worrying about if you broke the mapping to your database, for example.

Interesting comment simple_smile . What I wondered after reading this was: what if I alter a class to remove 1 existing column and add 2 new ones. What happens to the data in the DB? IMHO it has to convert the data in the DB, so refactoring isn't free here, on the contrary.

db4objects handles this for your automatically. The next time your database is opened, the deleted attribute will automatically be marked "deleted" in the database's internal schema and the other two will be transparently added.

The data in objects that are already stored will not be removed until you run an explicit defragment operation on the database. That way if you change your mind and put the attribute back on your object, you will get your data back too.

There are cases we don't handle, but native refactoring support is one thing our customers have really demanded, and so we're improving it every day right now.

Regards,

Dave

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 12-Aug-2005 09:45:37   

dvorme wrote:

The win from an OO database is that there is no mapping layer to maintain, fewer moving parts to break, and so on. So you can use your refactoring IDE to change your classes without worrying about if you broke the mapping to your database, for example.

Interesting comment simple_smile . What I wondered after reading this was: what if I alter a class to remove 1 existing column and add 2 new ones. What happens to the data in the DB? IMHO it has to convert the data in the DB, so refactoring isn't free here, on the contrary.

db4objects handles this for your automatically. The next time your database is opened, the deleted attribute will automatically be marked "deleted" in the database's internal schema and the other two will be transparently added.

The data in objects that are already stored will not be removed until you run an explicit defragment operation on the database. That way if you change your mind and put the attribute back on your object, you will get your data back too.

There are cases we don't handle, but native refactoring support is one thing our customers have really demanded, and so we're improving it every day right now.

Clever! simple_smile

Frans Bouma | Lead developer LLBLGen Pro
davisg avatar
davisg
User
Posts: 113
Joined: 27-Feb-2005
# Posted on: 12-Aug-2005 13:07:56   

Guys,

Many thanks for all your comments on this sensitive subject. It has been a very interesting read.

I for one is looking very closely at DB4O inline with my LLBLGen Pro projects mainly because of the refactoring of the DB. This is one area where it is going to help me out considerabily because my application will be written is such a way that new classes (objects) will be incorporated into the application on a request basis and therefore will persist into the database without me having to worry about providing database update programs to create new tables, etc...

Another reason is their client/server technology, it's built in! - Connecting to a database locally, LAN or WAN is so easy...

The reporting is not such a biggy either, I am using DevExpress and objects can be read into collections and binded to their reporting component. I have only tried this on a simple report though but it works.

Anyway, there are other reasons to look at it too but it's not really a subject I want to get too deep especially on Frans's space.

Geoff.

sparmar2000 avatar
Posts: 341
Joined: 30-Nov-2003
# Posted on: 12-Aug-2005 13:39:02   

Davisg, Before you close off this thread, do you have any figues on performance. How does a OO database perform again a relational db.

davisg avatar
davisg
User
Posts: 113
Joined: 27-Feb-2005
# Posted on: 12-Aug-2005 14:44:04   

sparmar2000 wrote:

Davisg, Before you close off this thread, do you have any figues on performance. How does a OO database perform again a relational db.

I haven't got any actual figures of my own but from the testing I have done on so far on determining whether or not DB4O is the right database for my project is looking very promising.

Using the embedded server mode is very fast and is where DB4O shines, client/server is slower obviously but by using careful user selections and paging this can perform quite well.

Like I said earlier I am considering DB4O over a traditional RDBMS because of it's database refactoring and built in client/server modes, speed is a consideration but from what I have seen so far it is pretty damn quick.

If you would like to look at some official benchmarks have a look here, these might help:

http://www.db4o.com/about/productinformation/benchmarks/

Geoff.

JimFoye avatar
JimFoye
User
Posts: 656
Joined: 22-Jun-2004
# Posted on: 12-Aug-2005 17:30:09   

What's the cost?

pilotboba
User
Posts: 434
Joined: 05-Aug-2005
# Posted on: 12-Aug-2005 19:36:05   

There is another database named "Cache" which is supposed to allow object based access and releational based access. Sort of a hybrid. Here is there speil:

"Caché is a post-relational database that uniquely offers three integrated data access options which can be used simultaneously on the same data: a robust object database, high performance SQL, and rich multidimensional access. No mapping is required between object, relational, and multidimensional views of data, resulting in huge savings in both development and processing time. Caché enables rapid Web application development, extraordinary transaction processing speed, massive scalability, and real-time queries against transactional data."

I played with is a while ago, but it just didn't work will with the tool I was using at the time, Visual FoxPro.

Here is the URL for those that like to spelunk:

http://www.intersystems.com/cache/index.html

BOb

JimFoye avatar
JimFoye
User
Posts: 656
Joined: 22-Jun-2004
# Posted on: 12-Aug-2005 20:30:45   

I don't get it. To work with this Cache you use ADO.NET? confused

davisg avatar
davisg
User
Posts: 113
Joined: 27-Feb-2005
# Posted on: 15-Aug-2005 10:21:46   

JimFoye wrote:

What's the cost?

Jim, it's on GPL license so it's FREE to use for your own development or in-house... Commercial license depends on volumes and would need discussing with their sales team but they are completely flexible.

One of the development applications I am writing will be targeted at the general public and will have a price tag of $50, I have discussed a royalty based license with them for which they are accomodating but it's expected to be no more than 7% and I will pay them post sale.

Geoff.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 15-Aug-2005 11:04:57   

Geoff, you're not leaving us, are you? wink

Frans Bouma | Lead developer LLBLGen Pro
davisg avatar
davisg
User
Posts: 113
Joined: 27-Feb-2005
# Posted on: 15-Aug-2005 13:08:31   

Otis wrote:

Geoff, you're not leaving us, are you? wink

Absolutely NOT, LLBLGen Pro is currently being used across 3 projects that I am building; all of which are high end transactional systems and I wouldn't use anything else for them. LLBLGen Pro is the bizz wink

DB4O is going to be used for another application in the making where it's database schema will change often and I want to take advantage of automatic refactoring of the database as well as it being light weight. Let me explain a little about the application:

It's basically going to be a hobbyist catalogue system in which you can store your music and movie collections but one thing I hate about other completitor software is that music is not just about storing CD's and LP's, many collectors also store information about Memorabilia like t-shirts, badges and even ticket stubbs, etc and this is not really taken into account. For example: When you store data you give each music entity a format code which is just a lookup table like CD, LP, 2CD and there will be one for T-Shirt. The problem is that most of the software and database is written is such a way that it thinks that every music item entered into the database has a track listing associated with it but we all know a T-Shirt doesn't have a track listing! - It's not just their UI, it's also their database table holding the music item that has a reference to a track listing.

So you might say, you can get around that by specifying in the format table whether or not the format has a track listing, right? Well, you are right of course but then you start down that road of having to create a lot of cross-reference tables to keep things properly abstracted. There are a lot of variations, LP's have a condition for the sleeve and the label but that information is redundant for non-vinyl.

What I wanted to do is to describe every characteristic of a music item as an entity and base the format code on that entity. So for example a Music DVD is completely different to a Movie DVD, Why? you may ask; well a Music DVD is associated with a Music Artist whereas a Movie DVD is not, they do however have region information. Another example would be a Music CD and a Music Classical CD, they both have track listings but a Music CD has an Artist associated with it and a Music Classical CD has a Composer, they are completely two different things when it comes down to describing the entity in full, it goes on and on and on.

Now back to why I am looking at DB4O for this. Well I am going to pre-build the classes for the Music/Movie entities that can be stored upfront, e.g. CD, DVD, LP, etc; all the well known ones and I will call them format types. Users will be allowed to request new format types whenever they like, all I have to do is create/modify the class, change the UI and redistribute the application. There is absolutely no database maintenance on my part.

Another good reason is that my application is truely pluggable from a database point of view. e.g. A user could be licensed for Music only but if later purchased Movies; all I have to do is open up the classes to the UI and the database will start storing Movie information automatically.

There are a couple of other reasons; built in client/server, same database works in .NET and JAVA.

Look forward to some comments. stuck_out_tongue_winking_eye

Geoff.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 16-Aug-2005 11:28:10   

Sounds like an interesting project, though what I wonder... aren't there like a gazillion different media + related ware storage/maintaining systems available already?

Frans Bouma | Lead developer LLBLGen Pro
davisg avatar
davisg
User
Posts: 113
Joined: 27-Feb-2005
# Posted on: 17-Aug-2005 10:31:44   

Otis wrote:

Sounds like an interesting project, though what I wonder... aren't there like a gazillion different media + related ware storage/maintaining systems available already?

For cataloging the actual music like MP3's, yes but there are not many good ones for cataloging music data. Although you will be able to attach MP3's to music items in my system, it is more geared towards people who want to just catalogue the collection for geekness, insurance purposes or compiling playlists. Another version of the product will also have seller functionality and will allow you to upload your collection into systems like e-bay for instance.

1  /  2