Sorry for the stupid title, but I don’t know how else to name this question 🙂
So I’m trying to build a very simple content management system that stores data in the database.
One of the data types is a “content type” (similar to WordPress’s posts / custom post types).
A content type can be whatever: a page, a car listing, a comment, a book product etc.
Each content type has its own fields. For example:
- a page has the: title, text.
- a car listing has: make, model, type, year, price, …
- a book has: title, author, price
and so on…
The idea is that these content types are dynamic (and so are their fields). They would be added trough a extension of the CMS. The only built-in content type would be the page.
Anyway, I need advice on how to set up the database tables for them. This should be done from the main CMS, and not from the extensions which are supposed to be very easy to write using the CMS API.
How should I set up tables / table fields, in such a way that searching for results based on certain content type fields would be very fast?
WP uses a different table for the fields, and stores them as rows with a ID pointing to the post they are attached to. But this is pretty slow when you’re searching for multiple fields…
There are a bunch of different options.
The most common is storing “key/value” pairs (I believe this is the WP model), alongside the content item. There are many problems with this model – boolean logic when searching quickly becomes unintelligible, content types aren’t easily be defined and validated in code (e.g. “all CAR content types must have attribute engine size”), etc. However, they do make it easy to create and change content types.
Another model is to generate database tables on the basis of the content types, usually with a “base” content item as the root. There’s a good discussion in Larman’s book on how to model the database tables (“Applying UML and patterns”). This design creates a large amount of housekeeping code – creating and modifying the database tables is a pain, and I wouldn’t recommend doing this for solutions where you’re going to need lots of content types.
The most robust solution I’ve seen uses XML to store the content – often within a database. XML allows you to define a content type (using a DTD or schema), and validate/query it. It isn’t as fast as SQL, though…