Share via

C# and databases...

  • Article

I've been "a database guy" for quite a while. Way back in 1989, I left the security and blandness of Boeing for a new project a Microrim (of R:Base fame), which was building a new database solution (by "solution", I mean the whole shebang - server, UI, connectors to other databases, UI abstraction to run both on (hold on) OS2 and Mac).

As part of that job, I wrote the Query By Example part of the database front end (what we called a "surface"). If you've ever used Access or SQL enterprise manager, you've used QBE - you just get a table to fill in, and the system generates the SQL query under the covers for you. It's an interesting problem - it's fairly easy to represent everything from a QBE table as SQL, but going the other way is more problematic - there are some queries that just don't represent themselves well, even before you get to degenerate cases and inner joins.

Along the way I learned a fair bit about database design, normalization, and how to think like a database engine. This carried on to my later jobs, where I often chose a database as the best way to store information, and therefore I wrote a fair bit of data access code. As I moved into the object-oriented world, I wrote a fair number of what I'll call "class adapters" - classes whose purpose is to adapt between the database view of the world (rows and columns, with separate statements to query, update, or delete information) to the object-oriented world (classes with fields and methods to perform operations).

These classes aren't hard to write, but they are a bit tedious. How many times can you write something like:

m_name = (string) currentRow[NAME_COLUMN].Value;

or deal with the fact that string values in insert statements are quoted, but integers are not, without getting tired of it?

When Ado.net came out, I played around with it (not being a developer at the time, I didn't really use it). It does some neat things - strongly typed datasets, for example, but after using it for a few projects, I decided that it was a pretty big stick for the kind of stuff that I was doing. I didn't need disconnected datasets, I rarely (if ever) have written an editable grid, and I didn't like having to regenerate datasets every time I modified my schema. I also had a hard time keep track of all the pieces - queries, adapters, connections, transmissions, valves, condensors, centrifugal clutches, ultrasonic cleaners, etc.

So, I switched back to the tried and true:

execute query
while (result has rows)
{
    process rows
}

style of programming, but I wasn't fully happy with it. There was still - to use the terms Anders uses - a big "impedence mismatch" between the programming language world and the database world. There's a lot of improvement to be had, if a solution to the problem can be found.

A couple of years ago, the C# language design team started talking about whether there was something that could be done at a language level, and I got to participate in that discussion for around 9 months. The coolest part of the plans are that...

Well, I can't really tell you. Partly because I'm not the person to talk about the details, but mostly because I've been away from the language design team for nearly a year now, so I'm not sure where the discussions led.

But I know who can tell you. The members of the team will be speaking about what may be in store for C# 3.0 at the PDC.

If you can't make it to the PDC, I'll try to link to documents as they become available, or you could just wait for Luca to post them

Comments

  • Anonymous
    August 02, 2005
    Eric, Do you know if the C# design team is soliciting input for C# 3.0, or whether they are primarily developing the ideas internally? I would really like seeing some of the design discussion brought out into the public, so that we C# users can provide some input. Thanks!
  • Anonymous
    August 02, 2005
    I've heard and read on MSDN blogs that peices of <a href="http://research.microsoft.com/Comega/">Cω</a> (Pronounced C omega) will be used to address data access issues at the language level.

    I also agree about the problems you discussed, Typed DataSets are very nice but they're also overkill. Using a foreach() model to access data isn't as elegant and easy to read. Something needs to be done at the data level.

    I'm not very familar with FoxPro, but everytime I read about Cω I always hear people referring to "Oh, thats how FoxPro did it, MS is going back to how FoxPro did it".

    Although this may or may not be true, who cares? If they can improve the way we access data I'm open for anything.
  • Anonymous
    August 02, 2005
    Eric,

    Interesting that you worked on the Rbase stuff. I work for a small 2-man product-based company that supplies applications to the government sector. While most of our customers use SQL Server now, all 3 of our VB6 windows apps are built to work against Rbase 6.0, in addition to SQL Server and Oracle. We have several customers still using Rbase as the backend and it really is a testament to Rbase that it all still works well.

    My boss still loves and uses Rbase 6.0 for a lot of his database design and he swears by the old R> prompt.
  • Anonymous
    August 02, 2005
    ahhh... you surfaces guys had all the fun. Us GUI layer guys had to write a generic editable grid control with the spec. of "make it work like Excel". Perhaps this explains why Vanguard never shipped (extra credit trivia: what MS building # did Microrim HQ become?).

    A short comment on databases in C#, as hinted by the earlier comment, it seems like X# (or whatever its called) will go a long way by simply adding the concept of sequences and tuples into the C# grammar. But the real question is what if there was no impedence mismatch? What if you could like, have a C# app with seemless embedding of SQL and XSD? Could this be a case of being careful what you ask for? A Frankenstein in code?

    As for myself, I found that I could actually get quite a lot of "relational mapping" handled by implementing custom attributes and using reflection. With these features C# gives just enough syntactic niceness to rough over those honed relational database programming edges.
  • Anonymous
    August 03, 2005
    The comment has been removed