Hi.
On Tue 2002-11-26 at 22:38:56 -0800, [EMAIL PROTECTED] wrote:
> I need help. I am building a database for a small college that wants to be
> able to update their program information for each department through an
> web/gui program.
>
> I've decided to use, MYSQL, Apache, PHP and FreeBSD as the OS. (I built my
> web page this way)
>
> Here's my QUESTION! Because some of the program information is large I don't
> want to query the data base everytime do I?
>
> This would take up to many resources. So I've decided to write a program
> that will take the information from the MYSQL tables and build static pages
> every night and remove the old ones through a cron job?
>
> How does this sound?
>
> Is this standard practice, if not what would be a better way of doing this.
> This college has about 1600 students?
There are always several possible solutions and which one is the right
for you depends on many factors you have not told us.
Regardless which solution you choose in the end, try to get usage
numbers from the current college program pages (hits/day) and build a
test database and a minimal prototype regarding your solution and see
if it is able to scale to the usage numbers you got. Do not forget to
take into account special times of days (max usage is often 3 times
higher than average) and special times of year (I presume there
are times in school year, when the college program is accessed much
more often).
That said, some let's consider some possibilities:
1. As you said, one solution is to simply make dynamic PHP pages. You
presume that this will be too slow, but be sure that this is indeed
the case (PHP+MySQL are quite capable), because this is the
solution that makes the least work. In short: least work, scales
worst, always up to date.
2. As you also said, you could create static pages at night. That is
the other extreme (the following points are somewhere in between).
Regarding the fact that the college program probably will not
change often, this sounds like a reasonable approach, should be
fast enough for sure, but also means quite a bit more work, as it
is not easy to get it correct all time. Most work, scales best, up
to 24 hours out of date.
3. A variant of 2: Build the static pages when a database entry
changes (i.e. on push). Whether this is feasible and how many work
it makes depends on how many pages are affected by a change. It
scales a little bit worse than 2., but should be still good enough
by far and has the advantage that the pages are always up to
date. If only one or two pages are affected by a change it is more
reasonable than 2. for sure. Creating the static pages the first
time needs some handiwork. Much work (depends on changed pages),
scales almost best, always up to date.
4. This is a hybrid: Create cached pages/parts, but save them in the
database (or disk, if you like more) and display them via PHP
(there is a PHP to support for that, IIRC). You can see that as a
variant of 1., just with the additional benefit of some
caching. Cache pages would be created on request, if the page is
not cached yet or outdated meanwhile (on pull). This solution fits
best if the data changes often (where 2. would be a big no-no), but
scales bad on restart. Medium work, scales good, always up to date.
5. Another hybrid: Do not create the cache pages yourself. Simply
build the back-end as in solution 1. and put a caching proxy
(e.g. squid) before it. The main drawback in comparison with.
Depending on proxy, may scale bad on restart. Depending on
configuration and usage may even be faster than 2. Is as out of
date as you configure it to be: the more current the pages shall
be, the worse it scales (because it less often hits the
cache). Medium work, scales good, actuality: as configured.
6. As 1., but allow client-side caching of pages. This only has
positive effects on reloads or often visited pages. Least work,
scales bad, actuality: as configured (same as 5.)
Since 1. allows to continue with 6., 5. and 4., I suggest to start
with solution 1. and then continue as much as need arises.
Bye,
Benjamin.
--
[EMAIL PROTECTED]
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
