C. J. Date was kind enough to comment on my article in the last issue (February 2015) of the NoCOUG Journal (see The Rise and Fall of the NoSQL Empire). The full text of his remarks will be published in the next issue (May 2015). Here’s a sneak preview:

First, to say that a database (distributed or otherwise) is consistent merely means, formally speaking, that the database conforms to all stated integrity constraints. Now, it’s crucially important that databases always be consistent in this sense; indeed, a database that’s not consistent in this sense, at some particular time, is like a logical system that contains a contradiction. Well, actually, that’s exactly what it is—a logical system with a contradiction. And in a logical system with a contradiction, you can prove anything; for example, you can prove that 1 = 0. (In fact, you can prove that you can prove that 1 = 0 in such a system!) What this means in database terms is that if the database is inconsistent in the foregoing sense, you can never trust the answers you get to queries (they may be false, they may be true, and you have no way in general of knowing which they are); all bets are off. That’s why consistency in the foregoing sense is crucial.

But consistency in the foregoing sense isn’t necessarily the same thing as consistency as conventionally understood (consistency as understood outside the world of databases in particular). Suppose there are two items A and B in the database that, in the real world, we believe should have the same value. They might, for example, both be the selling price for some given commodity, stored twice because replication is being used to improve availability. If A and B in fact have different values at some given time, we might certainly say, informally, that there’s an inconsistency in the data as stored at that time. But that “inconsistency” is an inconsistency as far as the system is concerned only if the system has been told that A and B are supposed to be equal—i.e., only if “A = B” has been stated as a formal constraint. If it hasn’t, then (a) the fact that AB at some time doesn’t in itself constitute a consistency violation as far as the system is concerned, and (b) importantly, the system will nowhere rely on an assumption that A and B are equal.

Thus, if all we want is for A and B to be equal “eventually”—i.e., if we’re content for that requirement to be handled in the application layer—all we have to do as far as the database system is concerned is omit any declaration of “A = B” as a formal constraint. No problem, and in particular no violation of the relational model.