Re: Do we always have to update or insert? Why can't we just relate?

David Portas wrote:
> > But there is still the conceptual part of my question. Do we really
> > need insert and update?
>
> No. Relational assignment is all you need for updates, inserts,
> deletes. According to both Codd and Date an RDBMS should support
> relational assignment. A "D" language must support relational
> assignment - it's a requirement. SQL does not support it.

So, there are a few interesting questions here. One is, what is a minimal, complete set of operators? (In this case, update operators.) Another question is, what's a good design for a set of operators?

It's well-known that NAND by itself is a complete set of boolean operators. Every boolean function can be built using NAND (or alternatively NOR) exclusively. But is this a good design? Certainly not. I'd hate to use a programming language whose only boolean operator was NAND.

A better set is AND, OR, NOT, even though just (AND, NOT) and (OR, NOT) are complete. You might also want XOR for those rare occasions. What makes this a better design? It's because it allows you to more directly specify you intent. If you want to do something if either one of A or B is set, it's much clearer to say

  if (A OR B) {...}

than it is to say

  if ((A NAND A) NAND (B NAND B)) {...}

For updating, what is a complete set of operators? Assignment by itself is a minimal, complete set. Insert and Delete are also complete, but not minimal (since there are two of them vs. only one with assignment.) Update is also quite useful, but it doesn't add any to the expressive power. Since both (assignement) and (insert, update) are complete, you might not want to have both; SQL doesn't, and I must say that it doesn't seem to be a huge problem. Many programming languages don't have NAND, either, but they still manipulate booleans okay.

If I have a gripe with SQL's update operators, it would be that INSERT blows up if the row is already there. Why? I mean, you would certainly want to fail if there was already a different row with the same key, because that's clearly an error, but why if it's the exact same row? Nothing in error about that.

I blame cosmic rays.

Marshall Received on Mon Oct 17 2005 - 01:37:22 CEST