I have created a series of views that operate on a fairly large table. The table has been properly indexed and the performance is entirely sufficient. I would like to add an additional layer of views to the DB that are effectively views of views. What I want to know is whether SQL Server is smart enough to use the indexes on the underlying table when it builds the query, or whether I need to index the first tier of views somehow?
Yes it is. A view (not persisted) is nothing more than a query stored on your DB. If you have a view called view1 as select * from table1 and do select * from view1, SQL Server will automatically transform that to select * from table1 and then build a execution plan
Same rule applies if you increase the chain of objects adding more views.
Related
Is there any way to get row-level security in SQL Server 2014?
My problem is:
I have a table with data for multiple regions
I created a view for each region
Specific user will have access to specific region views
But without giving access to the underlying table, those users are unable to access the views
I need to restrict users to view only certain rows. Are there any possibilities to do so?
I have achieved it by creating views for the specified rows and giving permission to only views not underlying table
so user has visible to only rows which are returned by views. We can control rows to be returned by where clause in view.
but table may contain other rows as well
key terms : Ownership chaining
The same SQL query returns results based on identity. No special database code required. You can control how the rows and columns return, and even aggregation. For example, the SQL below will return different results for managers, analysts, and developers.
select * from employee_salaries;
The limit of 10 GB is reached and different constraints force to circumvent this limit the time that a set of patches can be put in place. An appropriate license is already in place on another server but unfortunately the migration can not be done in a reasonable time. To address the most pressing, we must find the way to override the limit imposed by SQL Server Express. Shrinkage, aliasing, file splitting, index changes, all of these were attempted without success. Suggestions?
Since the 10GB limit is per database you can use the following trick to split the data among several databases. Warning: people with strong DB beliefs please close your eyes now :-)
Move some tables to other database, choosing a set of tables than doesn't break foreign key constraints.
For each table create a view with the same name in the original database like this:
create view TableName as
select * from TheOtherDB..TableName
In this way you use the view as the table and you don't have to change a single query, SQL Server allows INSERT, UPDATEand DELETE on that type of views as if they were a table, but the data is stored in the other DB.
Of course after you migrate to the new server you should move the data back to one database.
I need to select from 2 VFP free tables on some different network locations.
I've managed to get both tables into a dataset as two DataTables and add a Relation for them.
Now I need to join them and the result to insert into a SQL server database.
Any ideas?
Use two different queries to load the required subset of rows and columns from each table, upload each table individually to temp SQL server tables (using SqlBulkUpload), and then run your query in SQL against the two temp tables to create the required table.
Use Microsoft Access to add them as linked tables. You can then read the data from .net as though it were native Access data. You might be able to create queries in Access that join the tables and then read the queries from .net too.
If any database spreads across multiple servers (ex. Microsoft Sql Server), how can we do join or filter operations. In my scenario, if suppose:
A single table spreads across multiple servers how can we filter rows based on user input?
If master table is there on one db server and transaction table is at another db server, how can we do join operations?
Please let me know how can we achieve this and where can I get more details about this?
I think you're confused about SQL clustering - it doesn't allow you to split tables across multiple servers any differently than you would put different tables in different databases on the same server. Clustering is used for hot failover and redundancy.
However, I think I see what you're asking - if you want to split a database up between different physical servers, the easiest thing to do might be to have a VIEW that unifies those tables together in one place, and then you can query and filter that. SQL Server is smart enough (as long as there are indexes and statistics in place to make the decision from) to send the query where it needs to go if you select something from the unifying view.
For example, say you have two servers - SERVER1 and SERVER2 that both have a database - DATABASE - and each server has a table - TABLE - that has half the data in it (between the two servers, you have every row). Just create a view somewhere - either server, or somewhere else entirely - that looks like this, and then add Linked Servers for SERVER1 and SERVER2 that allow SQL Server to get the data from the remote location:
CREATE VIEW SomeView
AS
SELECT *
FROM SERVER1.DATABASE..TABLE
UNION
ALL
SELECT *
FROM SERVER2.DATABASE..TABLE
That way, you have one place to query and you'll always grab the data from whatever server it's on, instead of querying each server by itself. You can do this even if you don't want to split up individual tables - just create a view for each table you want to move, and have the view check whatever server the table is actually located on.
If I've missed your actual question, please leave a comment and some clarification and I'll be happy to add some more detail.
Does anyone have experience of when SQL Server 2008 R2 is able to automatically match indexed view (also known as materialized views) that contain joins to a query?
For example the view
select dbo.Orders.Date, dbo.OrderDetails.ProductID
from dbo.OrderDetails
join dbo.Orders on dbo.OrderDetails.OrderID = dbo.Orders.ID
Cannot automatically be matched to the same exact query. When I select directly from this view with (noexpand) I actually get a much faster query plan that does a scan on the clustered index of the indexed view. Can I get SQL Server to do this matching automatically? I have quite a few queries and views and I do not want to reference the indexed view manually each time because I am using an OR mapper.
I am on enterprise edition of SQL Server 2008 R2.
Edit: I found the solution. SQL Server 2008 R2 does not match indexed views with more than 2 joins automatically. Probably it would slow down the optimization process too much.
Edit 2: Reviewing this 2 years after the question was created by me, I don't think my conclusion was correct. Materialized view matching is a very fragile process with no clear rules that I could find over the years.
Certainly, the following play a role:
Number of joins
Presence of a predicate
Join order, both in the view and in the query
I'm a little fuzzy on exactly what your question is; but I think this will give you what you want:
http://msdn.microsoft.com/en-us/library/ms181151.aspx
There are a lot of strange, arbitrary-seeming conditions that limit when SQL Server will use a view index in a query. This page documents them for SQL Server 2008.