Hello,
the solution you mentioned came up on my mind too, but as you also said
- it doesn't seem efficient on high load.
Why do you think having 1000+ databases would be a nightmare?
I think it would be easy to backup, fast to read/write... although I
don't know what would that cause to the system - trying to imagine 1000
folders... is it a problem?
I supposed that on the third solution is based the optimized wordpress
(wordpress.com) - it does seem complicated, but better than having it
all in one database.
Martin
danaketh napsal(a):
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.
Martin Zvarík napsal(a):
Hi,
I am working on a blog system and I am currently thinking of what
would be the best DB approach.
I have read lots about wordpress and other blog's optimizations and
DB structure, but I have not found any mention of having separate
database for each blog/user.
So, my question is, which one is performance better (talking about
1000 blogs):
a) 1000 blogs * 5 (let's say we will have tables like comments,
post... for each blog) = 5000 tables in one database
... this is Wordpress default
b) 1000 databases (for each blog) each having 5 tables
c) 5 databases by 1000 tables - in this case, won't this be an issue
when SELECTing like this: [db_comments].testblog, [db_posts].testblog ?
Is that a controversial topic? :-/
Thanks for ideas,
Martin
