PERL Miscellaneous - Was this clever or dumb?

Author

Was this clever or dumb?

Tiger Hillside

2004-05-19, 3:32 pm

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

2004-05-19, 8:31 pm

On 19 May 2004 11:51:24 -0700, tigerhillside@netscape.net (Tiger
Hillside) wrote:

>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

2004-05-20, 9:31 am

Greg Miller <gmiller@NOTforSPAM.gregmiller.net> wrote in message news:<1msna0pl7dvi37d9g8bhebrlq9kfpl4kdb@4ax.com>...
> On 19 May 2004 11:51:24 -0700, tigerhillside@netscape.net (Tiger
> Hillside) wrote:
>
>
> 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.

Sponsored Links