July 31, 2014 at 8:21 pm
Comments posted to this topic are about the item Using Views
August 1, 2014 at 12:30 am
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.
August 1, 2014 at 2:04 am
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!!!
August 1, 2014 at 3:14 am
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!
August 1, 2014 at 3:53 am
Synonyms work in Oracle, anxious to test them out in MS SQL Server.
August 1, 2014 at 3:55 am
If I am not mistaken, it works only when View built on top of a SINGLE table and includes table's PK column(s)?
August 1, 2014 at 4:04 am
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!!!
August 1, 2014 at 6:04 am
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.
August 1, 2014 at 6:24 am
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.
August 1, 2014 at 6:37 am
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
August 1, 2014 at 8:38 am
I've seen several major ERP systems designed using views (JD Edwards, PeopleSoft, etc) . It adds a security layer and makes it easier to change the underlying data structure. It is a best practice. And for CRUD - use stored procedures as much as possible - as was noted earlier.
Yea, it is quicker to just use tables, until you need to make a change.
The more you are prepared, the less you need it.
August 1, 2014 at 9:49 am
We're in the middle of a huge project that's migrating an old legacy database into the current model, and we're using this strategy heavily, along with instead of triggers on the views. It's been very helpful in letting us make the changes iteratively, especially since there can be literally hundreds of objects in the database that reference a given table in some fashion.
There are some serious challenges though, and performance is sometimes one of them. There's no way we could do these changes all in one release cycle though, that way would lie madness and destruction.
August 1, 2014 at 11:37 am
Jason Whitish (8/1/2014)
We're in the middle of a huge project that's migrating an old legacy database into the current model, and we're using this strategy heavily, along with instead of triggers on the views. It's been very helpful in letting us make the changes iteratively, especially since there can be literally hundreds of objects in the database that reference a given table in some fashion.There are some serious challenges though, and performance is sometimes one of them. There's no way we could do these changes all in one release cycle though, that way would lie madness and destruction.
This would be interesting to plenty of people. If you had a particular table or two and are interested, we'd love an article or two on your experiences.
August 1, 2014 at 11:50 am
This would be interesting to plenty of people. If you had a particular table or two and are interested, we'd love an article or two on your experiences.
I'd be happy to. I'll go ahead and get started on it this evening.
August 1, 2014 at 12:01 pm
Views might work for a small subset of DDL changes since views are rarely update-able when based on more than one table. How can you handle a case where a denormalized child table column gets moved up into a parent table?
I queue up developer requests for a day, code and test locally, then deploy to development the next day. It breaks the app but all developers fix their stuff, check in, and get running again. The scheduled break and fix usually lasts less than an hour. I keep a full history of all DDL changes so I can apply them in order into other databases such as Testing, Staging, Production, etc.
Alternatively, if you have a stored procedure only interface to applications, you are completely free of the physical database design. This is the case for 90% of what I have.
I only use synonyms for objects external to the current database. I don't see how they would solve anything for a local schema change.
Viewing 15 posts - 1 through 15 (of 31 total)
You must be logged in to reply to this topic. Login to reply