Was this clever or dumb?

[Tiger Hillside]

My code is working, so this is not a question about that. But I just
came up with a solution that was either clever or dumb and I can't
figure it out.

The problem is this: I have a database that lists people doing stuff
at set times on various days. I was asked for a report that would say
something like:

"7 people worked at 7 PM on May 6"

The "7 PM" and the "May 6" are fields in the database.

It seemed to me that I needed a multidimensional hash. Then I thought
that I could concatinate time and date and use that as a hash key:
$timeval . "+" . $datevalue.

That would have worked, but at the printing end I would have had to
pull the fields apart and get that right. Then I had what I thought
was a good idea. I did the following concatination: $timevalue . " on
" . $datevalue", sorted the keys, and just printed out the has value
and the key.

Something about this bothers me. You are not supposed to use keys that
way and I am making the keys larger which, I suppose, could cause
problems if I have really large results. OTOH the codes is neat and
clean and short without being, AFAICT, cryptic.

So was that clever? Normal? A bad idea? I am, as I have said in a
previous post, new to perl and I don't know if I am getting it. Any
comments?

 

[Greg Miller]

That would have worked, but at the printing end I would have had to
pull the fields apart and get that right. Then I had what I thought
was a good idea. I did the following concatination: $timevalue . " on
" . $datevalue", sorted the keys, and just printed out the has value
and the key.

I do that all of the time. So I'm guessing it's dumb I
think it's the best way to do it for a small dataset. But if you're
going to be looking at thousands or millions of records, you're better
off doing an "order by" in your SQL on the date/time then loop through
all of the records and output the date/time and count anytime the
date/time on the current record isn't the same as it was on the last
record.

 

[Tiger Hillside]

I do that all of the time. So I'm guessing it's dumb

There is dumb and dumb. I will take that this as the right kind of
dumb. I try to be a bit smarter than my code when I can. ;-)

I
think it's the best way to do it for a small dataset. But if you're
going to be looking at thousands or millions of records, you're better
off doing an "order by" in your SQL on the date/time then loop through
all of the records and output the date/time and count anytime the
date/time on the current record isn't the same as it was on the last
record.

That was my first thought, have the DBMS do the sorting and check for
changes in key. That is how I would have done it in C. It would have
required much more testing to make sure that I had all of the
comparisons right and default values and such. Since I was not doing
any checking I couldn't get it wrong. We will see if size becomes an
issue. I have other reasons for keeping the number of records examined
to a minimum.