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 . 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. 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. 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