If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

 
Go Back  dBforums > General > Database Concepts & Design > Wide table VS. View Design

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old 09-20-06, 11:55
MO542 MO542 is offline
Registered User
 
Join Date: Nov 2005
Posts: 4
Wide table VS. View Design

Hi guys and gals!

I’m working on a warehouse project and I’m trying to create a design. I wrote some specifications for a table design there is some debate on the design. There are some members of the my team that believe that rather than creating a table we should create a view. I’ll go into the design a little here.

The proposed table design would have about 48 columns. 22 of these columns are keys back to dimensions; the rest are specific metrics (dollar amounts) that are attached to a claim. The metrics have to be calculated from the OLTP data.

The alternative design would create a view that joins a fact table (22 columns) and a separate table for each metric (26 tables) that would be joined back to the fact. All of the joins (for the metric tables) would have to be outer joins.

The reports that would be hitting the table (or view) would not be using all 48 columns at the same time. We might be using 10 of the foreign keys (to the dimensions) and maybe 3 of the metrics on a given report. The table will be about 8 million rows and we are using SQL Server 2005.

I’m being told that the view would be faster than the table; I’m not sold on this idea. But I realize that I have more to learn so I want to do my research first.

If any of this is not clear, please let me know; this is my first post .

Thanks in advance!
Reply With Quote
  #2 (permalink)  
Old 09-21-06, 18:22
certus certus is offline
Registered User
 
Join Date: Dec 2003
Location: Canada
Posts: 710
The best solution is not to create a bunch of fact to single dimension joins, but to create a view of the fact and all the necessary dimensions and attributes for the specific report. Then the report queries the view like a single table.
__________________
visit: relationary
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On