On Wed, 17 Jun 2015 22:05:12 -0700
Darren Duncan <darren at darrenduncan.net> wrote:
> I also believe the world is ripe to have SQL alternatives, its just
> a matter of ones appearing that are compelling to users for real work
> and not just an academic exercise. The fact we're still generally
> with SQL means this hasn't happened yet, but that doesn't mean it
> won't.
Yes, I've been keeping track of TTM-inspired projects, and tried to
convince Ingres to commercialize its D implementation. What makes
David's andl unusual is that it's a new language atop a DBMS that is
used in production.
Still, I'm not so sure the world is ready for a better SQL. The
evidence stands against, certainly. We already discarded one -- QUEL --
which hardly anyone remembers. A great deal of effort has gone into
replacing SQL with less powerful constructs with no theoretical
foundation, and into neutering the DBMS with ORM toys.
Do not underestimate SQL's enormous inertia and network effect.
Recognize that even if the syntax is better, engineering
challenges remain if the promise of fidelity to the relational model is
to be realized.
The inertia stems from laziness and ignorance, never in short supply. A
fraction of those who write SQL understand the math and logic
underlying it. Forums like Stack Overflow are rife with questions that
demonstrate as much; the answers are often not much better. If you're
not thinking in terms of relational algebra and are unaware of the
benefits of using logic to accomplish your task, changing syntaxes will
only compound your problems. If you *are* thinking in those terms,
it's still work to learn a new language. It's not clear that a better
syntax -- if that's all you get -- would be seen as a worthwhile effort
for very many people.
The network effect is important, too. The market recognizes knowledge
of SQL as a skill (even if it underestimates its value). That skill is
portable across jobs and DBMS implementations. It is a way that
programmers communicate to each other across the organization and
time. A new language has to clear a threshold of "better" to be
accepted.
There are two engineering challenges that come to mind: performance and
set-theory semantics.
As David outlines in his blog, it's no mean feat to swap out SQL from
any DBMS, including SQLite. Because the query language is
assumed/known to be SQL, query planning, rewriting, transformation, and
optimization is bound up in the grammar of SQL itself. Readers of this
list appreciate how much work goes into that.
Set-theory touches on the implementation, too. DISTINCT is
implied in andl. It was left out of SQL because it requires a sort.
The ramifications are nontrivial; consider joining on a nonkey and
counting the results. Also remember that SQLite violates even SQL's
set-theoretic features, such as when
update T set X = X + 1
fails if X is declared unique.
So I would say replacing SQL with andl or similar is in fact not
analogous to replacing Perl with Python or C++ with Go. The requisite
knowledge in the user community to appreciate the improvement is
greater (and relatively nonexistent). And the engineering effort to
build a DBMS is far more than to build a compiler.
There's a reason Larry Ellison can affort a yacht almost 500 feet
long.
--jkl
