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
