Grant, > 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... > > =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 > 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)... > > =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... > 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 ----- > From: "DL Neil" <[EMAIL PROTECTED]> > To: "Grant Cooper" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > 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 request this thread, e-mail <[EMAIL PROTECTED]> > > To unsubscribe, e-mail > <[EMAIL PROTECTED]> > > 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 request this thread, e-mail <[EMAIL PROTECTED]> > To unsubscribe, e-mail <[EMAIL PROTECTED]> > 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 request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
