views:

565

answers:

5

I'm going to be implementing a lightweight formatting language (probably Textile, maybe Markdown) in a project I'm working on, and I'm wonder how best to store it in the database.

If the user is able to edit the content they're posting, it makes sense to me that the original, non-converted markup be stored so that the user doesn't have to edit HTML the next time around. But since the content is going to be displayed a whole lot more than edited, it also makes sense to store a converted copy of the content so that the original doesn't have to be sent through Textile on every page view.

So, is the common practice to store both the original and converted content side-by-side in the database? Is there a better way?

Thanks!

A: 

You should definetly store original Textile/Markdown markup and use either standard HTTP caching stuff (Last-modified, Expires-At, ETag) to cache rendered pages or just cache the result of processing markup.

Anton Gogolev
A: 

I'm currently using Markdown with PHP. I store the markdown-source in the database, and I display the Converted Version upon request. I have no performance issues, and am very happy with this setup.

Jonathan Sampson
+2  A: 

What I've seen is indeed to store the compiled HTML in a seperate row in the database. Just have one row 'content' and another 'content_html', and save the compiled HTML in the 'content_html' row.

(Surely you have some kind of save method that you can override to do this?)

winsmith
+5  A: 

Store markdown:

  • Every view = conversion
  • Every edit = no processing

Store html

  • Every view = no processing
  • Every edit = convert to markdown and back

Store both

  • Every view = no processing
  • Every edit = convert to html after edit

You have to weigh up your processing costs vs. your storage cost.

ck
A: 

I've put up a little survey to see what people prefer for markup here: http://luciddesign.co.nz/2009/2/9/textile-vs-markdown-vs-tinymce-etc