Re: Technique Efficiancy

Interacting with a DB is very helpfull if you have information that changes very often or is displayed depending on the client.
OK, if you have lets say technical documentation for 50 tools and you store those in your DB and all clients shall get the same information then it would be waste of server power to let it generate documents on each request.
Even your server might cache the results of these queries the documents would be generated more often than it needs to be done.
Therefore I suggest the following:
Create somewhat like an admin script to compare the mod date of your generated files with an field in your DB holding the date or better timestamp when the info in that datafield changed. If the document you have is older than the info, the document should be deleted and newly be generated with the new info (thats easier than changing that document).
If you don't want to invoke that script manually you could tell your scripts that modify the data in your DB to check if the data changed will effect your documents and if it should invoke the update script (or function or procedure if you like to work with objects here).
And you could also perform another check (here might be better to use a cronjob) to look up templates you use to generate your documents from, cause if these changed, you'll have to let all documents be done again.
For example:

,---------------------.
| header              |
`---------------------´
|m |                  |
|e | tooldoc_31       |
|n |                  |
|u |                  |
`---------------------´
| footer              |
`---------------------´
[download]

This is quite easy for you if your server does support Server Side Includes (SSI).
eg.: 
But be aware that the result of this must be an valid HTML or XML document (or whatever mime-type) you want to send to the clients browser.
This is only an example for a dir structure:

httpd/
|
.
.
`-static/
| `-help/
| `-about/
`-dynamic/
| `-toolviews/ (so here could go the generated content)
| `-menus/ (they might change with your content)
`-includes/
| `-general/ (e.g. header, footer, and stuff that occurs very often)
| `-menus/ 
`-templates/
| `-section_a/
| `-section_b/
.
.
[download]

Have a nice day
All decision is left to your taste

Comment on Re: Technique Efficiancy Select or Download Code

Replies are listed 'Best First'.
Re (tilly) 2: Technique Efficiancy by tilly (Archbishop) on Apr 22, 2001 at 00:55 UTC
Before you do this, ask yourself why. This scheme is substantially more complex than just hitting the database. There are more files. If you ever need to reproduce the installation, it is not always obvious where to get them from. With things scattered around it will take longer for people to learn the system. Plus you have all sorts of possible synchronization errors. For instance you change where the files are dumped, but somewhere you still have a reference to an old location that appears to work because the file is there...then a month later you delete that and have to figure out how it ever worked. Or you lose a cron and then find out a couple of months later what it was for. Or someone decides to refresh a file with a long-running daemon which doesn't survive a reboot 6 months later. In short there are a lot of possible failure modes. Most of them won't happen to you, and they won't happen often. But why let them happen at all? That said, this can work and there are good reasons to go with a design like that. Certainly if I needed to run a high-performance website, I would look to something like that to offload work to static content that can be readily distributed across a cluster. But I wouldn't choose to make my life more complex up front when I had a choice.	[reply]
Re: Re (tilly) 2: Technique Efficiancy by little (Curate) on Apr 22, 2001 at 01:05 UTC
good point, I did it already this way once because we where producing HTML and PDF files. And to be honest I did it in this way because I wanted to do so. I wanted to try it, if it works and I made a nice frontend to it for the administration. But I "spread" the files because I don't want anyone to edit a document when all his changes would be overwritten with the next update of the content. Ok, the lost cronjob is a very strong concern, but are there anything alike "triggers" on a unix machine to invoke an action or script - like you have in some highly advanced RDBMS ??? So that is why I would prefer to keep those files in separate places. Ok, another reason is that automtically updated files will/might irritate the readers of cvs logs. Have a nice day All decision is left to your taste	[reply]
Re: Re: Technique Efficiancy by voyager (Friar) on Apr 22, 2001 at 00:11 UTC
Good post; one comment/observation: if you have to go to the database to get a timestamp, and make a system call to get the file timestamp, that overhead may cancel out any gain from avoiding the sql select(s) required to build the page dynamically. Other replies here made the case articulately for having the content be in the database and the page built dynamically. There are lots of subtleties, exceptions, etc., but as a first appoximation, one sql statment will usually be at least as much of a performance hit as everything else you do to build a web page. A select to get one field (i.e., timestamp) from a row and fetching html from the file system is going to be as much of a hit as selecting the whole row (assuming your row isn't many kb) and building your page on-the-fly. The sql performance hit for a keyed, single-row select is not based on band-width, but on the overhead of communicating with the sql engine. And it's probably an order of magnitude worse if you aren't maintaing db connections across page requests.	[reply]
Re: Re: Re: Technique Efficiancy by little (Curate) on Apr 22, 2001 at 00:23 UTC
but you don't need to compare on each page request - only if you update your data. Sorry, if I didn't state that clearly :-) But I assume here your observation is wrong! Continuing the tool documentation that would mean, that you might update the data may be once a week or once a month. So all queries to the DB would waste capacity, or not? If no data changed, we don't need to change the document and so we don't need to process the output for each requesting client. The only concern I have is the use of SSI. That is the point where I am afraid to loose time and if it wouldn't be better to compose the documents upon content creation. Have a nice day All decision is left to your taste	[reply]
Re: Re: Technique Efficiancy by Monolith-0 (Beadle) on Apr 21, 2001 at 20:37 UTC
That's just the sort of thing I was thinking of doing.	[reply]