Re: Performance (lots of tables / databases...)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Lester Caine:
danaketh wrote:
Hi,

the first choice is probably the best for you. When you think about second solution, it will be a nightmare when you have 1000+ databases and have to administrate them from one central system (if you're about to do it like this). The third solution looks little complicated to me - have one DB for comments, one for items etc.

But you can do it also in one database and six tables. Make one table 'blogs' where the blogs names and ids will be stored. Then you can just add one more field 'blog_id' to every table and identify items, categories, whatever on this. However in your situation (1000+ blogs) it may be not the best solution.

That alternate option is the easiest to manage, but since you make no mention of WHICH database engine which is best would be affected by that choice. And how you are hosting the site(s) may also limit your options. Properly indexed tables will be fast and a single connection accessing that data will be faster than having to make multiple connections to different databases, and if it only has to manage a small number of table most links would probably be cached.



Sorry, it's MySQL.

I am talking about ONE server => one connection
and then switching between databases.

Example:  SELECT * FROM [db_comments].testblog, [db_posts].testblog
Would this be a performance issue?


Thanks for joining,
Marti

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [PHP Users]     [Postgresql Discussion]     [Kernel Newbies]     [Postgresql]     [Yosemite News]

  Powered by Linux