Storing Templates and Object-Oriented vs Relational Databases
Please do Not Store templates (that might be altered by a user) in a database. There's no sane way to migrate from a staging environment to production if you have to deal with doffs of database dumps. We are dumping some software right one for this very reason.
Apart from that I'd simply store the source (user editable part) in the database plus a "precompiled version" either directly in the database (for faster retrieval) or in some cache system.
I'd personally go with a set theory approach.

Store each set of content type precompiled and recompile it when edited for fast serving in a separate place (table, collection, directory, whatever)
Store the sources in a common place to make it easy to rebuild different content types (the source format really just is a special case content type)
keep the templates in a place where migration between systems (dev, staging, prod) makes migration easy
I'm designing some custom blog software, and have run into a conundrum regarding database design.  The software requires that there be multiple content types, each of which will require different entry forms and presentation templates.
My initial instinct is to create these content types as objects, then serialize them and store them in the database as JSON or YAML, with the entry forms and templates as simple strings attached to the "contentTypes" table.  This seems cumbersome, however.  Are there established best practices for dealing with this design?  Is this a use case where I should consider an object database?
If I should be using an object database, which should I consider?  I am currently working in Python and would prefer a capable Python library, but can move to Java if need be.