I have to deal with large volumes of data of exactly this nature. In my shop we call them assignment records or dated records. Our records typically have a ($id,$keyfield,@other_data,$start_date,$end_date) structure where start_date and end_date are constrained to be in order (start_date<end_date), non null and via trigger based constraints records with the same $keyfield are guaranteed not to overlap in the DB (any update that results in an overlap is rejected by the trigger). We use a long distant date to represent the end_date of "open" assignments, and we state the rule that the start_date is inclusive and the end_date is exclusive (ie the start_date is part of the assignment, the end_date is not, it represents the first second after the assignment.)

This structure allows a much more flexible way of working with this type of data than most of the alternatives I've seen (such as using null to represent open assignments, or to using only a single date column). For instance IMO the query to extract all assignments valid for the month of 2004-11 is not easy to write with the table you have, and probably wont be particularly fast if you do work it out. (This is an operation that is very common for the systems i work on.) With the start_date/end_date mechanism such a query is really very easy to write.

I know this doesnt address your direct question: I'm not a fan or user of Class::DBI at all. I prefer hand rolling my own tools for things like this as I find for the type of database work I do that its both easier to maintain and easier to understand. OTOH I hope my experience with this type of database table is useful to you, especially as I think youll find Note 2 quite difficult to do, and I also wonder what youll do if a user is a member of a group for one month, not a member for the next and then member the following month (ie one/off/on). It seems to me like youll always have a time period where your assignments are wrong.