MathResult, MathResult_2, MathResult_3, etc
Each table is basically the same entity, i.e. it has the same number of rows and each row has the same key value as its peer tables.
My question is that should I create a view to bring the tables together, given that a View doesn't seem to have any sort of row-size restriction? Normally I shy away from Views because I've always found them to bring performance down. Any thoughts?EDIT
Views are query rewrites so you will get mathematical problems like ISNULL function giving just plain wrong numbers. That said you can combine all into a UNION ALL view. This article is old but read what RDBMS(relational database management system) vendor agnostic expert Craig Mullins says about SQL Server Views in 1999.
I forgot to add that views don't use any query optimization plans and usually ignore the plans even if you create one. The reason persisted queries. Hope this helps.
http://www.craigsmullins.com/cnr_0299b.htm|||Thanks for the reply, yes the artical is a bit out-dated but IMO the basic points are still true. The trouble I'm having is that I know the views will be bad but I'm finding it difficult to quantify it, "how much worse will a view be"?|||
I would think that indexed Views will give you acceptable performance but I have not run the tests so I cannot be sure. The person who run some tests recently for all RDBMS(relational database management systems) for an advanced SQL book was Peter Gulutzan of now MySQL. I have the link to his recent article and a SQL Server specific Views performance article both should give you the dos and don't. Hope this helps.
http://www.dbazine.com/db2/db2-disarticles/gulutzan9
http://www.informit.com/articles/article.asp?p=130855
|||Om Sri Sai Ram
I think indexed views effects performance. For every row insertion in base table, one record needs to be inserted for indexed view
Thanks,
Ram
No comments:
Post a Comment