There is no adequate rationale for enforcing a strict rule of one—view per base table for SQL Server application systems.

In fact, the evidence supports not using views in this manner.

Mullins Views are a very useful feature of relational technology in general, and Microsoft SQL Server specifically.

They are wonderful tools that ease data access and system development when used prudently.

There are three basic view implementation rules: These rules define the parameters for efficient and useful view creation.

Following them will result in a shop implementing views that are effective, minimize resource consumption, and have a stated, long-lasting purpose.

Therefore, a view can be considered a logical table. The SQL comprising the view is executed only when the view is accessed and views can be accessed by SQL in the same way that tables are — by SQL.

No physical structure is required of a view; it is a representation of data that is stored in other tables. When modifying data through a view (that is, using INSERT or UPDATE statements) certain limitations exist depending upon the type of view.

Views should be created only when they achieve a specific, reasonable goal.

Each view should have a specific application or business requirement that it fulfills before it is created.

That requirement should be documented somewhere, preferably in a data dictionary or repository.