One database or many ?

[cover]

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
other?

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

[J.O. Aho]

cover wrote:

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
other?

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

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
tables.

//Aho

[J.O. Aho]

cover wrote:

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
other?

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

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
tables.

//Aho

[Geoff Muldoon]

cover <coverland914 @ yahoo.com> says...

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
other?

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

Nothing to do with PHP.

Geoff M

[Geoff Muldoon]

cover <coverland914 @ yahoo.com> says...

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
other?

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

Nothing to do with PHP.

Geoff M

[Martien van Wanrooij]

"cover" <coverland914 @ yahoo.com> schreef in bericht
news:1115784541.db02b61609020993f871cd980906dbc7@t eranews...

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
other?

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,
Martien

[Gordon Burditt]

>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
other?
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
happen).
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

Throwing together lots of unrelated data can also complicate backup
strategies.

Gordon L. Burditt