Should a SQL database be able to handle the creation of thousands of tables on a daily basis or do I have to change my code?

This is my first time designing tables in a sql database and I have no idea how much server cpu this would use and whether this is a viable way of coding.

I have to create a开发者_JAVA百科 bidding site where the gist is every time someone bids (where bids have to be bought separately at 50 cents per bid) the final price goes up by 1 cent, 2 cents, or 5 cents.

The trouble I'm facing is that I have to make a database table to keep track of the item's bid history and it seems like I have to create an individual table for each item (3 things need to be kept track of apart from the item id - bidder, bit time, cents at which it was bid on).

I'm fairly inexperienced in this and am willing to go back to the drawing board to brainstorm another table design, but was wondering if creating thousands (assuming the site will be somewhat successful) of table on a daily basis for each new item being listed is something that's alright. And I'm probably overestimating site traffic and might be more in the range of just a few hundred tables per day, but I want to prepare for the worst.

I would go back to the drawing board. Creating new tables for what is essentially the same thing is poor design. Have you heard of the DRY (Don't Repeat Yourself) principle.

Why do you think you need one table per item ?

you could design a table structure with perhaps to hold your items, their bid history with 2-3 tables for all items together... depending on the metadata it could usefull to have another 1-2 tables... always NOT pet item but per "information type" (like "item history", "item metadata").