An Online Auction Data Model

Bidding sites are a popular way to buy and sell many products. In this post, we look at these online auctions from a buyer’s perspective. What does our data model need to handle the bidding process?

There are many online auction sites (eBay, eBid, Webstore, Bonanza, etc.) where one can buy jewelry, clothing, electronics, and a lot more. How these sites work is simple: an item is listed, people bid on it, and the highest bidder wins the item, often at quite a discount. Some online auction sites allow their registered users to sell their own products, but we won’t go into that today. We’ll look at an online auction data model from the bidder’s perspective. How can a data model be designed for the bidding process?

The online bidding process starts by offering the product at a predetermined base price. Every time a bid is placed, the product’s price increases by a fixed amount. Bidders also have to pay a small fee each time they bid. When the product’s auction is about to end, each bid placed may reset the timer by a certain number of minutes or seconds. This gives everyone a fair chance to get in their best bid.

Now we know what the online bidding process is like. Let’s talk about what features we want the data model to support.

What Does This Data Model Need?

Our online auction data model should include the following functionalities. Of course, we can always add some features later, but these will get us started:

• It should support a detailed description of the item on offer, including specifications and the base price (i.e. the minimum starting bid). Note: A base price must be set for the auction to begin.
• Only a limited number of bidders can participate in each auction. Limiting the number of bidders improves each one’s chances of winning the auction.
• Every bid placed increases the current price by a set amount. This amount is determined by the product and its base price, e.g. a product with a $10 base price might have a bid increase of $1, while a $1,000 product might have a bid increase of $50.
• When the countdown is about to end, any bids placed may add a predetermined number of seconds to the clock, e.g. when an item has two minutes left to run, every bid made adds 30 seconds to the clock.
• The bid balance (i.e. the product price) is adjusted automatically after every successful bid.

Before continuing, let’s see the entire data model.

The Data Model

This online auction data model is divided into three subject areas:

1. Bidders and Bid Coins
2. Products and Bid Offers
3. Bidding Process

Bidders and Bid Coins

This subject area is all about users and their accounts. In this auction site, bidders have to pay for reserving “seats” (i.e. being one of the limited number that can bid on a product). They also have to pay a small amount for each bid they place. All these transactions will require bid coins, which bidders will purchase from the auction website.

The bidder table holds basic details about people who register as bidders. The columns in this table are:

• id – Assigns a unique number to everyone who registers. This is the primary key for the table.
• first_name – The first name of the bidder.
• last_name – The last name of the bidder.
• date_of_birth – The bidder’s date of birth.
• email – The bidder’s email address.
• user_name – A user name, chosen by the bidder, that he or she will use to log into the auction site.
• pwd_enc – The bidder’s password, in encrypted form.
• joining_date – The date when the bidder registers with the site.
• curr_bid_coins – The number of bid coins the bidder currently has. This column updates every time a bid order involving this person is complete. We will discuss bid orders in the next subject area.

The bid_coin_bag is a static table that stores details about the coin bags offered to bidders. Bidders must purchase coin bags to place a bid, since their bid will be n coins. A bidder can buy any number of coin bags at any time. The bigger a bag is, the less each coin costs. As a marketing strategy, some bonus coins can be offered with the purchase of a bag. These bonus coins are no different than regular coins. The following columns enable us to meet these requirements:

• id – A unique ID number assigned to each bag offering.
• bag_name – A descriptive name, like “Bonanza 500” for a bag with 500 bid coins.
• bid_coins – The number of coins included in the bag.
• bonus_coins – The number of bonus coins given to the bidder when he or she purchases the bag.
• cost_in_currency – The price, in real currency, of the bag of coins.

The bid_coin_transaction_log table contains records of bidders’ deposits and transactions. It is like an account statement for bidders. Deposits will only happen when a buyer purchases a bag of coins, and withdrawals will happen when a buyer places a bid order (i.e. reserves a spot in an auction) or places an actual bid. The columns in this table are:

• id – A unique number given to each transaction.
• bidder_id – The ID of the relevant bidder.
• bid_coin_bag_id – Holds values related to purchases. This is a referential column that signifies which bag of coins is purchased by the bidder. It is NULLABLE because there will either be a value in this column or in the bid_order_bidding_log_id column, but not in both.
• bid_order_bidding_log_id – Holds values related to expenses, such as placing a bid order. This is a referential column that signifies which auction is associated with a withdrawal. It is NULLABLE for the reason explained above.
• transaction_type – Whether the transaction is a deposit or a withdrawal.
• transaction_date –The date and timestamp of the transaction.
• coins_count – The number of coins involved in the transaction.

Products and Bid Orders

This subject area describes products and the bid activities related to those products. Note: I’m keeping this subject area confined to products because I want to emphasize bid activity and the bidding processes.

The product table holds basic details about the products being auctioned. This table contains:

• id – A unique number given to each product.
• product_name – The name of the product.
• product_category_id – The category to which the product belongs – electronics, jewelry, etc. This is a referential column.
• product_specification – A brief description of the product, including its specifications.
• actual_cost_in_currency – The retail cost of the product.

The bid_order table captures everything relevant to bid activity: placing a bid order and submitting a bid on an auction item. The columns in this table are:

• id – A unique number assigned to each bid activity.
• product_id – The product in the auction.
• bid_start_time – When bidding will start.
• bid_end_time – When bidding will end.
• bid_chair_cost_in_bid_coin – The cost of registering to bid, in bid coins.
• number_of_chairs_allowed – The maximum number of bidders (i.e. “seats” or “chairs”) allowed for the auction.
• base_price_in_currency – The product’s opening bid (or starting price).
• bidding_cost_in_bid_coin – This column signifies the cost of each bid, i.e. how many bid coins to place a bid on the product.
• increment_in_price_per_bid – The number of coins that the product price will increase with each bid.
• increment_in_time_per_bid – The time (in seconds) by which the auction counter will be increased with each bid. This will be applicable only towards the end of the auction, say during last two minutes or so. If the column is NULL, the bid will end at the scheduled time; no time extensions have been allowed by the seller.

Bidding Process

This subject area manages the details of bidding registration and how bids are placed.

The bidder_bid_registration table contains details about who has registered to bid on an auction. The columns in this table are:

• id – The primary key of the table.
• bidder_id – Relates the bidder to the registration to bid.
• bid_order_id – Which auction the bidder is registering for. This is a referential column, and we can use it to derive other details like the relevant product and the bid start and end times.
• registration_date – The date when the bidder registered for this activity.
• is_active – If this bidder is still actively bidding. A bidder can withdraw their registration at any time. If they do, this column is set to “N”. Otherwise, this column is “Y” for all active registrations.

The bid_order_bidding_log table stores all bids made during an auction. It contains the following columns:

• id – The primary key of the table.
• bidder_bid_registration_id – Links to information about bidders, auctions, and bid activity. Note that this is a referential column
• bid_timestamp – The timestamp when a bid is placed.

With all these tables in place, we should be able to derive details about bidding activity, including the selling price of a product, who won the bid, how many people placed a bid for the product, and so on.

What Do You Think?

In the end, only one person wins the bid. However, some online auction sites give everybody who bids something in return, such as a discounted price on similar products. This discount is equivalent to the cost of bid registration. Or they may not have to pay for bid registration the next time they sign up to bid on an auction.

What additional structures do we need to enable this feature? What other changes would you make?

Please let us know in the comment section.