Hashmap within a Hashmap? Or better solution?

Question

I might be approaching this all wrong, but I think I want to have a group of nested hashmaps. I'm trying to build an auction house. When someone comes with a new product category, I want create a hashtable for that product category so hashmap allows me to label the category and put in the product as object. then, i want another level of hashtable to map individual product with the bids it receives ($ amounts). and, finally, i want to be able to label each bid by an id token, so, if the bidder comes back, i can then cancel or amend their bid. I was thinking of using an ArrayList to contain the bids for two reasons: (1) I want to order the bids so that I can respond to them on a first come first served basis and (2) I figured I could just keep track of the bid's price and search through the ArrayList for the id to modify it.
I know the following won't work, but am I anywhere close? And, also, how do I deal with determining whether a product category hash has already been created (or a bid price hash) or whether i need to instantiate one? Thanks so much in advance!!!
     private static Map<String, Map<Double, ArrayList<String>>> productCategory;
     private static Map<Double, ArrayList<String>> bids; // double used for the bids and array list of strings is for the id tokens
     public static void main (String[] args) {
          productCategory = new HashMap<String, HashMap <Double, ArrayList<String>>>;
          bids = new HashMap<Double, ArrayList<String>>;

Answer 1

Hmmm... I suppose you could use hashmaps to "map" these relationships, but that doesn't make it a good idea.
There is no need to use a "dynamic" datastructure like a Map to define the relationships you describe. Nesting Maps allows you to model a "tree" of arbitrary depth and complexity (like a file-system directory tree), but in this case "the complete set of allowable relationships between types" is know up-front... note that's between types, not individual instances... so this is a classical "static model" which (funnily enough) should be modeled "statically".
SO... I'd be inclined to model all these relationships as has-a relationships, using simple attribute fields (some of which will be lists).... atleast for the first cut.... later you might decide that there really are subtypes of things (like FloorBid, PhoneBid, or OnlineBid) and you would "refine" the model at that stage.
SO.... I guess I'd start with: An Auction has a Product and a list of Bids. You add a Product to the list, then create an Auction on that product, advertise, and hopefully recieve some Bids. At the completion of the auction some moneyis exchanged for the goods... and the Product, its Auction, and it's bids are either deleted; or (more likely) archived off to a warehouse of historical auction records.
HashMaps are for when you don't/can't know ALL the type-relationships upfront. What you where thinking of doing constitutes abuse (that's too strong a term, but can't think of "the right word") of there dynamic modeling ability.
My advise is "get something down". Getting a "first draft" down is the hard bit... it's the bit where even seasoned IT pro's sometimes suffer "writers block".
HTH.
Cheers. Keith.
Edited by: corlettk on 20/09/2009 13:37 ~~ Clearer.