Additionally, it gets complicated since you need to maintain referential integrity between content items – when the author to which you refer gets deleted, you need to make sure your news article gets updated. (Yes, this is easy in a standard relational database, but how many content management repositories are flat tables like that?)
eZ publish does relational modeling really, really well. I touch on this briefly in the screencast on eZ that I did for Packt last year. Essentially, you can state that a property of an object is (1) a reference to another object, or (2) a reference to multiple other objects. Additionally, you can specify what type of objects can be linked, and from what branch of the content tree they can come from. Short of a custom relational database, this is the best I’ve ever seen relational modeling executed.
Also, the template code to get at the relations is fantastic. The properties on the original object are seamless references to the other objects. Like this:
{$article.author.first_name} {$article.author.last_name}
Now, if your CMS has a content tree, you can fake up a limited amount of relational modeling. For instance, you could add an “author” object as a child of a news article. Then you just treat any author object found under an article object as the author of that article. This gives you a separate author object, but that’s about it – you have to have multiple authors under multiple articles, so it’s really limited. But it’s something, if you have no other options.
I realized recently that the ability to model content well is really the first thing I look for in a CMS. But it’s important to realize that discrete and relational model are two different things, and most systems are much better at the former than a latter (especially XML-ish systems – XML representations of content tend to be very discrete).
Next time you evaluate a system, look for both aspects of content modeling. A well-done relational modeling system can be a huge benefit.