Best to use 100's of dbs or store 1000's of entries in db?

[mybikeisace]

I am currentely working on a large site that will store details of cars from many different car dealers in a cenetral location.

My original plan was to create each different dealer a new db. However I thought if I have to update or chage the db at all it will be a nightmare updating 100's of dbs.

However if I store the details of every car in the same db, and refrence them by storing the dealers id and end up having 10, 000's of records in the same db will it affect the performane a lot?

[Sxooter]

Actually, either inheritence or schemas might be a nice way to handle this. However, a pure relational model would be best if you're using mysql, which has neither. Cross db joins and such are never very efficient, especially for large amounts of data, so that a "summary" page might be mighty slow if it was spread across multiple databases. Same holds true, to a lesser extent, for using schemas (like postgresql, oracle, and a few other dbs support)

10,000 records in a database is childs play. Most any database can handle 10,000,000 rows with no real problem, as long as it's indexed right and your queries are properly tuned / written.

What I'd do is create a dealer table, and then use that to partition out the other data.