47

I have a problem to decide whether to use a view or a temp table.

I have a stored procedure that i call from program. In that SP i store the result of a long query in a temp table, name the columns and make another queries on that table store the results in labels or a gridview or whatever and drop the Temp Table. I could also store the query-result in a view and make queries on that view. So what is better or in what case do i HAVE to use a VIEW/ Temp Table.

According to my research a view has the benefit of: Security, Simplicity and Column Name Specification. My temporary table fulfills all that too (according to my opinion).

einpoklum
  • 86,754
  • 39
  • 223
  • 453
ruedi
  • 4,417
  • 11
  • 41
  • 73
  • 1
    Unless you state your goals and rank them in terms of their importance to you, this is really too general a question. – Tim Jun 03 '13 at 13:04
  • Only possible answer for this question is: You'll have to try both and see which one works better. – Nenad Zivkovic Jun 03 '13 at 13:11
  • 1
    A view (at least in mysql) is persistent across sessions. Different users executing the same code, will have a problem, executing code that creates the same view. Temporary tables are removed when the session closes, and are not shared between differrent sessions. – Marinos An Oct 03 '18 at 16:11

5 Answers5

51

If the query is "long" and you are accessing the results from multiple queries, then a temporary table is the better choice.

A view, in general, is just a short-cut for a select statement. If does not imply that the results are ever run and processed. If you use a view, the results will need to be regenerated each time it is used. Although subsequent runs of the view may be more efficient (say because the pages used by the view query are in cache), a temporary table actually stores the results.

In SQL Server, you can also use table variables (declare @t table . . .).

Using a temporary table (or table variable) within a single stored procedure would seem to have few implications in terms of security, simplicity, and column names. Security would be handled by access to the stored procedure. Column names are needed for either solution. Simplicity is hard to judge without more information, but nothing sticks out as being particularly complicated.

Gordon Linoff
  • 1,122,135
  • 50
  • 484
  • 624
11

depends

A view must replicate the processing of your "long query" each time it is run, while a temp table stores the results.

so do you want to use more processing or more storage?

You can store some view values (persistent index) which could help on processing, but you don't provide enough info to really explore this.

If you are talking about just storing the data for the use within a single procedure call, then a temp table is the way to go.

KM.
  • 95,355
  • 33
  • 167
  • 203
6

I'd like to also mention that for temporary table,

You cannot refer to a TEMPORARY table more than once in the same query.

This make temp table inconvenient for the cases where you want to use self join on it.

Moyuan Huang
  • 451
  • 5
  • 3
3

It is really a situational and operation specific question and answer may vary depending on the requirements of the scenario. However, a small point that i would like to add is that if you are using a view to store results of a complex query, which are in turn used in operations of a GridView, then it can be troublesome to perform update operations on complex views. On the contrary, Temp Tables can suffice to this perfectly.

Again, There are scenario's where Views may be a better choice [ as in Multiple Database Servers if not handled properly] but it depends on what you want to do.

Jayant Shelke
  • 137
  • 1
  • 7
3

In general I would use a temporary table when I want to refer multiple times to the same table within a stored procedure, and a view when I want to use the table across different stored procedures.

A view does not persist the data (in principle): each time you reference the view SQL uses the logic from the view to access the original table. So you would not want to build a view on a view on a view, or use multiple references to a view that has complex logic.