Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
jesus4u
Posting Yak Master
204 Posts |
 Posted - 2003-02-14 : 13:04:59
|
This is a sample of some data that is a result of a SELECT that calculates the total number of sites that referred traffic to our websites.What I would like to do is store these results in another table so that my boss can simply SELECT that results table and get the report.Is this good practice? I need your opinions.Thankscoralridge.org 52 4549 4549 0- 36 3200 3199 1216.247.64.85 5 499 499 065.240.226.68 1 97 97 0crministries.org 0 84 84 0google.com 0 43 43 0search.yahoo.com 0 19 19 0search.msn.com 0 16 16 0oneplace.com 0 14 14 0 |
|
|
JustinBigelow
SQL Gigolo
1157 Posts |
Posted - 2003-02-14 : 18:34:51
|
| I'd suggest creating a view instead of a table. You won't have to store the aggregated data that way. Your boss can do the same select as if it were from a table. m2c,JustinExpect 0x80040106 |
 |
|
|
nr
SQLTeam MVY
12543 Posts |
Posted - 2003-02-15 : 02:13:10
|
| If the table is being updated frequently or is large then the view wouldn't be a good idea. Better to give the aggregate table.You will need to give a method of recreating this table from scratch and may want to do this periodically.Do you need it to be up to date? In that case you can put a trigger on the main table - may cause a problem due to slowing the updates. Better would be to include the aggreagate in an insert stored procedure.If it is ok for the table to be a few minutes out of date then run a scheduled job to add any new data.==========================================Cursors are useful if you don't know sql.DTS can be used in a similar way.Beer is not cold and it isn't fizzy. |
|
|
|
|
|
|
Storing Massive Results