I have one experience making one web application (a news database that shows the last 5 stories entered in the DB).

I am in the process of setting up a service online. I don't want to start phase 2 then 3 only to find out that I messed up in phase 1 later cause that only makes me a unhappy camper who has to decide to keep on truckin or go thru some uprooting.

My question is: Is having more than one MySQL database a benefit performance wise?

Lets say you have two sets of data: users and news. They have no relationship.

I know they can be on seperate tables within the same database. I want to know if it slows the database down percieveably if operations are being performed by clients on either sets of data. Or do I more have to worry about bandwith instead of DB performance.

Does it make sense to have two seperate databases for this type of thing?

Thanks for reading this in advance.

I think for the standard, run-of-the-mill web application it's inefficient and inelegant to have more than one database. However, you mentioned one of the data sets being "users," which is the one case in which I have heard of creating a separate db. I remember reading an article that suggested it as a security measure.

However, I doubt a second database is necessary and it seems inelegant. What if you wanted to create a relationship between the two datasets in the future? What if you wanted to record which news articles users read (ethical considerations aside)?

I would agree with Phaedrus, it does seem odd to have two-databases. However, you should bear in mind that you can have as many Tables in one database as you like. Good database design suggests that you should split the information you want to hold in databases up into tables as much as you can.

Say for example, a bike club holds members information in a database. They will have their full name (Title, First Name, Second Name) and their address (1st Line, 2nd Line, Town/City, County/State, Postal/Zip Code), however, members can give their address at will; it's optional. Therefore, we're going to need two tables, because if the majority of members dont give their address, we're going to have blank cells in our database, this slows down querys as well as taking up valuable space - plus it's just plain naughty!.

So we split them up into two relating database, using an ID field in the Members name table as the Key, and in the address table use the ID field again as the foreign key. That way you can call for the members addresses if and when you need them - quickly.

As for an example in news script, if you have a comment feature, for example, the comments would be stored in a seperate table, with the comments corresponding to a certain ID Key in the news stories table.

Hope I didnt just talk utter rubbish all the way through that, and that it makes some sense

No sir it makes perfect sense.

Through reading my Web database design book it mentioned having different levels of security such as OS authentication (i guess for locally) and DB authentication (for web applications) then going to table, column, relational, storing procedures for certain groups depending on who is logged in, etc.

It only briefly glossed over unrelated datasets and whether to keep them in the same DB or not. I can't remember right now, something about if a hacker gained access to the db with all data in it even unrelated that he would have all my information. The book said it is a security issue.

About it being inelegant, what exactly is the criteria for inelegance? Not that I'm challenging the statement but I want to know what is common and I suppose therefore elegant and since I am relatively inexperienced with dynamic database driven web aps, I don't really know what is considered elegant besides naming conventions, etc.

And if you wanted to connect two DBs, can't you use a join statement and refer to the db like db1.tblCustomer INNER JOIN db2.tblNewsComments? Excuse my syntax, but is it possible to do something like that? I just find it hard to believe that some of these huge websites are using only one DB to handle everything. I know that the ER models can get pretty complex.

Is there somewhere that you can see sample ER models of existing web applications to get an idea of how these things are layed out? Cause in my book, they present one for a webstore and walk you through how the DB handles the transaction and it is pretty simple.

Sorry for my wordyness but I just want to get this thing right and I know some of you have done these things before.