In SQL, a view is a virtual table based on the result-set of an SQL statement. A view contains rows and columns, just like a real table. The fields in a view are fields from one or more real tables in the database.is a virtual table based on the result-set of an SQL statement. A view contains rows and columns, just like a real table. The fields in a view are fields from one or more real tables in the database. I wish more people would realise the importance of this definition. It essentially means that, although the view in question may seem like a table when queried through Management Services or something similar, it is just that – it is a result of a SQL statement.
Too many times I have come across databases that are almost entirely built with views because the person building the queries does not realise this fundamentally important principle. Don’t get me wrong – views have their place in many databases, especially smaller ones where performance is not a major concern. The danger is when the database continues to grow and develop and the perpetrator does not change the way the data is being presented. You will then find that you have a SQL statement that takes longer and longer to run. The reason? You develop a query that produces the resulting data that you were asked to provide and this queries a view. In turn, this view may query more views which may also query more ad infinitum. Nested queries can be a ticking time bomb if not kept in check and the dangers can be seen when this happens. If you want a report or query to run properly get rid of your views. There should never be a complex query run on a view and there are NO exceptions. Don’t listen to anyone who says different. These are people who avoid and fall in the realm of Einstein’s advice – “if you can’t explain it simply, you don’t understand it well enough”. Met many people like this in my lifetime.
So, my advice? Use views sparingly and respect your users and servers.