Databases Reference
In-Depth Information
A Psychological Mistake?
Let me focus on SQL specifically for a moment. The fact that, in SQL terms, views are
supposed to look and feel just like base tables as far as the user is concerned suggests rather
strongly that the syntactic distinction between CREATE TABLE and CREATE VIEW was
always at least a psychological mistake. First of all, that keyword TABLE in CREATE TABLE
refers to a base table specifically, thereby (most unfortunately!) lending weight to the widespread
perception in the SQL world that views are somehow different from tables. To elaborate on this
point briefly: As is well known, SQL documents—textbooks, product manuals, and indeed the
SQL standard itself—all talk quite typically (fairly ubiquitously, in fact) in terms of “tables and
views.” But clearly, anyone who talks this way is under the impression that tables and views are
different things, and probably that “tables” always means base tables specifically, and probably
also that base tables are physically stored and views aren't. But the whole point about a view is
that it
is
a table (or, as I would prefer to say, a relvar); hence, we should be able to perform the
same kinds of operations on views as we can on regular relvars, because views
are
“regular
relvars.” Throughout this topic, therefore, I'll use the term
relvar
to refer to relvars in general—
and if I want to talk about base relvars specifically or views specifically, I'll use the appropriate
more specific term.
The second part of the mistake is this: The syntax of CREATE VIEW in SQL is such that
the mapping between the view in question and the table(s) in terms of which it's defined—in
other words, the pertinent view defining expression—is explicitly stated as part of the view
definition. That mapping is thus explicitly visible to users who are exposed to that CREATE
VIEW statement, despite the fact that those users have no logical need to see it (the mapping,
that is). Ideally, in fact, they shouldn't be aware of it at all. One consequence is that users
typically do know among other things that the view in question is indeed a view; more generally,
they typically do know which tables are base ones and which ones are views. The problem is
compounded by the fact that, ironically enough, the
structure
of the view, which users do need to
be aware of, isn't explicitly defined in CREATE VIEW but has to be inferred from the mapping!
(By
structure
here, I mean the names of the columns of the view and their corresponding data
types—in other words, the heading—but
heading
isn't an SQL term. In fact, SQL doesn't seem
to have a term for the concept at all.)
Now, lest I be accused of attacking SQL unfairly here, let me make it clear that the
foregoing criticisms all apply, mutatis mutandis, to
Tutorial D
also (at least in its present
incarnation). Let me also make clear what I would regard as an adequate fix for these problems:
First, relvar definitions as perceived by the user should (of course) specify the pertinent
heading but should not distinguish between base and virtual relvars in any way.
