August 3, 2006 at 12:05 am
Ok can some one settle the age old argument of:
Is it better to look onto a view or a table directly?
I know that in different cirumstances it will differ, but lets say someone has created a view that is a simple view onto a table, nothing fancy, no joins, it just selects all data from that table. Why would they do this? Wouldnt it be easier to just select directly from a table?
Thanks
August 3, 2006 at 2:11 am
If all your view does is a select of all columns with no WHERE clause then the only reason I can think of for doing so is to provide a synonym for the table.
August 3, 2006 at 3:18 am
Thats what I thought, but I have read post where people live by the fact that they never look onto tables directly, even the most basic 2 column tables.
August 7, 2006 at 9:20 am
Another factor to create view is if you want to expose only few columns of the table to other external application.
August 7, 2006 at 12:05 pm
I think the point with "never look onto tables directly" is that if you give read access to the table then someone can decide what they want to read from the table.
If table access is via stored procedures then they can only ever do what the stored procedures are designed to do.
August 14, 2006 at 12:45 am
Yeah I see what you are saying, but even views, just plain old views that just select all columns in a certain table I have read to be 'better' than reading directly from that table itself. Any ideas why?
August 14, 2006 at 3:35 am
I've no idea. Frankly I would be amazed if it were true.
The only possible benefit that springs to mind is if you use the table hint NOLOCK then you can do a dirty read.
August 14, 2006 at 3:01 pm
A view on every table is useful for establishing the interface between a client side application and the database and isolating the client application from physical database changes.
If you have to add or drop columns in the physical table, it is much less effort to isolate the client from these changes if you have a view in place than can also be modified to give the client the illusion that nothing has changed. So you'll have all these apparently redundant views, which only have value months or years later when a physical database change is required and the views let you make the change without having to recompile & re-deploy the client app.
Of course, that opens up another debate - why is the client selecting from the view & not using a stored proc for data access.
August 14, 2006 at 5:19 pm
Currntly in my setup for my own apps that Ive have (somewhat) written myself. I have all the code looking onto views directly. Not to tables (or as you mentioned stroed proc's). I didnt write all the code for this app which is where the original question comes from.
Most of the code was directly looking onto views that were so basic in their functionality, that it seemed pointless. I see exactly what you are saying, but the chances are that when a database strucutre changes at all it is usually the app that needs to change along with it to reflect these new changes.
For example when a new feature get implemented that adds columns your code will obviously change to implement the new change, or if a bug was found and a column datatype changes, chances are that values is your code will be wrong so it is nessecary to change and re-compile.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply