Help with design issue

[Terry Murray]

Hi once again,

I have been asked to add a feature that allows a person to add content to a
site via a control panel. This control panel is basically a form that will
have certain fields such as subject, body, date. The site is supposed to
show the content that is supplied to it via the form that is part of the
control panel. I was thinking that there's a good chance that the data that
leaves the form and that is then stored in a database may not change
frequently. Because, this might be the case, would it be more efficient to
come up with a solution that would only go to the database if and only if
something has changed. I was thinking that as soon as information has been
queried from the database to appear as information on the website it should
also be turned into a static page. If it is a static page and no further
activity (addition or modification of existing control panel information)
has occurred then it would be more efficient to grab the static html page
rather than query the database and possibly retrieve information that has
not been modified.

Is this solution a viable one and if so how could it be implemented?

I think there is a file system object something-or-the-other that perhaps
could be used to create the html file on the server. Maybe I could keep
track of the last modification date of this file or creation date and
compare it to the last date of the data that was inserted in the database.

Any suggestions

Thanks in advance

Terry

[Ray at]

I personally would never do this. It would over complicate things and
potentially cause inconsistencies. Keep your data in one place instead of
trying to "manually mirror" it. I suggest using the database. I understand
what you mean that if it doesn't change much, it's a waste, but it's either
have the server do the work for you or hire an HTML monkey to make
infrequent updates to static html pages.

Ray at work

"Terry Murray" <tgmurray@rogers.com> wrote in message
news:f318b.963$Rm1.263@news02.bloor.is.net.cable.r ogers.com...

> Hi once again,
>
> I have been asked to add a feature that allows a person to add content to

a

> site via a control panel. This control panel is basically a form that

will

> have certain fields such as subject, body, date. The site is supposed to
> show the content that is supplied to it via the form that is part of the
> control panel. I was thinking that there's a good chance that the data

that

> leaves the form and that is then stored in a database may not change
> frequently. Because, this might be the case, would it be more efficient to
> come up with a solution that would only go to the database if and only if
> something has changed. I was thinking that as soon as information has

been

> queried from the database to appear as information on the website it

should

> also be turned into a static page. If it is a static page and no further
> activity (addition or modification of existing control panel information)
> has occurred then it would be more efficient to grab the static html page
> rather than query the database and possibly retrieve information that has
> not been modified.
>
> Is this solution a viable one and if so how could it be implemented?
>
> I think there is a file system object something-or-the-other that perhaps
> could be used to create the html file on the server. Maybe I could keep
> track of the last modification date of this file or creation date and
> compare it to the last date of the data that was inserted in the database.
>
> Any suggestions
>
> Thanks in advance
>
> Terry
>
>
>

[Jeff Cochran]

On Thu, 11 Sep 2003 16:05:31 GMT, "Terry Murray" <tgmurray@rogers.com>
wrote:

>I have been asked to add a feature that allows a person to add content to a
>site via a control panel. This control panel is basically a form that will
>have certain fields such as subject, body, date. The site is supposed to
>show the content that is supplied to it via the form that is part of the
>control panel. I was thinking that there's a good chance that the data that
>leaves the form and that is then stored in a database may not change
>frequently. Because, this might be the case, would it be more efficient to
>come up with a solution that would only go to the database if and only if
>something has changed.

Well, you have to go to the database to get the data you'll compare to
see if it's changed anyway...

>I was thinking that as soon as information has been
>queried from the database to appear as information on the website it should
>also be turned into a static page. If it is a static page and no further
>activity (addition or modification of existing control panel information)
>has occurred then it would be more efficient to grab the static html page
>rather than query the database and possibly retrieve information that has
>not been modified.

Why double the work and data storage requirements?

>Is this solution a viable one and if so how could it be implemented?

Viable, maybe. Can it be implemented? Sure. Is it smart? I
wouldn't say that.

>I think there is a file system object something-or-the-other that perhaps
>could be used to create the html file on the server. Maybe I could keep
>track of the last modification date of this file or creation date and
>compare it to the last date of the data that was inserted in the database.

Oh yeah, instead of checking the database for modified material, you
check it to see if the data has been changed since you were last on,
then if it has, write out new files for static use. You're way
overcomplicating what is essentially a straight-forward design.

>Any suggestions

Optimize the data and normalize the databases before you start looking
at gaining any performance from this type of convoluted setup.

Jeff

[Terry Murray]

Hi again. And a particular thanks to Jeff for his thoughts. I was
wondering, Jeff, if the following changes the situation. Lets suppose that
the changes to the site that would occur through the control panel would
only take effect on the site at an actual time on any given day. Would my
solution have any more credibility now? I am still thinking that there are
tradeoffs to be gained by having to spend less time opening and closing
connections to the database for information that will essentially have not
changed for at least one day and most likely longer than that. I am not
sure how many visitors this site is anticipated to have yet but perhaps that
makes a difference. Essentially, a check will have to be performed once per
day at a specified time to check the date in the database and the date of
the previously created static file. If the date in the database is newer
grab the information required, create a static page and start using that
page from that moment forward until the next day at that same time it has
been determined that there is "newer" information.

The situation might even be more plausible given the fact that the
information contained in the site might be used for navigation in the site
as well rather than just straight forward content.

I am not sure if what I have just related changes anything.

Thanks
Terry

"Jeff Cochran" <jcochran.nospam@naplesgov.com> wrote in message
news:3f77c2a8.798970448@msnews.microsoft.com...

> On Thu, 11 Sep 2003 16:05:31 GMT, "Terry Murray" <tgmurray@rogers.com>
> wrote:
>

> >I have been asked to add a feature that allows a person to add content to

a

> >site via a control panel. This control panel is basically a form that

will

> >have certain fields such as subject, body, date. The site is supposed to
> >show the content that is supplied to it via the form that is part of the
> >control panel. I was thinking that there's a good chance that the data

that

> >leaves the form and that is then stored in a database may not change
> >frequently. Because, this might be the case, would it be more efficient

to

> >come up with a solution that would only go to the database if and only if
> >something has changed.

>
> Well, you have to go to the database to get the data you'll compare to
> see if it's changed anyway...
>

> >I was thinking that as soon as information has been
> >queried from the database to appear as information on the website it

should

> >also be turned into a static page. If it is a static page and no further
> >activity (addition or modification of existing control panel information)
> >has occurred then it would be more efficient to grab the static html page
> >rather than query the database and possibly retrieve information that has
> >not been modified.

>
> Why double the work and data storage requirements?
>

> >Is this solution a viable one and if so how could it be implemented?

>
> Viable, maybe. Can it be implemented? Sure. Is it smart? I
> wouldn't say that.
>

> >I think there is a file system object something-or-the-other that perhaps
> >could be used to create the html file on the server. Maybe I could keep
> >track of the last modification date of this file or creation date and
> >compare it to the last date of the data that was inserted in the

database.

>
> Oh yeah, instead of checking the database for modified material, you
> check it to see if the data has been changed since you were last on,
> then if it has, write out new files for static use. You're way
> overcomplicating what is essentially a straight-forward design.
>

> >Any suggestions

>
> Optimize the data and normalize the databases before you start looking
> at gaining any performance from this type of convoluted setup.
>
> Jeff

[Jeff Cochran]

On Fri, 12 Sep 2003 10:54:17 GMT, "Terry Murray" <tgmurray@rogers.com>
wrote:

>Hi again. And a particular thanks to Jeff for his thoughts. I was
>wondering, Jeff, if the following changes the situation. Lets suppose that
>the changes to the site that would occur through the control panel would
>only take effect on the site at an actual time on any given day. Would my
>solution have any more credibility now?

perhaps. But we're looking at the basic concept of the site, and one
of the main reasons for serving out of the database is that it's
dynamic, and normally, real-time. I would think if a change was
important enough to put into the system, it would be important enough
to be available right now. Otherwise, let everyone use Word and "Save
As HTML" to do their jobs, and skip the control panel idea.

>I am still thinking that there are
>tradeoffs to be gained by having to spend less time opening and closing
>connections to the database for information that will essentially have not
>changed for at least one day and most likely longer than that.

There are. But they're miniscule. And when you get to the point
where the only possible improvement in performance is reducing the
opening and closing of connections, then it's time to buy better
hardware, more bandwidth or something else. The reduction in number
of database reads isn't as much an issue as how long the read takes
and what's being returned. Use SQL views and stored procedures, and
possibly even temporary tables to solve that issue.

>I am not
>sure how many visitors this site is anticipated to have yet but perhaps that
>makes a difference.

Big difference. A dozen reads of your database an hour makes this a
non-issue. Hitting it with 100,000 requests a minute might.

>Essentially, a check will have to be performed once per
>day at a specified time to check the date in the database and the date of
>the previously created static file. If the date in the database is newer
>grab the information required, create a static page and start using that
>page from that moment forward until the next day at that same time it has
>been determined that there is "newer" information.

You could publish the entire site as static every evening if you
wanted. That defeats the idea of a dynamic site, but this is all
theoretical since we don't know thw nature of the data anyway.
medical records you'd want the latest changes immediately available.
A database of your daughter's Barbie collection may be less demanding.

>The situation might even be more plausible given the fact that the
>information contained in the site might be used for navigation in the site
>as well rather than just straight forward content.

Not really. How thw data is used isn't really an issue.

>I am not sure if what I have just related changes anything.

To me, no. But it's not my project, and fundamentally there's no
reason what you propose wouldn't work. To me it's more effort on the
part of the programmer and in maintaining it than any benefit that
would be derived.

Jeff