As we move towards Beta2 and are preparing for the headlong rush towards RTM (release to manufacturing), I’ve been lucky enough to be able to carve out some time to start doing some research for ideas that might show up past Whidbey. We’re not talking anything formal here, no feature lists or anything like that. Just the opportunity to spend some time noodling with some ideas on the whiteboard and fiddling with some prototype ideas. It’s one of the perks of having been around a long time – especially since most people on the team are still totally heads-down on shipping.
One of my areas of investigation has been the relationship between data access and the VB language and how we might allow people to work with data more effectively. This is an area with a lot of creative ferment going on, and I’m having the good fortune to spend some time working with people like Erik Meijer (one of the original authors of Cω), kicking new ideas around. In many ways, it’s a return to my roots – I started life at Microsoft on the Access team and worked a lot on the query designer generating SQL. So to get to go back and think about how to make data really easy to use is just a wonderful opportunity.
As I start to ease more back into thinking about data and data access, though, I find myself facinated by a schism between the data world and the language world that was not obvious to me back before I’d worked on either side of the divide. I find it kind of curious, but it seems to break down like this:
On the one side, it appears, are the database folks. Database folks usually cut their teeth designing databases and database products. They are extremely comfortable with the concept of normalization and prefer to deal with data stored in rowsets. Although they readily admit its limitations, they basically like the SQL language and feel that it is a very logical and powerful way of manipulating data. Their command of SQL allows them to slice and dice information in truly astonishing ways. In .NET, they prefer to work directly with datasets (maybe strongly-typed, maybe not), because that’s a very natural way for them to work and maps well to their domain knowledge.
On the other side are the language folks. Language folks usually cut their teeth working with programming languages and compilers. They are extremely comfortable with the concept of encapsulation and prefer to deal with data stored in hierarchical object models. They generally dislike the SQL language and feel that is a very poorly designed language, although they may envy its power. Their command of programming languages allows them to build astonishingly useful models of data that encapsulate large amounts of metadata. In .NET, they prefer to work with object/relational mappers, because objects is a very natural way for them to work and maps well to their domain knowledge.
The defining feature of this divide is that the guys in one camp tend to think that the guys in the other camp are crazy. (And, yes, I know, this is really a three-way battle, but I’m just leaving the XML guys out of it for now. Those guys are really are crazy.) It’s just another one of those religious debates, like case-sensitivity or curly braces, in which the extremists on either side espouse the One True Way, tossing hand grenades at the other side, and the moderates in the middle just try and keep their damn heads down.
This entry was sparked by Andy’s Conrad’s eminently reasonable thoughts on datasets. All he’s saying is something that seems completely obvious to me — sometimes relational is better, sometimes objects is better, it just depends on what you’re doing. And yet, it seems to me that this sort of pragmatic view of data is somewhat… lacking in some of the discussions of data access that I’ve seen elsewhere. Either it’s all O/R mapping and you’d be insane to want to work with your data in a relational way, or it’s all SQL and you’d be insane to want to work with your data as objects, and to heck with the idea that sometimes they’re just two great tastes that taste great together…
Anyway, it’s nice to be coming home a bit. More news when there’s something actually to talk about…