Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 1234»»»

Using Views Expand / Collapse
Author
Message
Posted Thursday, July 31, 2014 8:21 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 10:36 AM
Points: 31,362, Visits: 15,823
Comments posted to this topic are about the item Using Views






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1598547
Posted Friday, August 1, 2014 12:30 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Monday, December 15, 2014 11:29 AM
Points: 92, Visits: 457
Believe it or not, but this is taught in a course I just took for the SQL Server 2008 R2: Database Developer certification. It's covered with creating and altering views.

In my case, it was covered when defining uses for indexed views. Some applications hard code access to specific tables. A view can be created to replace the old object with the new structure and suffer little to no downtime from the application.

I myself have not practiced this technique, but it did catch my attention when I heard it from the course. That's because it surely sounded like a best practice that I'm sure everyone should pick up on.

Here are my notes from that particular section being I have it up.


What can you use indexed views for?

1. Improve Performance
1a. You can have indexed views compute and store data to improve performance.

2. Filter or Restrict Access To Data
2a. Views can be used to filter or restrict access to data because you specify which columns are included in a view in a defining query.

3. Manipulate Data
3a. If you often need to execute queries that require one or more tables to be joined together, you can use a view to always to it.

4. Restructure Tables
4a. Some applications hard-code access to specific tables. View can be created in replace of the old object with the new structure.

5. Customize Data
5a. Views can be used to customize data for the user viewing it.

6. Importing and Exporting Data
6a. You can define the data you wish to export in the views definition. The BCP utility can then use the view as the source.

Post #1598584
Posted Friday, August 1, 2014 2:04 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 1:45 AM
Points: 5,813, Visits: 3,734
This editorial highlights a key reason why I believe in using stored procedures. All I want from a stored procedure is to answer some question (no, not query) or to store a set of data (no, not a data set). I don't care how these happen and that gives power to those either side of the stored procedure interface definition. Anything can change on either side as long as the contract remains unbroken.

As a systems developer that often has a RDBMS at the back end, I want to give as much leeway to DBAs to do performance tuning as well as allowing for multiple system access to a single database.


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1598611
Posted Friday, August 1, 2014 3:14 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Today @ 3:14 AM
Points: 1,807, Visits: 1,191
In light of the QOTD is anyone using synonyms for such purposes yet or would they not work for that? Don't know much about them.

Views have been soured for me by a particular project (where they were done very wrong), but I guess they could have a place if done correctly - I might consider them for a project I have coming up.

The using all stored procedures to define the interface thing is fine but it can put an awful lot of business logic into fairly impenetrable code. It's got some advantages, but the lack of ability to do things in a very well structured way puts me off that course of action (as a developer, without any access to DBA services). Of course they always have a place in my book for some jobs - just not simple CRUD stuff.

Nice win for our lads at the Amex on another note Gary!
Post #1598623
Posted Friday, August 1, 2014 3:53 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Today @ 10:45 AM
Points: 1,402, Visits: 6,893
Synonyms work in Oracle, anxious to test them out in MS SQL Server.
Post #1598630
Posted Friday, August 1, 2014 3:55 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: 2 days ago @ 12:47 AM
Points: 37, Visits: 177
If I am not mistaken, it works only when View built on top of a SINGLE table and includes table's PK column(s)?
Post #1598631
Posted Friday, August 1, 2014 4:04 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 1:45 AM
Points: 5,813, Visits: 3,734
call.copse (8/1/2014)
...Nice win for our lads at the Amex on another note Gary!


Goes to show how unlucky you were not to get the League 1 silverware those few years ago. [Sorry everyone for going off topic]


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1598634
Posted Friday, August 1, 2014 6:04 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Yesterday @ 8:01 AM
Points: 154, Visits: 284
fregatepllada (8/1/2014)
If I am not mistaken, it works only when View built on top of a SINGLE table and includes table's PK column(s)?


Only if you try an update directly through the view. If you define appropriate triggers you can do multi-table updates. Triggers have their own issues, and if you think about it, by the time you write the logic for those, you've probably written a fair piece of a stored procedure.

I inherited a database with an Access front-end that was linked directly to the tables (you may wince now) and I used views that mimicked the exsiting tables to de-couple the tables from Access so I could re-work the schema without blowing up the whole thing. Stored procedures can be used with Access via pass-through queries but there are some extra gymnastics since SQL Server doesn't know a thing about the Access object model. Views on the other hand act the same as a linked table.

It's still a work in progress with the eventual goal of moving to a tiered architecture, but using views has certainly simplified the process - not to mention allowing me to learn a good bit of SQL in the process.

This isn't to say you should or souldn't use views. Like all things SQL Server, they're another tool in the toolbox and you have to evaluate when, where and how to use them.


____________
Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.
Post #1598653
Posted Friday, August 1, 2014 6:24 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Today @ 8:22 AM
Points: 386, Visits: 182
We have leveraged this option to some degree. But our system also uses replication, and each new view is another article of replication we must add. We are already over the recommended limit, so our DBA pushes back hard any time we try to add more.
Post #1598660
Posted Friday, August 1, 2014 6:37 AM


Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Friday, December 12, 2014 10:49 AM
Points: 11, Visits: 146
I personally embrace project based deployment methods such as the use of SSDT and dacpacs. I think that this method would prove a challenge in that environment because you'd have to create more than one build of the dacpac and deploy them in stages. The alternative would be to put everything in the pre-scripts but then you lose the value that is gained with that type of project.

For implementations that aren't doing this and prefer to execute hand-made scripts, I find it a useful tactic.


Derik Hammer
@SQLHammer
www.sqlhammer.com
Post #1598663
« Prev Topic | Next Topic »

Add to briefcase 1234»»»

Permissions Expand / Collapse