Plan A The HTML is already built and never changes.
Store only a url in the database, then tell the browser to go reach for that url. That, after all, is how images are done.
As with images, half the gurus will recommend storing the pages in the database, not as separate files. That's a separate debate. (It has been hashed out many times, but never really settled.)
Plan B You are creating the HTML on the fly.
In this case, you need the text accessible for assembly. It may involve dozens or hundreds of records scattered around various tables, especially since you include "lists". Now the html is just bits and pieces. You still have an important choice to make.
- If the text in the tables is only text, no markup, then call
htmlentities() (or equivalent) after fetching the text and before surrounding it with html tags.
- If the text necessarily contains embedded html tags, then think of the strings as opaque blobs that you are concatenating together to build the page.
- If you try to do some of each, you are likely to stumble an make a mess.
When you have big chunks of text in a table, it will usually be more efficient to compress it in the client, then store in a