The root of the problem is that this table is still not enough normalized. I would make it two tables one for uid, access_time, report_id and the key seq_no and another for just report_option and key seq_no.

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
[download]

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

I was commenting the other guy design and I understood that the last column is Recor Option - the singular form. That is that for each option you have a different record. Then you need the normalization. When you group the options into a string the table is normalized (enough at least for most needs). Sorry if I misled you.