Let me see if I follow. This table is an access log (reports run):
| seq_no (auto incremented key) | uid | access_time | report_id |
|---|---|---|---|
| this record | who | when | which report |
And then there's another that tracks the individual options for each report in the access log:
| seq_no (key) | report_options |
|---|---|
| record lookup | string of report options |
Is that what you were proposing? It seems good to me, though I want to percolate on that for a bit (since I'm still getting my head around how this access log is going to be used... and of course, you all have no idea :) ).
So my code would do this to figure out how many reports were run by each uid w/in a date range (excuse my psuedo code in advance):
(psuedo code) select count(seq_no) where uid like $uid and report_id like $report_id + and $access_range1 > access_time > $access_range2
And to check to see if a user was re-running a report (ie running a report w/ identical options w/in a certain time period) I'd match report_id, uid and access_time, to get seq_no that matched. Then I'd check the suspected re-run report options with report_options in table2.
Sound about right? Is there further normalization that could happen? Thoughts on splitting the report_options out like this? Anything else? I really appreciate your thoughts on this.
AH
In reply to Re: Re: Re: Suggestions on storing loosely similar data
by alienhuman
in thread Suggestions on storing loosely similar data
by alienhuman
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |