At 05:48 AM 10/23/01 -0400, Rex Arul wrote:
>Peter:
>
>I am not sure how I can differ or accept your statement, which is sort of
>appealing to me. Let me run this by you. On querying a database, I am
>getting a recordset of this form:
>
>2001-10-01 01:00:00 Amy 10 20 normal 555.234
>2001-10-01 01:00:00 JoeDoe 15 25 high 623.456
>2001-10-01 01:00:00 RexArul 10 20 high 772.265
>2001-10-01 02:00:00 Amy 10 20 high 544.345
>2001-10-01 02:00:00 JoeDoe 15 25 high 689.52
>2001-10-01 02:00:00 RexArul 10 20 high 800.002
>
>As you could see the recordset is sorted by Date-Timestamp first and then by
>the user-names second in the database. This is how the recordset is handed
>out to my ASP Page. I slash the records into a hash with Date-Timestamp and
>user-names being my hash keys (HashOfHashOfArrays):
>
>Like this:
>
>$returnHash->{getDTS($objRS->Fields(0)->{Value})}{$objRS->Fields(1)->{Value}
>} =
> [$objRS->Fields(2)->{Value},
>$objRS->Fields(3)->{Value},$objRS->Fields(4)->{Value},$objRS->Fields(5)->{Va
>lue}];
Might read a bit better as
{
my ($time, $user, @fields) = map $objRS->Fields($_)->{Value}, 0..5;
$returnHash->{getDTS($time)}{$user} = \@fields;
}
>Now as you see the date-timestamp and usernames, both are not going to lose
>their already sorted order from the database. Please shed some ideas as to
>how this is would be construed as mismodelling.
Let me be clear that I wasn't saying that it (mismodelling) was a given in
your case... just that in my experience it has been very common (in others).
In this case, there is an obvious way to re-sort the data (I take it that
getDTS() does something like convert to epoch time). So you can always
recover the order with a call to sort() later on. Unless there are a lot
of hash keys this is generally okay.
However, there's something odd on the face of it with a time being used as
a hash key. It's unusual to be handed a time later on and know that it
belonged to the set of ones you'd encountered, although I can imagine it
happening. More common in my experience is that you're given a time and
you need to find the closest record before or after, or you're given a
range of times and you need to find the records in between. In which case
a hash isn't the right structure; the records should be in an array, since
you're going to have to do a linear traversal (absent some clever algorithm
for bucket indexing or the like).
Also, your data structure only allows you to pull out records for a
particular user if you know their timestamps. I don't know whether you
would ever want to access all records for a particular user, but if you
did, you'd want a hash keyed by username.
*If* that were the case, a data structure like this might be better:
{
my ($time, $user, @fields) = map $objRS->Fields($_)->{value}, 0..5;
$time = getDTS($time);
push @recs, [ $time, $user, @fields ];
push @{$recbyuser{$user}}, [ $time, @fields ];
}
but as I say, it depends entirely on how you want to access the
data. Without further information I have no reason to say you are doing it
wrongly.
>Thanks in advance,
>--Rex
>
>----- Original Message -----
>From: "Peter Scott" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>; "Rex Arul" <[EMAIL PROTECTED]>
>Cc: <[EMAIL PROTECTED]>
>Sent: Tuesday, October 23, 2001 1:45 AM
>Subject: Re: Maintaining Order of Keys in a Hash
>
>
> > At 09:52 PM 10/22/01 -0400, Jeff 'japhy' Pinyan wrote:
> > >On Oct 22, Rex Arul said:
> > >
> > > >Without resorting to any additional lists/arrays, how can I maintain
>the
> > > >order of the keys in a hash? Is there a "package/module" that would
>redress
> > > >this issue?
> > >
> > >Tie::IxHash, on CPAN.
> >
> > It should be said, if you care about the order of the keys in your hash,
>it
> > is far more likely that you have mismodelled your problem than that you
> > need to use IxHash.
--
Peter Scott
Pacific Systems Design Technologies
http://www.perldebugged.com
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
