world” it is difficult to read coherently. The first paragraphs alone contain
more egregious misstatements than
most entire articles or papers. For
the record: “The raw physical data
model” is categorically not “at the
center of the [relational database]
universe.” Queries do not “assume intimate details of the data representation (indexes, statistics, metadata).”
While database technology relies on
“The Closed World Assumption,” this
assumption has nothing to do with
what the author apparently meant.
Every phrase in “Exposing naked data
and relying on declarative magic becomes a liability” relies on at least
one counterfactual. “Objects should
hide their private data representation, exposing it only via well-defined
behavioral interfaces.” But this is
exactly what the relational model
does—except (unlike OO) it adopts
an interface discipline that makes ad
hoc query and the like possible. “In
the realm of [data] modelers, there
is no notion of data abstraction.” Astoundingly wrong. “[Database technology necessarily involves] a computational model with a limited set
of operations.” False. Although the
(very powerful, well-defined, provably
correct) required set of relational operations is small, the sky’s the limit
on derived relational operations or
operations that define abstract data
type/domain behavior.
The author’s unfounded antipathy
toward relational databases domi-
nates even his application of CAP:
“The problem with SQL databases… is
the assumption that the data… meets
a bunch of consistency constraints
that is difficult to maintain in an open
[‘anything goes’?] distributed world.”
CAP does not eliminate this require-
ment; “…the hidden cost of forfeit-
ing [system-enforced] consistency…
is the need [for the programmer] to
know the system’s invariants.” 1 Nor
can programmers “…design their sys-
tems to be robust…to inconsistency.”
Once data inconsistency invades a
computationally complete system,
it is not even, in general, detectable,
and all bets are off. Consistency must
be enforced, hence constraints. The
author seemed to equate detecting
abnormal execution with enforcing
logical data consistency. No wonder
confusion abounds; CAP consistency
is single-copy consistency, a subset of
what ACID databases provide, yet the
Gilbert/Lynch CAP proof relies on lin-
earizability, a more stringent require-
ment than the serializability ACID da-
tabases need or use.
Coming Next Month in COMMUNICATIONS
Human Mobility
Characterization from
Cellular Network Data
Abstractions
for Genomics
Reference
1. Brewer, E. CAP twelve years later: How the ‘rules’
have changed. IEEE Computer 45, 2 (Feb. 2012),
23–29.
Computer Security
and the Modern Home
author’s Response:
The purpose of the article was not to
criticize the relational model but to point
out how building industrial-strength
systems using today’s relational database
systems requires leaving the ivory tower
and dealing with a morass of ad hoc
extensions to the clean mathematical
basis of first-order predicate logic. Rather
than depend on pure sets and relations,
developers need to think in terms of
(un)ordered multisets. For the sake of
efficiency and lock-contention avoidance,
transactions allow for various isolation
levels that clearly violate the ACID
guarantees of Platonic transactions. The
article also considered whether in the
new world of the Cloud we should view as
complementary computational models
that fundamentally address loosely
coupled distributed systems, like Carl
Hewitt’s Actors.
erik meijer, delft, the netherlands
What College
Could Be Like
Conference-Journal
Hybrids
Browser Security:
Appearances
Can Be Deceiving
The Web Won’t
Be Safe or Secure
Until We Break It
Condos
and Clouds
How Mechanical
Assemblies Work
Communications welcomes your opinion. To submit a
Letter to the Editor, please limit yourself to 500 words or
less, and send to letters@cacm.acm.org.
Plus the latest news about
side-channel attacks,
beyond hadoop, and
stealing others’ content.