Buu Nguyen's Blog

There are several interesting discussions at The Code Project regarding my article on db4o, I think it may be useful to compile those discussions into a blog entry so that those who missed the comments section at The Code Project can read.

Discussion between Marc Clifton and I
Marc:

Thank you for a well written and informative article!

On a philosophical note, I fundamentally disagree that this mismatch needs to be resolved. A schema represents the data from the perspective that is optimized for the database and is usually application neutral, while the object model represents the data from the perspective of the application-specific requirements. I often have to write several applications against the same database, and depending on what the application needs, the application object graph can vary considerably from the database schema. In fact, in many cases, there is no object graph for the schema because the data binds directly to the UI elements–an intermediate object graph is unnecessary. The translation between the UI’s display requirements and the schema is handled by virtualized views of the necessary schema elements.

Now of course, business rules are the exception, where the application is reading and/or writing the data. But again, I don’t feel that it is appropriate for the application-specific model to be directly associated with the schema. We use abstraction in programming to provide flexibility, and similarly, I feel a layer of abstraction between the application and the database is very useful. I achieve that using virtualized views (not actually SQL views, but views that are constructed on the fly when querying the associated tables as spec’d by the application-specific requirements). This gives me great flexibility, as it separates the underlying physical schema while keeping a layer of abstraction for the application-specific virtual schema. Both can vary independently of each other, which is very nice.

I’d like to see how such a thing (having a separation between the physical schema and the application-specific virtual schema) is possible with db4o or any of the ORM solutions.

Marc

Buu:

Thanks for your comments, Marc! I totally agree with your points and I would not say that you and I have any disagreement about the fact that there are cases in which the need for the separation between the data model and the application model exists. As I mentioned in one of my blog entry (in the Resource section, Part 2), RDBMS has the advantages of being portable across development paradigms (OO, non-OO) and applications, and that is something ODBMS cannot beat RDMBS.

db4o, as a native ODBMS, does not have a separate data model, instead the application model is stored and retrieved as-is. For that reason, it is virtually impossible for a db4o database to be shared by two or more applications at the same time, unless these applications use the exact same domain model (which I think is rare). If application portability is the goal, then db4o is definitely not the right choice. But if you only need a database to store your objects, esp. complex object graphs, and do not need to share that database with any other application now or in the future, db4o should be highly considered.

Finally, I think that if there is an ORM tool which can both provide an easy mapping mechanism to persist and query objects (e.g. no SQL, no HQL, no stored procedure, no mapping files, no primary/foreign key etc.) and fully enables the data model and application model to evolve independently (e.g. no constraint whatsoever enforced by the tools in any model), then we may not need ODBMS at all – since the O-R mismatch is now completely hidden by the mapping layer (in other words, the mismatch is there, and expected, but it is just hidden from application developers). Unfortunately, current ORM tools seem not to be able to completely resolve those two contradictory goals yet and they are bad in one way or another (or even both, EJB 2.x).

Marc:

Buu Nguyen wrote: it is virtually impossible for a db4o database to be shared by two or more applications at the same time, unless these applications use the exact same domain model (which I think is rare).

I would agree, and I appreciate your frankness.

Buu Nguyen wrote: then we may not need ODBMS at all

That’s essentially my position and the reason I developed Interacx (see sig).

Buu Nguyen wrote: Unfortunately, current ORM tools seem not to be able to completely resolve those two contradictory goals yet and they are bad in one way or another (or even both, EJB 2.x).

That’s my sense of the state of affairs, but unfortunately I’ve not had the time to dig deeply into any ORM product, I’ve only touched the surface reading through examples. I feel like ORM is trying to do too much. In my Interacx system, I use a very simple ORM (I’ve co-authored a couple articles about it) rather than embrace the complexity of mananging object relationships. The simple design emphasizes working with the view rather than the concrete tables, and is sometimes just an interface layer between the DB and the application’s representation.

Thanks again for your article. I like to keep my eye on ODBMS because I feel there definitely are valuable contributions that it can make. I’m just not sure what the best practices are.

Marc

Discussion between Carl Rosenberger and I
Carl:

> For that reason, it is virtually impossible for a db4o database
> to be shared by two or more applications at the same time, unless
> these applications use the exact same domain model

Actually we supply functionality exactly for this purpose: “Aliases”.

By creating aliases, you can map one class to another and work with objects of one class in an application as if they would belong to another class.

With this functionality we allow accessing the same database from Java and .NET, even though class namings differ, because the metadata of a .NET classname would also include it’s assembly name.

Here is a very simple example how to configure the use of such an alias:

Db4o.configure().addAlias(new WildcardAlias(
“com.f1.*, F1RaceAssembly”,
“com.f1.*”));

Thank you for your excellent article, Buu, it is a very good read!

Carl Rosenberger
db4o – database for objects
http://www.db4o.com

Buu:

Thanks a lot for your comments, Carl. I should have said that paragraph differently, since what I really meant was that it is either difficult or impossible to have two or more applications with different object graphs to share the same db4o database. Here’s why:

While Aliases is really cool feature and has its use in certain use cases, as far as I know, the stored type and the runtime type still need to have their attributes have the exact same names and types. As a result, in order to make use of Aliases, the two applications must have nearly identical object model (”nearly” because db4o will ignore missing or new attributes).

Now, I know with custom db4o object translators, we can somehow address the above issues, but the question is whether it is simple (or even possible) to perform translation between two or more complex object graphs which share the same data but are structured differently? Besides, currently I do not see how db4o can address use cases in which there is the need for a data model which is the *superset* of all data required by the applications running on top of it.

One of the reasons I like about db4o is that I do not have to do the tedious mapping work and can freely model my application in any way I want without being constrained by the O-R mismatch and the ORM tools. And that is possible because db4o stores the object model as-is, instead of having a separate schema definition for the data model. But that is also a drawback of db4o when coming to the application portability, the context in which I do not think db4o is currently the right tool for. Regardless, I am finding most of my projects do not fall into that specific context, and I am happily using db4o for them with a huge boost of productivity .

And of course, I would love to hear your thoughts on this.

Carl:

Hi Buu,

all you write is correct.

Indeed Aliases require classes to have very similar attributes to make sense.

Translators won’t work nicely for this usecase because of the way they are implemented.

I think it would be possible to do really wild transformations at db4o reflector level but I haven’t seen anyone do that yet.

Indeed db4o was intended for one-app-one-schema but there is no reason to stop thinking and designing here. Why should it not be possible to have “object views” or “class-to-class” mappings if people need that? I am sure that we will get to a stage where we will think about ways to supply such functionality.

Carl Rosenberger
db4o – database for objects
http://www.db4o.com

Buu:

Thanks for your feedback, Carl.

Why should it not be possible to have “object views” or “class-to-class” mappings if people need that? I am sure that we will get to a stage where we will think about ways to supply such functionality.

I don’t see why not, and it would be great if db4o can provide a simple mechanism to perform such custom mapping – there are obviously many use cases for such feature. Besides, while I think cross-application portability and nearly effortless persistence (as currently) are two contradictory goals, I really hope db4o can effectively address both of them in a future version. And you’re right, there is no reason to stop thinking and designing .

Keep up the good work in building such a great product!

A guy named Georani has a concern about data-binding
Georani:

There is an important thing missing in db4o for .NET:

There is no components to use with databinding in Windows Forms.

Developer Express XPO has the “XPCollection” and “XPView”.

LINQ has the “.ToBindingList” operator.

What is the better way to use databinding in Windows Forms with db4o?

Thanks

Buu:

Hi Georani,

For simple binding behaviors, you can either use the results of db4o queries directly as the data sources (note that IObjectSet implements IList) or simply convert them to BindingList objects for list management and change notification behaviors. For more advanced binding usages, either you need to write your own or consider the DB4OBindingList library, which implements both BindingList and IBindingListView and supports features such as paging, sorting, and filtering etc.

Thanks,

Buu Nguyen