Relational people vs. object people

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 ), 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…

18 thoughts on “Relational people vs. object people

  1. Paul Wilson

    Some of us are equally comfortable in both worlds — I have used both models a good deal. So why am I a big fan of O/R Mappers lately then? Because I am building apps with languages and objects, and I simply want to get that task done — and O/R Mappers let me get to the heart of my app. On the other hand, some of my system occurs purely in the database as jobs that execute, and of course then I work with stored procs and such. So while its a nice theory that people fall into either the data or the language side, some of us just want to get our tasks done no matter what "side" it falls on. BTW, sorry for implying you actually meant we have to be on one side or the other, for I’m sure you did not — but I still wanted to make the point.

  2. Mike Gale

    Thanks for bringing this up in a useful way.

    I switch between "modes" fairly often, and I don’t find the change-over pleasant. I have to re-program myself between mindsets and it can hurt.

    This ties in with Joel’s observations that getting back into a moderately complex design takes time.

    I’ve never seen an analysis of this that is much use to me, but at least I know I’m not alone.

    Even if the changeover can be unpleasant, I wouldn’t want to be perpetually trapped in OO-land, relational-land, XML-land, IA-land etc. all the time.

    If you can get some useful model of the processes, you could produce really valuable changes in language/IDE design.

  3. Jackie Goldstein

    Hi Paul,

    I think you are right on – the "either-or" positioning is ridiculous. I always talk about tradeoffs and how you need to understand them and then choose what is right for your particular project.

    I am definitely perceived as someone who falls into the "dataset camp" and after my presentation on Data Access Strategies and Tactics (which talks about options and tradeoffs) at VSLive SF, an attendee approached me and started talking to me about (and asking me to explain!) Rocky Lhotka’s position – since he is generally perceived as falling strongly into the "object camp".

    I spoke to Rocky about this and he agreed with my analysis – he and I come from different experiences and typically work on different types of projects. This is what leads us to have different DEFAULT CHOICES for the data access model. However, we both realize that this is just the default and that different circumstances/requirements would lead us to choose the other option.

    BTW, I think that VS goes a long way to promoting this approach with the new Data tools is Whidbey. The technology and the message is clear – there is the same support for data binding, regardless of whether your data is coming from a DataSet or a custom object model (or Web Service). Just choose what make the most sense for you/your project.

  4. Alex Kazovic

    Hi Paul

    There are three comments I’d like to make.

    Firstly, as the C# team are also working on Comega, hopefully the two teams (VB & C#) won’t duplicate each others efforts. Instead each team can leverage the others work.

    The second point is related to database development in general and Access specifically. Every single business project I’ve worked on has involved database development/interaction. Therefore database development is an important constant subset of the work I do. To me Access is not a database, but a database development tool/environment that uses Jet as its default database. I.e. the purpose of Access is this subset of work I do. But overall I favour using VB.

    Access is a great productivity tool, but I like the extra control and easier extensibility I get in VB. Ideally, I would like to see the Access team become a part of the VB team focussing on the database side pf things; bringing their input with regard to productivity and usability. Additionally, I suspect there is a big overlap in the target user base for both products.

    Being realistic, politically there is no chance of this happening so I would like to see some resources on the VB team focussing solely on database development with the aim to making VB as easy to develop databases as Access. (BTW I looking forward to seeing the new reporting controls in Widbey and seeing how they compare to Access’s reporting engine [which is great].)

    Thirdly, as you mentioned working on Access’s query designer, I have to comment here. I have often used Access to do quick prototypes or relatively simple database systems and I really liked the query designer. This was a surprise to me as I consider myself an experienced developer who can quite easily write SQL statements. But I found I preferred dragging things around on a design surface rather than writing the statement. This was brought home to me when I had to do union queries or complicated sub queries; I missed using the designer.

    Looking back at the query designer, I now regard it as a Domain Specific Language for SQL. Especially in the context of the work being done at Microsoft on Software Factories and Domain Specific Languages. I think that work is very interesting, but I’ll leave my views on that for another time.

  5. yag

    Hi Alex,

    Just want to clear up a few misconceptions and make a few comments:

    1. The C# team is not working on C-Omega. That’s an MS Research item based on some prior work by a different team. The person who led that work is actually one of the folks Paul alludes to and is someone we’re working with on the VB implementation of data/language integration. The C# team is working on the issue as well – and we are *definitely* working together. In fact, it’s one of the more fun things that I get to help drive.

    2. I hope you let us know what you think of the SQL Reporting Services in Whidbey – my team and the VB team helped to make sure that happened because of our focus on data.

    3. It was great reading the props on the query designer and the thoughts of it as a DSL. I think of it that way as well. Part of my team wrote the code for that – and I’d love to hear how you think it can and should be enhanced.

    4. You mention about resources on the VB team being focused solely on data. Consider it done. My team is part of the RAD group in the Developer Division, along with VB and the Winforms team. That is our sole focus (which is why I had the 3 comments above).

    5. Finally, if you don’t check it out, add my team’s blog at to your reader. We’ll be having more on data/language, database design, etc., down the road.


    Group Manager

    VS Data

  6. RichB

    Let me start by being controversial:

    VB.Net is too professional. So, please simplify VB.

    VB.Net is too much like C# and as long as it parallels C# it will always be seen as a baby brother and therefore looked down at. It needs to focus more RADically on a different marketplace – that of the hobbyist programmer.

    A little history: VB began life as a scripting environment for Windows 2.0 Program Manager. It’s purpose was to allow end users to customize their desktop appearance using a simple tool with a simple language but powerful GUI. When Microsoft purchased it off Alan Cooper, out went the simple language and in came QuickBasic, but the original ethos was still there – it was a simple tool which enabled powerful results.

    IMHO, VB should return to those roots and target those end users who currently build their simple applications in Excel. Those Excel people write their applications after work sat at home. They don’t know SQL and couldn’t care – but they do know about lists and they do know about data. They don’t care about object oriented programming and large systems, because the largest system they’ve ever written took them 2 weeks working during the evenings. VB.Net is overkill.

    Just as JotSpot is focusing on the mass of small apps, so too should VB and leave the day-to-day programmers to migrate to C#.

    The best new bit of VB.Net was the Handles keyword – it couldn’t do everything the add{} and remove{} handlers in C# do, but it satisfied everything those hobbyist programmers needed. For VB.Net Orcas, please add more language features like Handles and forget about (indeed deprecate) the OO stuff.

  7. Alex Kazovic

    Hi RichB

    I agree and disagree with your comments.

    I agree that Microsoft seems to have focussed more on enterprise software lately and this has made it harder for the hobbyist programmer to get to grips with both .NET and VB. I also agree that VB should focus more on RAD/productivity.

    I disagree that VB should deprecate the OO stuff. I think that we can make VB more productive, lower the bar/learning curve for the hobbyist and keep OO.

    How can we do this? Firstly, I believe that being more productive is not just about writing less code. I think it should include:

    1. Ability to interact with a higher level abstraction (often a visual one)

    2. Write less code

    3. Cut down on maintenance

    4. Keep regression testing down

    It’s not JUST about writing less code; the other parts are just as important. E.g. the pattern and practises group has produced various application blocks. Let me say that this is a very good move, but doesn’t meet all the criteria above and therefore is a step forward but no a big one. I.e.

    1. There isn’t a higher level abstraction to interact with.

    2. By copying and pasting the developer does write less code.

    3. The maintenance is still mostly down to the developer

    4. No real help in cutting down on regression testing.

    If we take the big advances in VB such as the Visual part of VB it means all the above criteria. I.e.

    1. The user interacts by dragging an icon onto a design surface and changing values in a property sheet/grid.

    2. The IDE then generates code.

    3. The maintenance of the `components’ e.g. the textbox and the code generation is down to Microsoft and not the developer.

    4. If Microsoft changes the implementation of the textbox it is not necessary to regression test the textbox. Again that is down to Microsoft.

    To me the above actually qualifies as a Domain Specific Langue and that’s the direction that VB should head in.

    E.g. I think that Access is a great database development environment for the hobbyist, because it helps him/her do things quickly and easily. One example is that Access has a wizard to create a `switchboard’ form which is a main menu form with buttons to launch other forms. It’s easy to use even for an `inexperienced developer.

    I would like to see in VB some mechanism, either some menu option or icon in a toolbox that when activated shows a design surface. Then the user can drag a form from the Solutions Explorer on to it. The IDE can then add a button to a main menu form and generate the code (using the partial class feature) when the button is clicked to display the form. I realise that creating a main menu form is not the hardest thing in the world for an experience VB.NET developer, but for someone new to .NET is would be useful. Additionally, this can be a great learning tool as the developer can then look at the code that was generated.

    By taking this approach we can keep the OOness of VB, but hide/abstract a lot of it for the hobbyist.

    So I think that the VB team should look at common tasks perform by the hobbyist and then design a DSL to generate the VB code for that task

  8. Alex Kazovic

    Hi yag

    It’s good to get your comments.

    As for suggestions for the query designer, I’ve not been using it lately. The reason being that it’s tied to Access and I’ve been using VB.Net as the front end and SQL Server as the back end lately. Actually, this leads me to the first suggestion; make the query designer part of ,NET or VB rather than an Access thing. I would definitely start using it again then.

    My second suggestion related to the fact that I found it difficult to do nested sub queries in the query designer. It needs to be much easier to do nested sub queries. I found that to do nested sub queries I had to `cheat’ and do the sub query id a different instance of the query designer and then cut and paste the SQL statements back into the original instance of the query designer. It sort of worked, but wasn’t very good and I often made a mistake.

    As far as SQL Reporting Services in Whidbey, I haven’t had time to `play’ with it yet. When I do, I will give you feedback. BTW when referring to SQL Reporting Services in Whidbey I presume that includes the reporting controls that can work without a server.

  9. yag

    The query designer is in VS – just too hidden, I think. It should be more discoverable in Whidbey. Subqueries is on our radar – but not for Whidbey.

    And yes, it includes reporting controls that work in Winforms without a server.


  10. Alex Kazovic

    Hi yag

    I was looking for the query designer in VS 2003 and couldn’t find it. Where is it?


  11. Steve Davey

    RichB – Yeah, that’s right…cripple VB.Net and muck things up for those of us who do want to do enterprise level stuff <tut>.

    Alex. Sound like good ideas. Anything that means I do less work is great! ;o>.

    I do think MS should beware of concentrating too much on the hobbyist. You can always offer wizards for those who want a cookie cutter approach. If VB were (not that I imagine it will) to be aimed more at the P/T coder then it would lose a lot of credibility.

  12. yag

    You have a few options. The easiest in VS2003 is to create a database project, right click on the project and pick Add Query.


  13. Alex Kazovic

    Hi yag

    FYI Before you showed how to access the query designer I tried loading an existing project; then using Server Explorer selecting a server, database, and an existing stored procedure. I double clicked the stored procedure to edit it. This should the SQL statements. I expected that there would be some menu option to allow me to switch to the query designer; which there wasn’t (or at least I didn’t see it).


Leave a Reply

Your email address will not be published. Required fields are marked *