One database or many ?

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

If you're writing many databases that aren't necessarily associated
with each other (ie parts, vacation days, how you like your steak
done, and school you attended, etc; as examples), does it make more
sense to have one database name and several tables for the data topics
above OR multiple databases since they aren't associated with each

It would SEEM easier to have a single database with multiple tables
from a data management perspective as long as there's no risk of data
integrity issues as a result of having multiple tables under one
database header.   TIA

Re: One database or many ?

cover wrote:
Quoted text here. Click to load it

If you have data some are somehow releated to eachother, as they are managed
with the same tool, then one database will be IMHO the best option.
The integrity of data can be set by premissions for the users, so that an user
don't have access to all the tables, while another may have access to all the


Re: One database or many ?

Quoted text here. Click to load it
The company where I hosted my domain name charges an additional fee for a
mysql database. So I have chosen for one database, when I would need to
create more "subdatabases" (i.e. groups of tables that according to their
behaviour could have been separate databases) I could work with prefixes to
the tables so you can still use almost the same table names if necessary
like db1_members, db2_members and db1_results, db2_results etc. I think
there must even be a trick to transfer one "table group"  to a new database
when that will be necessary some day.

But be aware that I am relatively new at this topic :)
Good luck,

Re: One database or many ?

Quoted text here. Click to load it

Depends on what database product you are using.  MySQL? Oracle?

Nothing to do with PHP.

Geoff M

Re: One database or many ?

Quoted text here. Click to load it

It depends.  One consideration is security issues, and who uses the
data.  It is a lot easier and simpler to segregate access by database,
and easier to check that it's correct, even though MySQL and some
others allow access restrictions by table or by column.

In MySQL and some others you can do joins between tables in different
databases, should that "unrelated" data become related.

If you avoid writing code that explicitly names the database in
queries, it's easy to have a "test" database and a "production"
database, and the only difference in using the two is the database
name used on connection (which can be stuck in an include file).
If you do it with different table names in the same database,
changing from "test" to "production" is more complicated and it's
easier to screw up (e.g. the item is shipped but billing doesn't

Quoted text here. Click to load it

Throwing together lots of unrelated data can also complicate backup

                    Gordon L. Burditt

Site Timeline