Talk:View (SQL)

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
???	This article has not yet received a rating on Wikipedia's content assessment scale.
???	This article has not yet received a rating on the project's importance scale.

The statement, "Views do not incur any extra storage overhead" is not entirely correct. A view does not require as much space as a/the table(s) that it represents, but it requires space to store the view definition. In Microsoft SQL Server, a view's text/definition is stored in the table syscomments and takes one row per every 4000 bytes of text in the definition of said view. Other databases would have to store the view definition somewhere, so it is a small, but a non-zero number, regarding the amount of space that a view takes. We have views that can contain four or five rows of data for our ERP system.

I think the point the article was making was that a view can provide columns from multiple tables but does not require the actual storage space to hold that result set. Wwphx 19:44, 27 August 2007 (UTC)wwphx[reply]

Right, but I agree that it sounds funny. I'll try to make it more correct without making it confusing. —Preceding unsigned comment added by 64.81.170.62 (talk) 22:40, 1 January 2008 (UTC)[reply]

Indicate advantages and disadvantages of views; help in understanding the concept's relevancy

Views compared to selects

The section about the advantages of views is rather strange. The most common method of getting data out of a database is using a SELECT statement.

Views can represent a subset of the data contained in a table
- so can a select
Views can join and simplify multiple tables into a single virtual table
- so can a select
Views can act as aggregated tables, where the database engine aggregates data (sum, average etc) and presents the calculated results as part of the data
- So can a select
Views can hide the complexity of data; for example a view could appear as Sales2000 or Sales2001, transparently partitioning the actual underlying table
- so can a select
Views take very little space to store; the database contains only the definition of a view, not a copy of all the data it presents
- selects actually take less space to store
Depending on the SQL engine used, views can provide extra security
Views can limit the degree of exposure of a table or tables to the outer world
- should this really be part of the database and not part of the application?

After all this, the only advantages of selecting from a view instead of just flat out selecting is that the view may provide additional security, which should arguably be handled by the application and not the database. It would appear that the 'advantage' list is rather biased. —Preceding unsigned comment added by 74.202.89.125 (talk) 19:45, 12 August 2009 (UTC)[reply]