-

I disagree with what Rob's point of view. The main reason is that a relational database is much more than a series of tables: it has set based logic in store for you, which means you can form new sets from the existing ones, with attributes (columns, fields) from multiple sets.

If you strictly see the database as a box into which you can store objects (little boxes) then, yes, an OODB might be suitable. However, an OODB isn't going to cut it in many cases, simply because it's restricted to the world view of sets of boxes.

If you want a new set with Order.OrderId, Order.OrderDate, Customer.CompanyName, Sum(Sum(orderlines)), you have a rough time in an OODB.

So one either will avoid using that kind of logic altogether because it's not available (bad) or one will use it but then using an OODB is not really efficient (bad too). I.o.w.: why go this difficult route? Isn't it better to embrace the fact that the relational database is part of the application (and a big part as well) as that will make sure a developer isn't limiting him/herself and also in production stuff will be more efficient.

One of the reasons llblgen pro has typedlists for example is the fact that the world of data-access isn't about storing boxes, but about using sets and a set-oriented language (SQL). .NET is an OO environment and thus a conversion has to take place somewhere, but it's not about OO alone: by just closing your eyes and considering the database as an OO store too will make it less efficient to perform non-OO (but set-oriented!) operations on the data, ones which are necessary in almost any app (think lists, reports etc.)

-