[SGVLUG] Probably more "dev" related, but a question on databases...

[Emerson, Tom (*IC)]

I've come across something I think is a bit odd for a database - every table has a corresponding "view" that (I presume) is little more than "select * from table" - end user (reporting) apps only have access to the "views" and not the underlying tables.  The reason I've been given for this is that it "avoids locking issues".

>From this, I also presume that the "views" are "read only", which I would agree would avoid locking the underlying table, but doesn't a "view" imply extra processing and/or storage to support the view?  [i.e., a "temporary" table built and populated with a copy of the data]

This seems to be a false-economy to me - but then, I "grew up" with a different sort of database than the current crop of RDBMS's, one in which "locking" wasn't a big scary issue.  (it is still a big issue, just not scary...)  After all, "end user apps" can be written such that any "query" is a "read only" query, avoiding the need to generate a temporary table and populate it with a copy of the data [in particular, you would need/use "non-repeatable" reads]

For those of you who administer modern databases, does this make sense?  Is it true that a "view" that mirrors the structure of an existing table completely avoids "locking" issues with the tables, or are you robbing peter to pay paul?  [using more disk or processor time to present the same data]