Data base driven web page idea - need help!

Data base driven web page idea - need help!

Post by Grant Coope » Thu, 28 Nov 2002 14:39:32



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?

Thanks in advance, I plan on doing alot of planning and really apreciate
reading this email.

---------------------------------------------------------------------
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/           (the list archive)



Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

 
 
 

Data base driven web page idea - need help!

Post by DL Nei » Thu, 28 Nov 2002 17:59:18


Grant,

Quote:> 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?

=Most use LAMPs (Linux (sorry of that is not quite kosher for FreeBSD),
Apache, MySQL, and PHP) to create DYNAMIC web sites. As such, every query
from a user results in a back-end database interaction. Amazon, Yahoo,
Google, etc have large back-end databases and thousands of (concurrent)
users and every 'click' requires a database interaction.

=In your case, the transaction rate will be significantly lower, even if the
volume-transmitted per click may be "large".

=Database retrieval and PHP formatting speeds are insignificant when
compared to Internet transmission speeds - and even bulk text/page downloads
over a campus network.

Quote:> 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?

=caching seems like a reasonable approach, where possible. Remember though,
there is a lot of effort involved in managing that overnight process!

=Can I assume that the information doesn't change frequently?

=You talk in terms of "large". Can you quantify this?

=Instead of caching, could you have your authors develop the basic program
description pages as static HTML? Then your database has no need to store
page-data, but only a filename: when the end-user requests information, the
database chooses a file, and PHP instructs Apache to display same. Much the
same as you have described above, but with fewer management headaches!?

=You seem to be saying that there will only be one or two types of query
that the system will face. Correct? If I'm off-base, then perhaps more
description might help attune...

Quote:> Is this standard practice, if not what would be a better way of doing
this.
> This college has about 1600 students?

> Thanks in advance, I plan on doing alot of planning and really apreciate
> reading this email.

=Concur. It is cheaper to make planning changes/mistakes at this level, than
to get an ugly surprise in the coding/testing phases!

Regards,
=dn

---------------------------------------------------------------------
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/           (the list archive)



Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

 
 
 

Data base driven web page idea - need help!

Post by Grant Coope » Thu, 28 Nov 2002 19:12:06


This is correct, only two types of queries. Updating and Deleting.

Quote:> =Can I assume that the information doesn't change frequently?

This is correct. The plan is to stream line the web site and get the
information out faster and cut out the red tape. We were thinking intern's
from each department, no matter how computer illiterate they are could open
a GUI or Web interface to change there data.

Quote:> =You talk in terms of "large". Can you quantify this?

A normal class outline, shouldn't be no more than 9,999.

That file idea of your is interesting I will have to sleep on it. Thanks for
your input. I'm a one man team developing this and I've been sinful. This is
the time God's going to punish me if this blows up in my face. hehe.

----- Original Message -----


Sent: Wednesday, November 27, 2002 12:55 AM
Subject: Re: Data base driven web page idea - need help!

> Grant,

> > 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?

> =Most use LAMPs (Linux (sorry of that is not quite kosher for FreeBSD),
> Apache, MySQL, and PHP) to create DYNAMIC web sites. As such, every query
> from a user results in a back-end database interaction. Amazon, Yahoo,
> Google, etc have large back-end databases and thousands of (concurrent)
> users and every 'click' requires a database interaction.

> =In your case, the transaction rate will be significantly lower, even if
the
> volume-transmitted per click may be "large".

> =Database retrieval and PHP formatting speeds are insignificant when
> compared to Internet transmission speeds - and even bulk text/page
downloads
> over a campus network.

> > 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?

> =Instead of caching, could you have your authors develop the basic program
> description pages as static HTML? Then your database has no need to store
> page-data, but only a filename: when the end-user requests information,
the
> database chooses a file, and PHP instructs Apache to display same. Much
the
> same as you have described above, but with fewer management headaches!?

> =You seem to be saying that there will only be one or two types of query
> that the system will face. Correct? If I'm off-base, then perhaps more
> description might help attune...

> > Is this standard practice, if not what would be a better way of doing
> this.
> > This college has about 1600 students?

> > Thanks in advance, I plan on doing alot of planning and really apreciate
> > reading this email.

> =Concur. It is cheaper to make planning changes/mistakes at this level,
than
> to get an ugly surprise in the coding/testing phases!

> Regards,
> =dn

> ---------------------------------------------------------------------
> Before posting, please check:
>    http://www.mysql.com/manual.php   (the manual)
>    http://lists.mysql.com/           (the list archive)


> To unsubscribe, e-mail


Quote:> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

---------------------------------------------------------------------
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/           (the list archive)



Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

 
 
 

Data base driven web page idea - need help!

Post by Adam Erickso » Thu, 28 Nov 2002 19:15:58


Quote:> Here's my QUESTION! Because some of the program information is
> large I don't
> want to query the data base everytime do I?

Define large?  Are we talking mixed media types (PDF/Word/PowerPoint) or
plain text/HTML?  As someone has already suggested, you might be better to
save the files on the disk and store the filenames in the database instead.

Then again, you said "some" of the information is large.  What's the ratio?
If it's small enough, fitting it in the DB might not be so bad.  Depends on
the hardware.

Since you're pulling static pages from disk, not SQL, it would probably
scale better.

Always looking for a challenge, I would look at the kind of data you're
dealing with.  If it's of similar format, you may be able to create a SQL
strucutre that would allow more flexibility with your data.  Render the data
in different views where applicable or at least enforce a theme on your
system.  Of couse, XML/XSLT is more suitable for that....  and I've gone way
overboard...

Quote:> This would take up to many resources. So I've decided to write a program
...
> every night and remove the old ones through a cron job?

If you're eager to store it all in the database, I would do so.  It doesn't
sound like this stuff is going to change often.  Throw a reverse-proxy squid
in front of apache.  Even running on the same machine will help a LOT.

Avoid cronjobs and nightly generated static files.  That practice does NOT
scale and can be very difficult to manage.

---------------------------------------------------------------------
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/           (the list archive)



Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

 
 
 

Data base driven web page idea - need help!

Post by DL Nei » Thu, 28 Nov 2002 19:46:10


Grant,

Quote:> This is correct, only two types of queries. Updating and Deleting.

=deleting is a trivial exercise, whether the data is held in a db or file.

=updating is more of an exercise for the content managers than it is for
you...

Quote:> > =Can I assume that the information doesn't change frequently?
> This is correct.

=this is both a 'win' and a 'loss': it eases the technical side, but for the
user/authors the less frequently they 'do it', the more time between for any
techniques, rules, standards... to be forgotten!

The plan is to stream line the web site and get the

Quote:> information out faster and cut out the red tape. We were thinking intern's
> from each department, no matter how computer illiterate they are could
open
> a GUI or Web interface to change there data.

=in which case, continuing the static file theme, I would give serious
thought to ascertaining which tools these people can be expected to already
be familiar. There are a number of HTML-hiding editors/authoring tools 'out
there', eg (R18 warning) FrontPage or even MS-Word. Don't be tempted to
re-invent the editor-wheel...

=another possibility would be a BB system (recently discussed on the PHP
list) or a 'wiki' (specifically designed to 'get data out there quickly',
but tend to be less structured/less geared to a template/'common look and
feel'/marketing-brand approach/straight-jacket)...

Quote:> > =You talk in terms of "large". Can you quantify this?
> A normal class outline, shouldn't be no more than 9,999.

=unfortunately no 'units'. If you are talking bytes or even lines; then with
respect this is trivial stuff for LAMPs on even modest hardware. It sounds
like a lot on paper, but web servers are fleet of foot!

=although if you are talking bytes/characters you might consider splitting
such pages into more than one web page - an 'average' sheet of A4/A paper is
(round numbers) going to present 2KB. So you appear to be talking of 4~5
pages of data. Imagine that presented as a single screen-load and ask if it
seems appropriate for the application...

Quote:> That file idea of your is interesting I will have to sleep on it. Thanks
for
> your input. I'm a one man team developing this and I've been sinful. This
is
> the time God's going to punish me if this blows up in my face. hehe.

="one man...sinful"???
No, I'm not going there...
=dn

> ----- Original Message -----


> Sent: Wednesday, November 27, 2002 12:55 AM
> Subject: Re: Data base driven web page idea - need help!

> > Grant,

> > > 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?

> > =Most use LAMPs (Linux (sorry of that is not quite kosher for FreeBSD),
> > Apache, MySQL, and PHP) to create DYNAMIC web sites. As such, every
query
> > from a user results in a back-end database interaction. Amazon, Yahoo,
> > Google, etc have large back-end databases and thousands of (concurrent)
> > users and every 'click' requires a database interaction.

> > =In your case, the transaction rate will be significantly lower, even if
> the
> > volume-transmitted per click may be "large".

> > =Database retrieval and PHP formatting speeds are insignificant when
> > compared to Internet transmission speeds - and even bulk text/page
> downloads
> > over a campus network.

> > > 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?

> > =Instead of caching, could you have your authors develop the basic
program
> > description pages as static HTML? Then your database has no need to
store
> > page-data, but only a filename: when the end-user requests information,
> the
> > database chooses a file, and PHP instructs Apache to display same. Much
> the
> > same as you have described above, but with fewer management headaches!?

> > =You seem to be saying that there will only be one or two types of query
> > that the system will face. Correct? If I'm off-base, then perhaps more
> > description might help attune...

> > > Is this standard practice, if not what would be a better way of doing
> > this.
> > > This college has about 1600 students?

> > > Thanks in advance, I plan on doing alot of planning and really
apreciate
> > > reading this email.

> > =Concur. It is cheaper to make planning changes/mistakes at this level,
> than
> > to get an ugly surprise in the coding/testing phases!

> > Regards,
> > =dn

> > ---------------------------------------------------------------------
> > Before posting, please check:
> >    http://www.mysql.com/manual.php   (the manual)
> >    http://lists.mysql.com/           (the list archive)


> > To unsubscribe, e-mail

> > Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

> ---------------------------------------------------------------------
> Before posting, please check:
>    http://www.mysql.com/manual.php   (the manual)
>    http://lists.mysql.com/           (the list archive)


> To unsubscribe, e-mail


Quote:> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

---------------------------------------------------------------------
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/           (the list archive)



Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

 
 
 

Data base driven web page idea - need help!

Post by Michael T. Babcoc » Thu, 28 Nov 2002 23:27:03



> Here's my QUESTION! Because some of the program information is large I don't
> want to query the data base everytime do I?

Profile it first.  You may find MySQL handles the load just fine on the hardware
you're using and you don't need any such fancy tricks.  You may also find that
simply adding Expires: headers to your output on the cacheable pages means that
you get fewer queries (and have the same effect as static pages).

FWIW, I use ETag's as well which I make an MD5 hash of the latest TIMESTAMP in
the tables being queried.  This allows the browser to check if the ETag has
changed for a page when requesting it, have the server do a very simple query to
find out if it should rebuild the page or not, and let the browser use the cached
page if not.
--
Michael T. Babcock
CTO, FibreSpeed Ltd.     (Hosting, Security, Consultation, Database, etc)
http://www.fibrespeed.net/~mbabcock/

---------------------------------------------------------------------
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/           (the list archive)



Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

 
 
 

Data base driven web page idea - need help!

Post by Matthew Baranowsk » Fri, 29 Nov 2002 02:56:25


Hi Grant:

The answer to your question depends on a lot of details. In most cases, the
solution you have chosen is just fine. The real question you need to answer
is, "Does your solution meet your needs?" If you can answer yes to this
question, your solution is fine.

Your solution gives you a couple of advantages:
1. As you said, fewer hits against the database.
2. Faster downloads for your user. Static HTML pages download faster than a
dynamic alternative.
3. Static pages will get crawled and added to search engines; sometimes
dynamic pages won't.

Some disadvantages:
1. You have a delayed update to your Web page. If a faculty member notices a
critical error on a Web page, they must contact you or otherwise figure out
how to trigger an update.
2. There are things you can do with a dynamic page that you cannot do with a
static page.

Quote:> Here's my QUESTION! Because some of the program information is large I
don't
> want to query the data base everytime do I?

Like I said, your solution will probably work just fine, but it is probably
unnecessary. You say the program information is large, but it would have to
really REALLY large for it to make much difference. With a college of 1600
students, it does not sound like your Web site is going to have much
traffic.  Php and MySQL are pretty efficient.

My advice is to test your assumptions; does retrieving the large Web pages
from the database make much difference?

Good luck,

Matt

Matthew P Baranowski
Data Manager, Office of Educational Assessment
University of Washington

----- Original Message -----


Sent: Tuesday, November 26, 2002 10:38 PM
Subject: Data base driven web page idea - need help!

> 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?

> Thanks in advance, I plan on doing alot of planning and really apreciate
> reading this email.

> ---------------------------------------------------------------------
> Before posting, please check:
>    http://www.mysql.com/manual.php   (the manual)
>    http://lists.mysql.com/           (the list archive)


> To unsubscribe, e-mail


Quote:> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

---------------------------------------------------------------------
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/           (the list archive)



Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

 
 
 

Data base driven web page idea - need help!

Post by Benjamin Pflugma » Fri, 29 Nov 2002 05:43:08


Hi.


Quote:> 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.

--

---------------------------------------------------------------------
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/           (the list archive)



Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

 
 
 

Data base driven web page idea - need help!

Post by Michael T. Babcoc » Fri, 29 Nov 2002 07:07:37



> 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.)

As someone who uses 5 & 6 together quite often (as suggested), I can
tell you it works very well (and very responsively).  Your point about
oft-used pages is interesting, but it only applies in a special
circumstance that, in my experience, doesn't happen often (although
Slashdot does consider this):

If a page would require significant database resources and the source
information changes more rarely than the data is accessed and/or the
data may be accessed when it is inconvenient to load the database
server with such a query, generating the page offline and storing it
makes sense (like the Slashdot archived stories).

In most cases, however, doing no caching at all is sufficient and
allowing client-side caching takes the load off the frequently used
pages (which is all you really care about usually) and adding Squid or
Apache doing caching in front of your live server takes away hits to
the same data from multiple requestors.

Quote:> 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.

I agree with this, personally.

--
Michael T. Babcock
CTO, FibreSpeed Ltd.     (Hosting, Security, Consultation, Database, etc)
http://www.fibrespeed.net/~mbabcock/

---------------------------------------------------------------------
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/           (the list archive)



Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

 
 
 

Data base driven web page idea - need help!

Post by Grant Coope » Fri, 29 Nov 2002 08:06:56


Thanks you very much for all your suggestions. I really appreciate it.

Grant Cooper

----- Original Message -----


Sent: Wednesday, November 27, 2002 9:23 AM
Subject: Re: Data base driven web page idea - need help!

> Hi Grant:

> The answer to your question depends on a lot of details. In most cases,
the
> solution you have chosen is just fine. The real question you need to
answer
> is, "Does your solution meet your needs?" If you can answer yes to this
> question, your solution is fine.

> Your solution gives you a couple of advantages:
> 1. As you said, fewer hits against the database.
> 2. Faster downloads for your user. Static HTML pages download faster than
a
> dynamic alternative.
> 3. Static pages will get crawled and added to search engines; sometimes
> dynamic pages won't.

> Some disadvantages:
> 1. You have a delayed update to your Web page. If a faculty member notices
a
> critical error on a Web page, they must contact you or otherwise figure
out
> how to trigger an update.
> 2. There are things you can do with a dynamic page that you cannot do with
a
> static page.

> > Here's my QUESTION! Because some of the program information is large I
> don't
> > want to query the data base everytime do I?

> Like I said, your solution will probably work just fine, but it is
probably
> unnecessary. You say the program information is large, but it would have
to
> really REALLY large for it to make much difference. With a college of 1600
> students, it does not sound like your Web site is going to have much
> traffic.  Php and MySQL are pretty efficient.

> My advice is to test your assumptions; does retrieving the large Web pages
> from the database make much difference?

> Good luck,

> Matt

> Matthew P Baranowski
> Data Manager, Office of Educational Assessment
> University of Washington

> ----- Original Message -----


> Sent: Tuesday, November 26, 2002 10:38 PM
> Subject: Data base driven web page idea - need help!

> > 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?

> > Thanks in advance, I plan on doing alot of planning and really apreciate
> > reading this email.

> > ---------------------------------------------------------------------
> > Before posting, please check:
> >    http://www.mysql.com/manual.php   (the manual)
> >    http://lists.mysql.com/           (the list archive)


> > To unsubscribe, e-mail

> > Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

> ---------------------------------------------------------------------
> Before posting, please check:
>    http://www.mysql.com/manual.php   (the manual)
>    http://lists.mysql.com/           (the list archive)


> To unsubscribe, e-mail


Quote:> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

---------------------------------------------------------------------
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/           (the list archive)



Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

 
 
 

Data base driven web page idea - need help!

Post by hoo.. » Fri, 29 Nov 2002 10:12:28


Quote:> 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?

I've got a web site which takes just this approach, but there are pros and cons
with it.

The upside, is that if most of the information is fixed, then you're
swapping database accesses and the overhead of a CGI script for a simple
'GET' request. It clearly works best when the rate of change for the raw
data is relatively low, because it implies that you generate the page(s)
once but server them up many times.

The downside is the delay between entering new data and it being
available on the site. In some applications this may be critical.

The method that I used is to record a timestamp every time the database
is updated, to have a script running permanently in the background
looking at this timestamp. If it's greater than zero and more than 5
minutes old, the pages get regenerated and the timestamp is then set to
zero again.

The reason that I chose this approach is that updates are relatively
rare (a dozen or so times a week), but the hit rate on the site is
orders of magnitude higher. Also, it gave scalability at lower cost than
tuning CGI scripts and the Apache server environment.

The underlying point though, is that you need to look at the pattern of
both accesses to the site and updates to the database and decide based
on that.

The site I'm talking about is here :  www.pubfun.com if you feel a need
to look round.

Paul Wilson
Chime Communications

---------------------------------------------------------------------
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/           (the list archive)



Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php