SQL PROGRAMMING STYLE- P15 pot

7.12 Improper Use of VIEWs 147

sex INTEGER DEFAULT 0 NOT NULL
CHECK (sex IN (0, 1, 2)),
);

And a CHECK() constraint is simpler than creating VIEWs with the
WITH CHECK OPTION.

Exceptions:

None

7.12.2 Single-Solution VIEWs

Rationale:

Another past usage for VIEWs was to enable solutions where VIEWs
really were the only way to solve a data access problem. Without VIEWs,
some complex data access requests could be encountered that were not
capable of being coded using SQL alone. However, sometimes a VIEW
can be created to implement a portion of the access. Then, the VIEW can
be queried to satisfy the remainder.
Consider the scenario where you want to report on detail information
and summary information from a single table. For instance, what if you
would like to report on stock prices? For each stock, provide all stock
details, and also report the maximum, minimum, and average prices for
that stock. Additionally, report the difference between the average price
and each individual price.

CREATE VIEW StockSummary (ticker_sym, min_price, max_price,
avg_price)
AS
SELECT ticker_sym, MIN(price), MAX(price), AVG(price)
FROM Portfolio
GROUP BY ticker_sym;

After the VIEW is created, the following SELECT statement can be
issued joining the VIEW to the base table, thereby providing both detail
and aggregate information on each report row:

SELECT P.ticker_sym, P.quote_date, S.min_price, S.max_price,
S.avg_price,
(P.price - S.avg_price) AS fluctuation
FROM Portfolio AS P, StockSummary AS S
WHERE P.ticker_sym = S.ticker_sym;

148 CHAPTER 7: HOW TO USE VIEWS

Situations such as these were ideal for using VIEWs to make data
access a much simpler proposition. However, the advent of table
expressions (sometimes referred to as in-line VIEWs) makes this usage of
VIEWs obsolete. Why? Instead of coding the VIEW, we can take the SQL
from the VIEW and specify it directly into the SQL statement that would
have called the VIEW. Using the previous example, the final SQL
statement becomes:

SELECT P.ticker_sym, S.min_price, S.max_price, S.avg_price,
(P.price - S.avg_price) AS fluctuation
FROM Portfolio AS P,

(SELECT ticker_sym, MIN(price), MAX(price), AVG(price)
FROM Portfolio
GROUP BY ticker_sym) AS S
WHERE P.ticker_sym = S.ticker_sym;

So we can use a table expression to avoid creating and maintaining a
VIEW.

Exceptions:

If an expression is used in many places and it has a clear meaning in the
data model, then create a VIEW.

7.12.3 Do Not Create One VIEW Per Base Table

Rationale:

A dubious recommendation is often made to create one VIEW for each
base table in a SQL application system. This is what Craig Mullins calls
“The Big VIEW Myth.” This is supposed to insulate application programs
from database changes. This insulation is to be achieved by mandating
that all programs be written to access VIEWs instead of base tables.
When a change is made to the base table, the programs do not need to
be modified because they access a VIEW, not the base table.
There is no adequate rationale for enforcing a strict rule of one VIEW
per base table for SQL application systems. In fact, the evidence
supports not using VIEWs in this manner. Although this sounds like a
good idea in principle, indiscriminate VIEW creation should be avoided.
The implementation of database changes requires scrupulous analysis
regardless of whether VIEWs or base tables are used by your

applications. Consider the simplest kind of schema change, adding a
column to a table. If you do not add the column to the VIEW, no
programs can access that column unless another VIEW is created that

7.13 Learn about Materialized VIEWs 149

contains that column. But if you create a new VIEW every time you add a
new column, it will not take long for your environment to be swamped
with VIEWs.
Then you have to ask which VIEW should be used by which program?
Similar arguments can be made for removing columns, renaming tables
and columns, combining tables, and splitting tables.
In general, if you follow good SQL/SQL programming practices, you
will usually not encounter situations where the usage of VIEWs initially
would have helped program/data isolation anyway. By dispelling, “The
Big VIEW Myth,” you will decrease the administrative burden of creating
and maintaining an avalanche of base table VIEWs.

Exceptions:

None

7.13 Learn about Materialized VIEWs

Rationale:

A materialized VIEW is brought into existence in the physical database,
where it can be used like any other table. This is implementation
dependent, so you have to know what your product does to get the best
use of this feature.

All VIEWs are supposed to act as if they are materialized, but in
practice the text of the view can often be put into the parse tree of the
statement using it and expanded like an in-line macro statement. For
example, given this VIEW:

CREATE VIEW NewYorkSalemen (ssn, first_name, )
AS
SELECT ssn, first_name,
FROM Personnel
WHERE city = 'New York';

When it is used in a query, the effect is as if it were a derived table
expression inside that query. For example:

SELECT ssn, first_name,
FROM NewYorkSalemen
WHERE firstname = 'Joe';

150 CHAPTER 7: HOW TO USE VIEWS

in effect becomes:

SELECT ssn, first_name,
FROM (SELECT ssn, first_name,
FROM Personnel
WHERE city = 'New York')
AS NewYorkSalemen (ssn, first_name, )
WHERE firstname = 'Joe';

which will probably become something like this in the parse tree:

SELECT ssn, first_name,
FROM Personnel AS NewYorkSalemen (ssn, first_name, )
WHERE city = 'New York'
AND firstname = 'Joe';

However, if more than one user references a VIEW, it can be cheaper
to materialize it once and share the data among all users. If the
materialized result set is small enough to fit into main storage, the
performance improvements are even greater.
This is actually a common event, because we tend to build views that
summarize data for reporting periods. Thus, lots of users want to get to
the same summary views at the same time. If you plan the VIEWs to take
advantage of this usage pattern, you can get major performance
improvements.

Exceptions:

None

CHAPTER

8

How to Write Stored Procedures

“Whatever language you write in, your task as a programmer is to do the
best you can with the tools at hand. A good programmer can overcome a
poor language or a clumsy operating system, but even a great programming
environment will not rescue a bad programmer.”

—Kernighan and Pike

E

VERY



SQL



PRODUCT

has some kind of 4GL tools that allow you to write
stored procedures that reside in the database and that can be invoked
from a host program. Each 4GL is a bit different, but they are all
block-structured languages. They have varying degrees of power and
different language models. For example, T-SQL is a simple, one-pass
compiler modeled after the C and Algol languages. It was not intended
as an application development language, but rather as a tool for doing
short tasks inside a SQL Server database.
At the other extreme, Oracle’s PL/SQL is modeled after ADA and
SQL/PSM. It is a complicated language that can be used for application
development. Likewise, Informix 4GL is an application development
language that generates C code, which can be immediately ported to a
large number of platforms.
What this means is that anything I say about SQL stored
procedures will have to be general, but perhaps the most frightening

thing is that I have to go back and teach basic software engineering