By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,402 Members | 1,628 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,402 IT Pros & Developers. It's quick & easy.

One database or many ?

P: n/a
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
Jul 17 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
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
Jul 17 '05 #2

P: n/a
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
Jul 17 '05 #3

P: n/a
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
Jul 17 '05 #4

P: n/a
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
Jul 17 '05 #5

P: n/a

"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
Jul 17 '05 #6

P: n/a
>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
Jul 17 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.