SEO

Hello,

I am writing a web application and trying to decide how to best
store/reference HTML:

Do I store just store filenames/paths in mySQL, and just use them as
references?

Or, should/can I store all of the HTML text as single string variables
within individual mySQL fields?

Any advice on this is greatly appreciated, and feel free to discuss the
respective pros/cons.

Thank you very much in advance.

-S

MidiBot@gmail.com wrote:
> Hello,
>
> I am writing a web application and trying to decide how to best
> store/reference HTML:
>
> Do I store just store filenames/paths in mySQL, and just use them as
> references?
>
> Or, should/can I store all of the HTML text as single string variables
> within individual mySQL fields?
>
> Any advice on this is greatly appreciated, and feel free to discuss the
> respective pros/cons.
>
> Thank you very much in advance.
>
> -S
>

Your question doesn't make a lot of sense unless you tell use what
you're trying to do.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

> I am writing a web application and trying to decide how to best
>store/reference HTML:
>
> Do I store just store filenames/paths in mySQL, and just use them as
>references?

Web servers generally serve *files*. You can use a database with
active scripts, but this tends to cause more overhead per hit and
makes the client's browser less able to cache static content.

> Or, should/can I store all of the HTML text as single string variables
>within individual mySQL fields?

Consider your application and maintenance. How easy is it to *edit*
and *preview* HTML stored in a single database field?

My feeling is that databases are good at storing tables of relatively
short rows and filesystems are good at storing potentially much larger
files. You should use each for what it's good at. There are intermediate
cases where it is reasonable to go either way.

Filesystems are not generally good at storing large numbers of small
files (thousands to millions and up) in a single directory. The
lookup is slow, and the minimum block size wastes a lot of disk
space. You can use a hierarchy for this (e.g. the mailbox for
gordonb is stored as g/o/gordonb.mbox), or you can use a database.

Databases may get slow (lots of disk seeking) with large records,
especially if there is a lot of access that doesn't involve the
large field in the record.

>Any advice on this is greatly appreciated, and feel free to discuss the
>respective pros/cons.

Are transactions an issue? How important is it that the description
for item #938784 change in all locations at *exactly* the same time
(which still won't guarantee that the user's browser won't fetch some
pieces before the change and some after)?

Gordon L. Burditt

Hi Gordon,

Thank you very much for your reply.

I think you convinced me that I should store references to files in my
database, instead
of the actual file text. While I don't think transactions would be
really be an issue, I am counting on having at least a couple thousand
rows, and the text files could potentially be very large.

thanks,

-S

Gordon Burditt wrote:
> > I am writing a web application and trying to decide how to best
> >store/reference HTML:
> >
> > Do I store just store filenames/paths in mySQL, and just use them as
> >references?
>
> Web servers generally serve *files*. You can use a database with
> active scripts, but this tends to cause more overhead per hit and
> makes the client's browser less able to cache static content.
>
> > Or, should/can I store all of the HTML text as single string variables
> >within individual mySQL fields?
>
> Consider your application and maintenance. How easy is it to *edit*
> and *preview* HTML stored in a single database field?
>
> My feeling is that databases are good at storing tables of relatively
> short rows and filesystems are good at storing potentially much larger
> files. You should use each for what it's good at. There are intermediate
> cases where it is reasonable to go either way.
>
> Filesystems are not generally good at storing large numbers of small
> files (thousands to millions and up) in a single directory. The
> lookup is slow, and the minimum block size wastes a lot of disk
> space. You can use a hierarchy for this (e.g. the mailbox for
> gordonb is stored as g/o/gordonb.mbox), or you can use a database.
>
> Databases may get slow (lots of disk seeking) with large records,
> especially if there is a lot of access that doesn't involve the
> large field in the record.
>
> >Any advice on this is greatly appreciated, and feel free to discuss the
> >respective pros/cons.
>
> Are transactions an issue? How important is it that the description
> for item #938784 change in all locations at *exactly* the same time
> (which still won't guarantee that the user's browser won't fetch some
> pieces before the change and some after)?
>
> Gordon L. Burditt

> I think you convinced me that I should store references to files in my
>database, instead
> of the actual file text. While I don't think transactions would be
>really be an issue, I am counting on having at least a couple thousand
>rows, and the text files could potentially be very large.

If that also means a couple of thousand files, try not to store all
of them in a single directory. That has performance issues as well.

Gordon L. Burditt