Re: HTML storage
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 |