Zarrek, I great description on how the system could possibly work. When I had thought about it, I had broken the AH into 3 main components:
- Interactive Interface
- Delivery System
With that break down, the buy/sell interface may have a table that only has the following schema:
Once a purchase is made through the interactive component 2 messages are put on a queue. First the BuyerID, ItemID, and Qty is set to the delivery system, which then mails the items to the buyer. Then the ItemID, QtyA, PriceX, ItemID, QtyB,PriceY,… so on is sent to the backend.
The backend then has the full schema as you described plus auctionID and AuctionLength (for expiration). This process then determines which actual auctions sold, determines the seller, updates the auctions table, and send messages to the Delivery System with Seller and price info for them to receive their proceeds from the sale.
Based on how I had broken it down, the Interactive interface may not have the attributes available to display the seller information. It can only indicate your auctions because that lookup was done separately for the “Auctions” tab of the interface.
Now to steer this back from a programming discussion to a discussion of the user experience of the auction house, neither method, mine nor Zarrek’s, leaves room to display seller information on the user interface in a way that the buyer can take action based on who the seller is. Doing so sacrifices the efficiency improvement that was a core design objective in this overhaul.