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

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.

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.

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.

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.

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

Also what about referential integrity?

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

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

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.

Regards,

Dave Orme

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

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.

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.

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

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 . 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.

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 . 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

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 . 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!

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.

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

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.

What's the cost?

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

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

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.

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

Otis wrote:

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

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

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.

Geoff.

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

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.