MySQL: Many tables or many databases?

Question

For a project we having a bunch of data that always have the same structure and is not linked together. There are two approaches to save the data:

• Creating a n

Answer 1

If you don't want one set of tables with poolID poolname as TheTXI suggested, use separate databases rather than multiple tables that all do the same thing.

That way, you restrict the variation between the accessing of different pools to the initial "use database" statement, you won't have to recode your SELECTs each time, or have dynamic sql.

The other advantages of this approach are:

• Easy backup/restore
• Easy start/stop of a database instance.

Disadvantages are:

• a little bit more admin work, but not much.

I don't know what your application is, but really really think carefully before creating all of the tables in one database. That way madness lies.

Edit: If performance is the only thing that concerns you, you need to measure it. Take a representative set of queries and measure their performance.

Edit 2: The difference in performance for a single query between the many tables/many databases model will be neglible. If you have one database, you can tune the hell out of it. If you have many databases, you can tune the hell out of all of them.

My (our? - can't speak for anyone else) point is that, for well tuned database(s), there will be practically no difference in performance between the three options (poolid in table, multiple tables, multiple databases), so you can pick the option which is easiest for you, in the short AND long term.

For me, the best option is still one database with poolId, as TheTXI suggested, then multiple databases, depending upon your (mostly administration) needs. If you need to know exactly what the difference in performance is between two options, we can't give you that answer. You need to set it up and test it.

With multiple databases, it becomes easy to throw hardware at it to improve performance.