views:

1327

answers:

22

When and Why does some one decide that they need to create a View in their database? Why not just run a normal stored procedure or select?

A: 

When I want to see a snapshot of a table(s), and/or view (in a read-only way)

vehomzzz
what do you mean by a 'snapshot of a table'? When or why would you want to do that?
MedicineMan
There are many scenarios; say you want to run a complex query/store-precedure on a table without effecting and underlining table. You create a view (a read-only representation)
vehomzzz
You usually hear views in the context of reporting as well...
vehomzzz
view doesn't have to be readonly.
Yossarian
so if you want to run a complex query store procedure, couldn't you access the view in a read only fashion? I really don't have the database experience to 'get' what you are talking about here. Could you elaborate or provide a detailed example?
MedicineMan
+21  A: 

A view is an encapsulation of a query. Queries that are turned into views tend to be complicated and as such saving them as a view for reuse can be advantageous.

Andrew Hare
So you would want to create a view when you have a complicated query? How complicated of a query, what's the threshold? What do you gain from making it a view?
MedicineMan
How complicated is a personal choice really, there's no set threshold. You would often use a view if you don't want to duplicate logic in multiple applications or different points in your application for example. By making it a view you hide that logic and are able to share it easily.
ChrisCM
can't you do the same with a stored procedure that has a select? have i incorrectly thought of stored procedures as a way to store complex query logic? should complex queries be done in views instead of stored procedures? Whats the advantage of a stored procedure here?
MedicineMan
@MedicineMan - A stored procedure returns a result-set whereas a view represents a virtual table that allows you to use as a table in other queries.
Andrew Hare
FYI some database systems allow selecting from a stored procedure as if it were a table or view, so you get the best of both worlds.
Graeme Perrow
I think this point about result set vs virtual table seems to be a key point that I didn't understand.
MedicineMan
I believe in the past there were caching advantages also.I tend to use views for reusability. also its handy to tie lots of different db's together into a views layer for instnace (not that i entirely agree with this )
John Nicholas
+2  A: 

It can function as a good "middle man" between your ORM and you tables.

Example:

We had a Person table that we needed to change the structure on it so the column SomeColumn was going to be moved to another table and would have a one to many relationship to.

However, the majority of the system, with regards to the Person, still used the SomeColumn as a single thing, not many things. We used a view to bring all of the SomeColumns together and put it in the view, which worked out nicely.

This worked because the data layer had changed, but the business requirement hadn't fundamentally changed, so the business objects didn't need to change. If the business objects had to change I don't think this would have been a viable solution, but views definitely function as a good mid point.

Joseph
why would I want to create a 'middle man'?
MedicineMan
interesting. In your case, it is almost like an interface to the tables.
MedicineMan
+24  A: 

Among other things, it can be used for security. If you have a "customer" table, you might want to give all of your sales people access to the name, address, zipcode, etc. fields, but not credit_card_number. You can create a view that only includes the columns they need access to and then grant them access on the view.

Graeme Perrow
interesting. Security is a good answer. What 'other things' do you have in mind?
MedicineMan
I assumed that the other answers to this question would describe the "other things". :-)
Graeme Perrow
+1 Very good point.
Andrew Hare
+11  A: 

I usually create views to de-normalize and/or aggregate data frequently used for reporting purposes.

EDIT

By way of elaboration, if I were to have a database in which some of the entities were person, company, role, owner type, order, order detail, address and phone, where the person table stored both employees and contacts and the address and phone tables stored phone numbers for both persons and companies, and the development team were tasked with generating reports (or making reporting data accessible to non-developers) such as sales by employee, or sales by customer, or sales by region, sales by month, customers by state, etc I would create a set of views that de-normalized the relationships between the database entities so that a more integrated view (no pun intended) of the real world entities was available. Some of the benefits could include:

  1. Reducing redundancy in writing queries
  2. Establishing a standard for relating entities
  3. Providing opportunities to evaluate and maximize performance for complex calculations and joins (e.g. indexing on Schemabound views in MSSQL)
  4. Making data more accessible and intuitive to team members and non-developers.
cmsjr
can you elaborate on this? Your answer is being voted up quite a bit, but I'm not getting the value that everyone else seems to
MedicineMan
+1 for the elaboration
Graeme Perrow
+4  A: 

Several reasons: If you have complicated joins, it is sometimes best to have a view so that any access will always have the joins correct and the developers don;t have to remember all the tables they might need. Typically this might be for a finacial application where it would be extremely important that all financial reports are based on the same set of data.

If you have users you want to limit the records they can ever see, you can use a view, give them access only to the view not the underlying tables and then query the view

Crystal reports seems to prefer to use views to stored procs, so people who do a lot of report writing tend to use a lot of views

HLGEM
+1 It removes duplication. Even SQL can be (to some extent) DRY
Mike Woodhouse
+1  A: 

There is more than one reason to do this. Sometimes makes common join queries easy as one can just query a table name instead of doing all the joins.

Another reason is to limit the data to different users. So for instance:

Table1: Colums - USER_ID;USERNAME;SSN

Admin users can have privs on the actual table, but users that you don't want to have access to say the SSN, you create a view as

CREATE VIEW USERNAMES AS SELECT user_id, username FROM Table1;

Then give them privs to access the view and not the table.

RC
A: 

I like to use views over stored procedures when I am only running a query. Views can also simplify security, can be used to ease inserts/updates to multiple tables, and can be used to snapshot/materialize data (run a long-running query, and keep the results cached).

I've used materialized views for run longing queries that are not required to be kept accurate in real time.

MattH
when you are running a query as opposed to? Why? This point doesn't quite make sense
MedicineMan
when you use a view, you know you are only perform a DML operation, when you call an SP you don't what else maybe happening before you get your data. I.e. calling a cache function, may return the cached dataset, but it doesn't mean you should call the SP everything you want the data. It simplifies the API to the data IMO
MattH
+2  A: 

here are two common reasons:

you can use it for security. grant no permissions on the main table, create views that limits column or row access and grant permissions to users to see the view.

you can use use it for convenience. join together some tables that you use together all the time in the view, can makes queries consistant and easier.

KM
+55  A: 

A view provides several benefits.

1. Views can hide complexity

If you have a query that requires joining several tables, or has complex logic or calculations, you can code all that logic into a view, then select from the view just like you would a table.

2. Views can be used as a security mechanism

A view can select certain columns and/or rows from a table, and permissions set on the view instead of the underlying tables. This allows surfacing only the data that a user needs to see.

3. Views can simplify supporting legacy code

If you need to refactor a table that would break a lot of code, you can replace the table with a view of the same name. The view provides the exact same schema as the original table, while the actual schema has changed. This keeps the legacy code that references the table from breaking, allowing you to change the legacy code at your leisure.

These are just some of the many examples of how views can be useful.

Crappy Coding Guy
item 3 is a reason that no one else seems to have pointed out yet
MedicineMan
very good points (3 particularly) +1
Jeremy Powell
another +1 for point 3
ChrisCM
+1 for clarity/layout of answer - rather than usual blah blah blah blah <eyes glaze over> blah
adolf garlic
I think point 3 is more of stop gap than anything else. Eventually when you get round to updating the legacy code, you'll not only have to change the code behind the view but also all the code that have been built on top of the view. My 2cents
Nai
3 Is really the most powerful property of views. It's what help provides *logical data independence* the fact that you can provide an interface to the DB independent of the underlying logical database is a very powerful concept.
Falaina
@Nai... what do you mean, when you update the legacy code? That might be in 10 years. Or never.
John
@John this incurred technical debt has to be repaid sooner or later no? In 10 years it might not matter to that engineer who wrote it 10 years ago but it matters to the company.
Nai
Changing your main DB and everything depending on it is a bad choice to make because you might 'need it in 10 years'. Technical debt isn't to be avoided at all costs, only if the expected cost of fixing it later is more than the definite cost of fixing it now.
John
+1  A: 

Views can be a godsend when when doing reporting on legacy databases. In particular, you can use sensical table names instead of cryptic 5 letter names (where 2 of those are a common prefix!), or column names full of abbreviations that I'm sure made sense at the time.

Jeff Hardy
A: 

Views also break down very complex configuration and tables into managable chunks that are easily queried against. In our database, our entire table managment system is broken down into views from one large table.

Jim
A: 

This doesn't answer your question exactly but I thought it would be worth mentioning Materialized Views. My experience is mostly with Oracle but supposedly SQL-Server is fairly similar.

We used something similar in our architecture to address XML performance problems. Our systems are designed with a lot of data stored as XML on a row and applications might need to query particular values within it. Handling lots of XMLTypes and running XPaths across large number of rows has a large impact on performance so we use a form of materialized views to extract the desired XML nodes out into a relational table anytime the base table changes. This effectively provides a physical snapshot of the query at a point in time as opposed to standard views which would run their query on demand.

ChrisCM
A: 

I see a stored procedure more as a method I can call against my data, whereas to me a view provides a mechanism to create a synthetic version of the base data against which queries or stored procedures can be created. I'll create a view when simplification or aggregation makes sense. I'll write a stored procedure when I want to provide a very specific service.

jacor
can you give examples of small services
MedicineMan
+2  A: 

The one major advantage of a view over a stored procedure is that you can use a view just like you use a table. Namely, a view can be referred to directly in the FROM clause of a query. E.g., SELECT * FROM dbo.name_of_view.

In just about every other way, stored procedures are more powerful. You can pass in parameters, including out parameters that allow you effectively to return several values at once, you can do SELECT, INSERT, UPDATE, and DELETE operations, etc. etc.

If you want a View's ability to query from within the FROM clause, but you also want to be able to pass in parameters, there a way to do that too. It's called a table-valued function.

Here's a pretty useful article on the topic:

http://databases.aspfaq.com/database/should-i-use-a-view-a-stored-procedure-or-a-user-defined-function.html

EDIT: By the way, this sort of raises the question, what advantage does a view have over a table-valued function? I don't have a really good answer to that, but I will note that the T-SQL syntax for creating a view is simpler than for a table-valued function, and users of your database may be more familiar with views.

DanM
+1 for being one of the few answers to address the issue of stored procedures against SELECT statements. You're right to raise the issue of table functions. Basically, view are likely to perform better than functions because they share the same engine. There is an overhead (at least in Oracle) to be paid when switching from SQL to trabsactional SQL (i.e. PL/SQL). But all the other stuff - security, encapsulation, etc - applies equally to procedures or functions as to views.
APC
A: 

One curious thing about views are that they are seen by Microsoft Access as tables: when you attach a Microsoft Access front-end to an SQL database using ODBC, you see the tables and views in the list of available tables. So if you are preparing complicated reports in MS Access, you can let the SQL server do the joining and querying, and greatly simplify your life. Ditto for preparing a query in MS Excel.

A: 

Think of it as refactoring your database schema.

quillbreaker
A: 

Generally i go with views to make life easier, get extended details from some entity that's stored over multiple tables (eliminate lots of joins in code to enhance readability) and sometimes to share data over multiple databases or even to make inserts easier to read.

Kris
A: 

I only have 10 or so views in my production databases. I use several for columns I use all the time. One set I use come from 7 tables, some with outer joins and rather than rewrite that constantly I only have to call that view in a select and make one or 2 joins. To me it is just a time saver.

Brian Spencer
pardon me if this is outside the scope of the question, but several people have mentioned this-- don't you incur some kind of performance penalty for doing this?
MedicineMan
Not at all. SQL Server optimizer show the exact same plan to select * from view as it does for the SQL joins equivalent to the view
Brian Spencer
A: 

I am creating xxx that maps all the relationships between a main table (like Products table) and reference tables (like ProductType or ProductDescriptionByLanguage). This will create a view that will allow me retrieve a product and all it's details translated from its foreign keys to its description. Then I can use an ORM to create objects to easily build grids, combo boxes, etc.

GRGodoi
A: 

Hey I found this site that touches on creating views for databases. There's even some example coding. Enjoy!

http://www.izenda.com/Site/KB/Integration/18

Rocky
A: 

What about performance? Isn't a DB engine able to optimise a view, and let you put indices on it for instance? Or at least know it's a view and therefore cache the query results into a table in the background?

John