PROS! I need advice on DB structure!

Anon

Hello Pros,

Wondering how I should set this up.

I have a database which has 3 tables.

TITLES
INFO
REGIONS

Now, the REGIONS will always be attached to the TITLES, and the INFO is dependent on which TITLE we're talking about.

I need to add something new. INFO2 & STARS.

If INFO2 is present, then STARS & REGIONS will be present too.

If INFO is present, then REGIONS will be.

So, basically my database will look like:

Some TITLES will be attached to INFO and REGIONS, and some TITLES will be attached to INFO2, REGIONS, & STARS, and some TITLES will be attached to EVERYTHING...displayed on seperate pages.

My question is, is it better to start another DB with INFO2 & STARS tables and have it relate to the TITLES in the other DB, OR is it better to have everything under the same DB???

van__

Well, considering the use of a DB is to act as a broad container for all relative data

And also considering the fact that joins on tables in seperate DB's can't be used in a single query...

I'd really have to say that the no brainer move here is to stick with a single database.

Why now would we ever use more than one?
Well, let's say you have mondo data.
We know every database get's it's own file generated on the server, so we say, let's have virtual shopping isles made for us via databases. So, what we wind up with is say "movies" becomes a single database with tables for each genre, which act as shelves in our virtual shopping isle. And one isle over is the database "games" and on it's shelves are the various genres of games.

Ahhh....
Now you see that we come full circle.
And return to my first point of a database being a container for all related data.
And that this not only makes a virtual store ready for shopping, but at the same time makes the databases query faster.
And it makes sense to do this since we would never be joining a movies data with a games data for any normal query.

And for most sites, one database is more than enough to keep a mid-sized site pumping away. And as you can also see, breaking up your related data into seperate databases will only hurt your process flow and hamper your development.