Martin Zvarík schreef:
Hi,
I am working on CMS-Blog system, which will be using approx. 10 000 users.
using them? sounds like google or M$
I have a basic question - I believe there are only two options - which
one is better?
1) having separate databases for each blog = fast
(problem: what if I will need to do search in all of the blogs for some
article?)
2) having all blogs in one database - that might be 10 000 * 100
articles = too many rows, but easy to search and maintain, hmm?
are you sure your up to it? this is basic analysis, if your stuck here
already is this system ever going to gel?
some concepts that are more helpful:
1. data sharding
2. data warehousing
3. output caching
the whole enchilda comes down to performance. there are many possible layers,
and ways to skin the cat (where is tedd anyway?)
but decent dbserver hardware (redundancy, failover??) will consider a million
records chump change (although trying to update them all via a single db transaction
will bite ... i know :-/)
---
I am thinking of having some file etc. "cms-core.php" in some base
directory and every subdirectory (= users subdomains) would include this
"cms-core" file with some individual settings. Is there better idea?
who knows, first define what exactly you require, and why then think about
logical, performant ways to implement it.
obviously a central system coupled with multiple user-bound front-end interfaces
is going to need some way of merging core settings with user specific settings.
figure out the what and the why, then try things out to see which 'how' best fits
your specific needs.
I appreciate your discussion on this topic.
Martin Zvarik
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
