views:

81

answers:

5

When I create a view I can base it on multiple columns from different tables. When I want to create a lookup table I need information from one table, for example the foreign key of an order table, to get customer details from another table. I can create a view having parameters to make sure it will get all data that I need. I could also - from what I have been reading - make a lookup table. What is the difference in this case and when should I choose for a lookup table?? I hope this ain't a bad question, I'm not very into db's yet ;).

+1  A: 

Creating a view gives you a "live" representation of the data as it is at the time of querying. This comes at the cost of higher load on the server, because it has to determine the values for every query. This can be expensive, depending on table sizes, database implementations and the complexity of the view definition.

A lookup table on the other hand is usually filled "manually", i. e. not every query against it will cause an expensive operation to fetch values from multiple tables. Instead your program has to take care of updating the lookup table should the underlying data change.

Usually lookup tables lend themselves to things that change seldomly, but are read often. Views on the other hand - while more expensive to execute - are more current.

Daniel Schneller
So in the lookup table you won't find live data representation?How is this table filled manually? Do you mean that you will run something like a stored procedure every day to update your lookup table so it stays up to date?
Younes
@Younes – per your question of view versus lookup table, yes, the lookup table won't contain 'live' data (necessarily) and you would need to maintain the table data somehow (either on a regular schedule, or as the source information changes). A view is, in-a-sense, a dynamic lookup table.
Kenny Evitt
A: 

Read this tutorial and you may find helpful info when a lookup table is needed:

SQL: Creating a Lookup Table

Pentium10
A: 

Here's an example of a lookup table. We have a system that tracks Jurors, one of the tables is JurorStatus. This table contains all the valid StatusCodes for Jurors:

Code: Value
WS : Will Serve
PP : Postponed
EM : Excuse Military
IF : Ineligible Felon

This is a lookup table for the valid codes.

A view is like a query.

Leslie
+2  A: 

I think your usage of "Lookup Table" is slightly awry. In normal parlance a lookup table is a code or reference data table. It might consist of a CODE and a DESCRIPTION or a code expansion. The purpose of such tables is to provide a lsit of permitted values for restricted columns, things like CUSTOMER_TYPE or PRIORITY_CODE. This category of table is often referred to as "standing data" because it changes very rarely if at all. The value of defining this data in Lookup tables is that they can be used in foreign keys and to populate Dropdowns and Lists Of Values.

What you are describing is a slightly different scenario:

I need information from one table, for example the foreign key of an order table, to get customer details from another table

Both these tables are application data tables. Customer and Order records are dynamic. Now it is obviously valid to retrieve additional data from the Customer table to display along side the Order data, and in that sense Customer is a "lookup table". More pertinently it is the parent table of Order, because it has the primary key referenced by the foreign key on Order.

By all means build a view to capture the joining logic between Order and Customer. Such views can be quite helpful when building an application that uses the same joined tables in several places.

APC
A: 

Just learn to write sql queries to get exactly what you need. No need to create a view! Views are not good to use in many instances, especially if you start to base them on other views, when they will kill performance. Do not use views just as a shorthand for query writing.

HLGEM