Comments on: Scalability and the Relational Model

By: andy

andy — Mon, 27 Sep 2010 12:04:51 +0000

I really loved reading your blog. It was very well authored and easy to understand. Unlike other blogs I have read which are really not that good. I also found your posts very interesting. In fact after reading, I had to go show it to my friend and she enjoyed it as well!

By: Thor Michael Støre

Thor Michael Støre — Mon, 15 Mar 2010 22:08:17 +0000

As long as it’s relational I’m satisfied to use it for the things I do for a living these days. It’s a solid theoretical foundation, and too much criticism seem to be levied against misapplications and misunderstandings of it. When used as the of a logical or conceptual view of reality for a database then it stands up on it’s own.

One peeve of mine is how changes to this “view of reality” are done in SQL. I don’t like being limited to just firing off a sequence of begin, insert, update, delete, commit/rollback commands. Only having the option of having a set of commands that are issued independently strikes me as “incomplete” somehow. I’d love a formalization of a more solid theoretical foundation for encapsulating the changes done to a database/”set of relations” as well as transaction management into a singe unit, and in practice end up with perhaps a command I use to feed data into like I can read it from a result set. “MERGE” is somewhat closer here, but it’s “not quite there” relative to what I’m thinking of.

Also:
“…mindset, which places the burden of computation on reads rather than writes.”
I can’t say I understand that one, I wonder if it doesn’t show the shortcomings in the critics mindset when they’re reasoning about what they’re criticizing, rather than in that of the proponents. The “burden of computation” is a physical problem, the relational model is a logical model.

For instance in the case of queries that can be sped up with a materialized view one really can do the computation on write or at some other time before the read and just dump out the data in question when it’s queried. There are ways to hide the materialized view and present a “100% relational(tm)” view of the database that can be queried as normal, so that just like adding an index will cause the database to jump to the requested row instead of doing a full table scan when querying, so will adding a materialized view cause the database to jump to the exact data the user needs even if the query explicitly orders for instance a “sum”, so it doesn’t violate the relational mindset either.

By: Jeff Davis

Jeff Davis — Tue, 09 Mar 2010 07:41:50 +0000

Ideally, you should be able to represent your data in relations even if it is stored in the format you describe.

Unfortunately, existing SQL systems almost universally assume “table = file”. That makes it difficult for you to store the data in the format which suits your needs, and still use SQL.

By: Jeff Davis

Jeff Davis — Tue, 09 Mar 2010 07:34:25 +0000

Great to hear. I’ll watch for the next announcement.

By: David Fetter

David Fetter — Tue, 09 Mar 2010 04:49:20 +0000

Good luck with that. You’re gonna need plenty.

By: Darren Duncan

Darren Duncan — Tue, 09 Mar 2010 01:45:17 +0000

I should be adding examples like that in around 2 months, after I’ve fleshed out a few more parts of my spec, since adding those parts would greatly affect how good any code examples would look. (The part I’m currently working on is adding type mixins/etc so that one can properly do things such as operator overloading, which would be a shameful feature to lack; should be out any day now.)

By: Jeff Davis

Jeff Davis — Tue, 09 Mar 2010 01:07:47 +0000

I have been casually following that for a while. Great work!

Last time I checked, I had trouble finding some “hello, world” type examples. It would be very nice if you had a simple primer for SQL person.

By: Pablo H. Reda

Pablo H. Reda — Tue, 09 Mar 2010 01:06:01 +0000

Hi Jeff,
It’s only my opinion, I not have argument, only code and vage sentences like “avoid joins and keep the data near”

By: Darren Duncan

Darren Duncan — Tue, 09 Mar 2010 00:38:38 +0000

Tutorial D is only intended to be an illustration of concepts, so of course it hasn’t replaced SQL, and wasn’t intended to. Mind you, Pascal was only intended as a teaching language, but then it went into production. Now if you mean by saying Tutorial D failed in that it hasn’t inspired other languages that are used in industry, then yes you are right so far, though I intend to change that with my “Muldis D”.

By: Darren Duncan

Darren Duncan — Tue, 09 Mar 2010 00:33:54 +0000

Regarding your #4, that is totally my intent with my Muldis D language, which I am actively developing now and filling in the last major omissions. And this is a completely serious and pragmatic exercise too. I am learning from all the past successes and mistakes I can get my hands on, in its development.