|
I have previously made my viewpoint known regarding
the need for training docs separate from the main docs.
Regarding views: Think single point of
maintenance. Here are a few examples:
1: You have a complex query which is run with
different restrictions in the WHERE clause. You can set up a view to make
maintenance easier, so you avoid duplication of effort.
2: You have an app that expects data to be
presented in a different way. You can use a view to do this.
You are right, that a view can do just what a
select statement does, but particularly for extremely complex data
manipulations, they are very helpful.
Here is another example:
Imagine that I have a complex database where I
store historical changes to a hotel and reservations. I can then use a
view to look at calculated vacancy rates. Then the vacancy rate view
can be manipulated in various ways as if it were a table. Often the simple
examples don't show as much as the examples that are much harder to do without a
view.
Stored Procs are much the same. The advantages of stored procs
are:
1)
For repeated queries based on other queries, less network latency
buildup.
2)
Stored procs can be used from any frontend, so if a function is generally useful
you might want to put it there.
|
