A Call to Arms

A Call to Arms - Jim Gray, ACM Queue

"The really big news here is that these languages have also been fully integrated into the current crop of object-relational databases. The runtimes have actually been added to the database engines themselves such that one can now write database stored procedures (modules), while at the same time defining database objects as classes within these languages."

Big-time language lock-in.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Typical DB Sales Market Speak

The really big news here is that these languages have also been fully integrated into the current crop of object-relational databases.

Only one reason to put all this junk in the database => Speed. Yet, these languages will all be slower than Stored Procedures written in Transact-SQL. So, if speed is your number one concern, you won't see much point to converting over to a slower language. But then, if you knew that, why would spend spend a gazillion dollars just to rewrite the database procedures in C#?
such that all those design rules you were taught about separating code from data simply won’t apply any longer.
So you can now have your organization's data become as buggy as the software that you run. And have a churn rate of every couple of years. joy.

Darwen and Date respond

Here.

Never more welcome, in my view. I like, especially, Darwen's comment:

Relational database isn't a tradition; it's a theory.

Also of interest

Darwen's article on language design issues in SQL, which he says was "prompted by the appearance of 'A Call to Arms'", is worth a look. Money quote #1:

I question the competence in computer language design of the System R team. I do so by examining and criticising the design of SQL's notation for writing database queries. In spite of my strong words, I mean no personal offence to the members of that team, with some of whom I collaborated closely and was on very friendly terms during my time at IBM (1967-2004). Many of them were and are very fine software engineers, and Jim Gray in particular was one whose work (on locking) was of great help to me and my colleagues working on Business System 12 (1978-82). But an engineer does not a language designer make.