MySQL Forums
Forum List  »  Performance

Question regarding multi-tables
Posted by: Anthony Greco
Date: March 15, 2005 01:16AM

I am coding up a website using PHP5, mySQL 4.1 and I have a quick question:
Is there a noticeable difference between using one database with three tables, or using three databases with one table? Reason I am asking is because I expect my site to eventually get a LOT of traffic and it is 100% database dependant. It uses it CONSTANTLY for every page. Because of this, I would have to assume that my mySQL server will eventually start to lag very bad. I decided it would probly be best to split up my current database by table into as many seperate databases as possible. (ex: make one for mail, one for images, one for users profiles).

Obviously when doing this, I can not split up tables that are dependant on each other. For the most part, though, they all depends on a single value "user_id" to relate to each other. Because of this, to split them into different database's should not be that hard.

Some pages will have to call from mutli-databases, while others will only require a max of two (the one to retrieve the user_id and the one that is mainly being used).

Any suggestions/Comments/Past experiences would be very helpful. I know I might be getting ahead of myself, but I have had to go back and recode things many times. I do not want to do that with this (atleast I want to keep it to a minimun by trying to predict future problems that I will run into regargless of what happens.)

note: At first, I plan on running all the mySQL databases off of the one server, but as users increase, I will invest the money in giving the more active ones their own server until they all have their own.

Thanks in advance.

Options: ReplyQuote


Subject
Views
Written By
Posted
Question regarding multi-tables
2494
March 15, 2005 01:16AM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.