Why views, stored proc's etc. Re: [GENERAL] Is my MySQL Gaining ?
Chris Travers <chris@travelamericas.com>
From: "Chris Travers" <chris@travelamericas.com>
To: "Tony" <tony@unihost.net>, "Shridhar Daithankar" <shridhar_daithankar@myrealbox.com>, <tgl@sss.pgh.pa.us>, <pgsql-general@postgresql.org>, <pgsql-advocacy@postgresql.org>
Date: 2003-12-30T12:37:42Z
Lists: pgsql-hackers
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.