I have multiple database-driven webapps that I'd like to install on a single server (bugDB, wiki, etc). From a performance standpoint, what makes more sense:
1. Create a database for each of the webapps
2. Create a single database for all of the webapps and differentiate the tables by appending a string at the beginning.

I think performance-wise is the same. From management wise, it's better to compartmentalize the tables per projects / web apps. Think about it this way. Say your wiki webapps really took off ... and database load is high on that particular app. You can simply move the database to a more powerful server without affecting other apps.

Another advantage of having multiple databases is that you can define different security for them. For example, the wiki app doesn't have read-write access to the bugDB.

Agree I don't think it matters providing the db is designed properly.

however what may make a difference is how the db(s) are used, whether you see one growing more rapidly, wheteher you see on being hived off into another entity, whether for load balancing you need to shift to more than one server

the reality is that if you have multiple databases but installed on the same server you will still get the same perfomance issues whether its in one or multiple db's.


I could see that for archive & admin it may make more sense to split the db's so you are dealing with smaller amounts of data, or if in the event of a recover you only loose one of several d's when a restore is performed on that db.

if there is no crossover of data I suspect there is somthing to be said in keeping the logically separate.