On the use of RA
Ok, I admit it. I was whining when I wrote Please tell me Relational Algebra is not dead. I've been using mathematics all of my life and have really tried to apply math where it is appropriate and ignore math where it is inappropriate (you heard it here first: scalper thinks it's OK not to use math sometimes). But time and again, I find myself in the presence of architects, designers and developers who walk with a swagger from their vast knowledge of .Net. Yet many don't even take the time to understand the fundamentals of the relational discipline. Competence in SQL is not competence in relational theory. Discovering new join syntax and testing performance by building new indices in your database is the equivalent of saying "I've washed my car's engine. I can't understand why it isn't running any better". Those that espouse normalization better be able to explain functional dependence, transitive dependence, the difference between third normal form and Boyce-Codd normal form and many other topics. I promise not to throw stones at anyone in particular. I'm just trying to hold people to a standard. Take the time to make yourself better at this stuff. Competence in relational theory solves real world problems.
When it comes to mechanical stuff, I'm basically pretty dense (say it: I like totally have no clue). I've never personally changed the oil in my car. I don't cut my own lawn, so I don't know much about lawn mowers (I've heard they use gasoline). I know water comes out of my sink, but if water comes out of something other than the faucet, i.e. a leak, I call a plumber. I know better than to try to maintain or fix something about which I know nothing.
The reason that I bring this topic to light is that there is great difficulty in managing data in the relational form. It is counterintuitive to the way most humans think. So when I hear about articles where someone has an opinion on how SQL should be changed without any corresponding approach in Tuple Relational Calculus (TRC), I just shake my head. Read "An Introduction to Database Systems" by Chris Date. It's been around for a while (I think its in it's 65th edition and 705th printing or something like that). If you are a math guy or gal, you may actually like TRC and use TRC to demonstrate insufficiencies in SQL.
Let's get back to the relational theory. Now call it what you want to, there is difficulty in the mathematics of RA and RC and the corresponding mathematics of OO. If you call it an "impedance mismatch" or work on "object-relational mapping", you are trying to solve a math problem, not a programming problem. There are a lot of viewpoints in the community on how to address these issues. The reality is, ORM through code-generation or other measures are really nothing more than stop-gaps. The language, i.e. the CLR, CTS, C#, VB.Net, all need to address this issue. I don't discourage anyone who is working on ORM as it solves real problems in real-world situations.
I found this post here from Wesner Moise that talks about this issue. In other words, the good folks at Microsoft are actually considering that data needs a better representation in the language. I even see the words "Relational Data" in the name of the PDC session title. The work that is done at MSR in this area may actually make it into the product at some point. I know that there is talk at MSR about the use of tuples in the language, but I haven't seen any evidence of whether that was in the context of a relation with full RA on the relation(s). Regardless of what those wacky guys at MSR are doing, the fate of the programming community is ultimately in the hands of the CLR and C# teams as they "make the call" on what is put in production.
Now before I'm I accused of being relational-happy or relational-centric, let me be clear. I am not. While the relational theory is my focus here, it is important to note that the Erik Meijer at MSR has an article here that Meijer, Schulte and Bierman (as mentioned in Mr. Moise's link) published some time ago (presented at the XML Conference and Exposition 2003) that discusses Xen, an experimental language, and the difficulties involved in the integration of XML data into the programming language.
I also notice "join calculus" is mentioned later in Mr. Moise's post. As he mentions, this is NOT related to relational theory, but is another process calculus. pi-calculus is another of the process calculi (pi-calculus and join calculus are separate and distinct disciplines, but both address distributed and mobile computing; BizTalk is based on pi-calculus albeit informally).
By the way, I should mention that " .Net Undocumented" has other useful information on this topic here and on other topics.