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!
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.
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.
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.
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?)
