Ok, first I tried to look at the problem from a number of angles. I started by suggesting that you could use a tree (e.g., Tree::Binary) to store things - but the problem is that you want to look up data in multiple ways: by serial number, and by last-in. Look-up by serial number is a hash lookup, while look-up by last-in is an ordered list (ordered on the time of the insert). So then I was about to suggest storing your data simultaneously in multiple containers (since it's all references anyway, it's not going to take up that much space). But then, my fingers and mind got all twisted up trying to describe it.
That's a good indication that either it's a bad idea, or I don't understand the idea well enough to teach someone. I've been introduced to the idea before, but I've never actually used multiple containers for a single set of data before. So my experience just isn't great enough to really describe it. Then the epiphany.
You could simply get the display data directly from the database. Set indexes on the serial numbers and the last-insert-time fields. If you get multiple inserts per second, you may need a sub-second time field (I'm not sure if that's standard in RDBMSes or not - I pretty much only use DB2). If you still get multiple inserts simultaneously, it's not really that bad of a thing anyway. You can then query directly for any serial number you want (the database will use a b-tree for index lookup - for 20,000 records, that will mean approximately 14.3 lookups on average), and also query for the 20 highest insert times. Let the database worry about it. It'll use the best algorithms that it can - which you can help by setting up proper indexes.
Basically, you already have a powerful tool for this, and you're already eating most of the overhead of doing this with that tool. Take advantage of that tool for the rest of it :-)
In reply to Re^4: Populate and sort AoA
by Tanktalus
in thread Populate and sort AoA
by nedals
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |