Should I convert stored Markdown to HTML, or shoul

问题:

Markdown seems to be easier to write and edit than HTML. All HTML editors I've seen output a ton of unnecessary junk. Markdown seems cleaner.

Here is what I'm thinking of doing: storing markdown in the database, converting it to HTML with PHP Markdown, then outputting that to the web browser.

One problem is that it would have to do this every time a page is requested. This seems somewhat expensive.

Is this a good idea? or is there a more efficient way to do this?

回答1:

As a practical example, Stack Overflow supports Markdown (as you know), but stores both the Markdown and the rendered HTML in the database. This makes it much faster to serve pages, because the rendered HTML is always the same. Posts are created much less frequently than they are shown to users.

回答2:

Stand back from your site and ask yourself how "expensive" it really would be. Do you serve more than 1,000 uniques per day? Realistically, is it going to balloon? With all these sorts of questions, the answer isn't clear cut. For example, when I was building websites for an international bank, a non-minimized CSS document could add 1 gigabyte per day of bandwidth. However, when I'm building my portfolio site, I'm expecting a fraction of that traffic.

I'm certainly not advocating building inefficient code....just bear in mind that "cost" should really be measured as process times executions, not just process.

If you're really concerned, record before- and after- times around the execution of a PHP Markdown process. Then, track server load for a period of times in an A/B fashion. Numbers don't lie.

回答3:

You could store both. The stored markdown is useful if it must be edited multiple times, or if another or better Markdown to HTML translation is developed. The stored HTML is useful, as you say, to avoid regenerating it again and again.

回答4:

I recently completed a project very similar to what you are asking. Rather than store full-blown HTML in the database, I opted to store marked-down html on the filesystem using a proprietary API, much like MongoDB. The beauty of the storing marked-down vs full-blown is the foot-print on the filesystem is much smaller, and if you ever needed to view the raw markdown, it is much easier to read. When a user edits html, I render the full-blown so they can see what it looks like.

There have been other suggestions of storing both, which I don't quite agree with. If you are looking to improve the performance by not having to markup the marked-down version for every request, then I would consider caching the full-blown version every-time it's edited. Storing both marked-down and full-blown defeats the purpose of marking-down, as you pay the penalty in disk-space and/or database ops.