I have this script(dtsx file) on a sql 2005 server (made by some other technician), some stored procedures update tables with data from views. I can see that these views are based on other views, sometimes 4 to 5 layers thick before hitting the database tables. Would you recommend to improve this construction?
(when confronted with this script i found no documentation, so i don't know the motivation why this construction is used)
No, I would not recomend you change this, unless there is some logical, or business requirement that you change the structure.
Views on views is quite normal.
Have a read here
Using Views in Microsoft SQL Server
SQL Server Views
Related
I have created views on the SQL Server 2005 database and this view is based on views provided by a third party. I'm displaying them in our application via JDBC connection and they seems to be very slow. I tried another method and created them as a table by using SQL (select into) command in this case viewing the data in the application is fast. Can you advise me please about the best approach.
How can I improve the application performance?
Indexed view.
Use SSIS to get them into our database which is also an SQL Server 2008 R2.
What else?
The best way I have to found to improve the performance of queries (including views) is to take a look at the generated query plans produced by SSMS. The first thing I look for is Index or Table scans. When you see any of those, there is a good chance an index is needed, and often times you'll need to INCLUDE columns in the index for the index to actually get used.
Indexed views can give a tremendous performance boost. However, Microsoft has laid so many restrictions on them it's often very difficult to actually use them. They will also affect insert / update / delete performance on the base tables. So there is a trade-off.
I doubt that creating a separate table is a viable long-term and scaleable approach unless the plan is to execute these queries a very small number of times. The process of copying this data can be extremely resource intensive.
You should understand where the slowness is first.
Materializing the data into a table obviously means later selects can be faster, but the copying may be slow. If the data is slowly changing, that is certainly a design approach which can work.
Indexed views have restrictions and all indexes will affect write performance, since they need to be updated when data changes.
It sounds like two servers could be in play here. It's not clear if the views you created are on your server or the 2005 server. If you create a view in one server on views in another linked server, it is possible that more data is being pulled between the servers than is strictly necessary (compared to all the views being on the same server and being able to be optimized together).
How can I improve the application performance?
Indexed view.
Use SSIS to get them into our database which is also an SQL Server 2008 R2.
What else?
Another option not mentioned is
Don't use views
My experience is that non-indexed views typically make things slower and indexed views are difficult to create due to restrictions.
If you encounter some problem where you think you need to use a View try using a CTE or inline view instead.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Why is database view used?
Since I always can use Select statement from original tables instead of creating a view and using select from it, I wonder what are benefits of using view in database?
It simplifies calls and provides a layer of indirection.
So, if you have a complex select with lots of joins, you can implement it in a view and simply call the view without need to consider all these joins. You can then reuse this view.
Additionally, if you use a view instead of a table in this manner, in the future if you need to migrate a column, you can easily do that and only require changes to the view.
There are several, but I think the main benefit is that views are the SQL implementation of logical data independence.
Build an updatable view, and applications that use the view are relatively immune to changes in the underlying tables. Change the structure of the underlying tables, update the view definition, and all applications work as if nothing had happened. (On legacy databases, there might be hundreds of applications written in dozens of languages. This is the big win.)
Other benefits (paraphrasing Chris Date)
"Automatic" security for hidden data. Restrict access to views, and you have fine-grained control over who sees what.
"DRY" capability for applications. A view can provide a simple, public interface to a complex SELECT statement, so applications can just SELECT column-list FROM my-easy-view.
Different users can see the same data in different ways.
Besides the obvious benefits that Oded mentioned, you can sometimes drastically improve speed by using materialized views. From wikipedia:
In a database management system following the relational model, a view is a virtual table representing the result of a database query. Whenever an ordinary view's table is queried or updated, the DBMS converts these into queries or updates against the underlying base tables. A materialized view takes a different approach in which the query result is cached as a concrete table that may be updated from the original base tables from time to time.
I'm writing in VB.net 4.0 and using SQLExpress 2008 R2. In a DataGridView, I would like to display (no edits) data coming from multiple tables in my database. A second Grid (different data, still multiple tables) will need to allow editing and saving of data.
I understand creating a View in the database and using that as a source for the DataGridView. I also assume that there are ways to query and create a data source for the Grid totally within my VB program. Would someone explain the consequences and implications of the different approaches?
I recommend you look into LINQ to SQL for your data calls. It would be prudent for you to create a data access layer class that performs all of your data calls separate from any UI architecture you have. This allows you to maintain the data calls within the code but separated from any display logic.
Putting your queries into SQL server as views or stored procedures simplifies some of your immediate code within the application, but over time stored procedures and views become harder to maintain. Unless you have massive data load and optimization requires stored procedures, I'd recommend you investigate the usage of LINQ for making quick, atomic data calls.
I would go with the good old Stored Procedure. Write one SP, getting data for each gridviews.
It has been quite a while since I used SQL Server and had been primarily working on Oracle DBs. I had grown accustomed to building materialized views off of my OLTP tables to speed up performance. I was excited to find information around what appeared to be the SQL Server equivalent of a Mat view...however, when I started reading and testing I realized I couldn't do things like sub-queries..reference other views, etc when building a view I was going to index. Are there any other techniques within SQL Server that folks use to speed up query times and build "reporting layers" off of the existing OLTP tables?S
I could add a lot more indexes, etc to the base tables, just really wanted to see if I could accomplish something simliar to Mat views.
I could totally be incorrect on the indexed views...still very ignorant, so if I am missing something let me know.
Thanks!
-S
Yes indexed views have a lot (and I mean a LOT) more limitations than Oracle's materialized views. What you can do to speed up reporting is create pre-calculated tables and have processes that update those. You can also use partitioning to manage ever growing tables
For heavy use OLTP apps, I will usually created separate reporting tables or db during off-hours, due to the additional load updating the indexed views puts on the system. For not frequently-updated data though, indexed views can be fantastic.
I infrequently (monthly/quarterly) generate hundreds of Crystal Reports reports using Microsoft SQL Server 2005 database views. Are those views wasting CPU cycles and RAM during all the time that I am not reading from them? Should I instead use stored procedures, temporary tables, or short-lived normal tables since I rarely read from my views?
I'm not a DBA so I don't know what's going on behind the scenes inside the database server.
Is it possible to have too many database views? What's considered best practice?
For the most part, it doesn't matter. Yes, SQL Server will have more choices when it parses SELECT * FROM table (it'll have to look in the system catalogs for 'table') but it's highly optimized for that, and provided you have sufficient RAM (most servers nowadays do), you won't notice a difference between 0 and 1,000 views.
However, from a people-perspective, trying to manage and figure out what "hundreds" of views are doing is probably impossible, so you likely have a lot of duplicated code in there. What happens if some business rules change that are embedded in these redundant views?
The main point of views is to encapsulate business logic into a pseudo table (so you may have a person table, but then a view called "active_persons" which does some magic). Creating a view for each report is kind of silly unless each report is so isolated and unique that there is no ability to re-use.
A view is a query that you run often with preset parameters. If you know you will be looking at the same data all the time you can create a view for ease of use and for data binding.
That being said, when you select from a view the view defining query is run along with the query you are running.
For example, if vwCustomersWhoHavePaid is:
Select * from customers where paid = 1
and the query you are running returns the customers who have paid after August first is formatted like this:
Select * from vwCustomersWhoHavePaid where datepaid > '08/01/08'
The query you are actually running is:
Select * from (Select * from customers where paid = 1) where datepaid > '08/01/08'
This is something you should keep in mind when creating views, they are a way of storing data that you look at often. It's just a way of organizing data so it's easier to access.
The views are only going to take up cpu/memory resources when they are called.
Anyhow, best practice would be to consolidate what can be consolidated, remove what can be removed, and if it's literally only used by your reports, choose a consistent naming standard for the views so they can easily be grouped together when looking for a particular view.
Also, unless you really need transactional isolation, consider using the NOLOCK table hint in your queries.
-- Kevin Fairchild
You ask: What's going on behind the scenes?
A view is a bunch of SQL text. When a query uses a view, SQL Server places that SQL text into the query. This happens BEFORE optimization. The result is the optimizer can consider the combined code instead of two separate pieces of code for the best execution plan.
You should look at the execution plans of your queries! There is so much to learn there.
SQL Server also has a concept of a clustered view. A clustered view is a system maintained result set (each insert/update/delete on the underlying tables can cause insert/update/deletes on the clustered view's data). It is a common mistake to think that views operate in the way that clustered views operate.