Thanks Tim, this helped me a lot.
Martin
Tim Hawkins napsal(a):
If you are looking at future expansion then the separate DB per blog is
defiantly the way to go.
Some notes:
1) Avoid joins like the plague, in fact most operations on a blog
application would consist of getting primary
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 -
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
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
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
If it were Oracle I'd go with one database and separate schema for each
blog.
For Mysql I think I'd go for a database each blog.
Jack
2008/9/28 Martin Zvarík [EMAIL PROTECTED]
Hi,
I am working on a blog system and I am currently thinking of what would be
the best DB approach.
I have read
If you are looking at future expansion then the separate DB per blog
is defiantly the way to go.
Some notes:
1) Avoid joins like the plague, in fact most operations on a blog
application would consist of getting primary record and then
decorating it with secondary data, for example
