wagnerblog.com

Phil recently posted about object databases and, as it is frequently the case on his blog, the comments section included some great feedback. Among the replies was a note from Daniel who pointed to db4o.

Db4o is a relatively newcomer to the object database scene and as a company has an interesting business model. If you want to use the product in a non-commercial way, there are no license costs (GPL license). Thats pretty nice. Of course any commercial usage does require proper licensing and fees.

So whats my observation you say. Well, Phil got me thinking and somewhere between my second and third cup of coffee I had a small epiphany. Languages and data access technologies change at a much faster rate than data storage mechanisms.  There – thats it. You knew that already? I’m late to the party? Bummer! My grandmother had an old German saying for my incredible speed of comprehension:“ Wire was very cheap the year you were born”  – meaning I have such a long wire for thought processing it takes me longer than the average geek to arrive at the same conclusion.

OK enough kidding around. Those of us working with Microsoft tools have been indoctrinated to a new data access methodology every 18 months or so. Just when the collective wisdom of the programming hive had caught up with one version – here comes a new one! First there were dynasets, then there were recordsets, then there was ODBC, followed by RDO followed by ADO which sat on top of OLEDB followed by ADO.NET which is about to get a big infusion of change with ADO.NET 3.0. Don’t get me started on all the people that I see bashing stored procedures these days who in years gone by  argued endlessly that SP’s were the only way to deal with server databases and SP’s are faster than dynamic SQL etc etc. What Lemmings! .

In all those years with all those changes the basic foundation of data storage at MS has remained the same. The foundation of data storage follows the RDBMS model mentioned by Phil.

Yes we had a bit of a hiccup for a few years while desktop databases were trying to come close to what server based tools could do. In the end though instead of any desktop system moving up-market and getting a version of its engine that could compete on the server, it was the server based tools that moved down-market (i.e. MSDE). But underneath it all, even while throttled versions of the server product were being released, the basic mechanics of dealing with data remained the same.

Of course there was that other unfortunate detour a couple of years ago when every database vendor had to add some sort of XML capabilities to their product in order to remain competitive. And for a while there I worked with people who wanted nothing more than to put XML into the database and retrieve XML out of the database. Whew what a mess! Talk about having a hammer and everything looking like nails. It took several years for that detour to sort itself out. Even the Product Manager for SQL Server had to spell out in several interviews that the XML capabilities of the product were intended to assist in getting bulk data in and out of the system between disparate data stores, and were not intended as a wholesale replacement for the tried and true methods of data access that had been used for years. Some of that confusion of course based on Microsofts philosophy of never meeting a large customer it didnt like. Hence it attempts to cover all the bases and have a tool that can be used in any number of ways. Whenever the company is critiqued for a given approach the corp communication for years has been “Thank you for the feedback, but your way is just one of many many ways that we cover and hence we do what we do and you dont have the whole picture. You can’t possibly know what all of our partners and vendors want.”  Well, as developers we dont have to. We always look for the BEST way to accomplish a task and we expect our tool providers to do the same. Yes it can be difficult to determine the best way but you know something? When a company has billions in reserve – enough to buy entire countries of this world several times over, it does have the resources to find the best way. Period. That’s one of the things that allowed MS to beat IBM back in the day of the OS wars. But more and more MS is looking like General Motors.

The data storage technologies do not change as drastically as the languages and methods used to access it. I actually know a few programmers who turned into DBA’s because the rate of change was manageable in SQL Server.

I did notice a very interesting convergence that may get more coverage as time goes by. Take a look at the following query examples. Notice how the data in each case is retrieved via a code expression that, at least in the case of LLBLGen and Linq, gets turned into a proper SQL statement under the hood. The similarity is striking. So rather than attempting to address the object-table impedance by swapping out the backend, or diluting the market by introduing an “object sql server”  (bad move) , the smart money provides an engine on top of the database that is capable of overcoming the mismatch between relational structures and object structures. Lets face it folks, 99% of all data storage in this world is based on RDBMS systems. Nobody wants to throw away that investment. And as Phil also alluded to in his comments, you can always use newer tools to code against legacy data storage.

db4o
IList <Pilot> pilots = db.Query <Pilot> (delegate(Pilot pilot) {
return pilot.Points == 100;
});

LLBLGen
 _customerDS.FilterToUse =
      new RelationPredicateBucket(CustomerFields.Country == “USA”);

Linq
Northwind db = new Northwind(connectionString);
Customer cust = db.Customers.Single(c => c.CustomerID == “ALFKI”);