As you can see from the GIF provided, an ideal setup for the content management database schema would include 3 tables. Read over the setup here, and if you have any questions, please let me know.
This is of course the most obvious. Content at the base level is the same across the board. Whether the content is news, articles, section content, or whatever you want to call it (heck, even comments!), they are all the same.
Table Schema and Explanation
Table: content
Field: id
The id field is simply the unique id (or a sequence) of the content. This is common enough.
Field: type
Somewhat abstract, however, type is important in human terms. What 'kind' of content is this? Content can a front page news article, section content, heck, even comments or forum posts. This allows for a special abstraction and making this system a core system would allow other applications using PostNuke a common content setup to use. They could define their own 'type' of document, and simply use that table. This would make searching the content of the site really easy as well.
All news items could have the 'news' declaration put on them. Namespaces would have to be enforced, so you could enforce a 'modulename_type' of system, and use 'core_type' for anything the core system uses.
Field: status
Status is important in a CMS. Content Management is the key, and just because content is in the system doesn't mean anyone should be able to look at it. It is important to remember what a CMS is. Giving status several possible values, like "Published", "Under Review", "Editing Phase 1", "Editing Phase 2", "Rough Draft" and finally, "Queued for Deletion" would allow PostNuke to take on a better CMS status. Integrating this with your proposed new user system could also be a boon, allowing only certain levels of users to "Publish" content finally. You can also set certain types of content, like comments, to be set to "Published" automatically, or allow admins to create "content rules".
Field: promotion
Another abstract term, yet something used to help describe how the system should handle the data. Most obvious use is the Drupal style of promoting the content, whatever it is, to the front of the page. This means you can quickly and easily add new content, or a comment, as a front page news item and 'promote' it. Of course, setting up something so that all "news" items are set as being promoted to the front page would be a good case.
Field: title
Self explanatory, the title of the content.
Field: abstract
Self explanatory, the abstract of the content.
Field: content
Finally, the content itself.
Table: content_author
Basically a one-to-many setup here. Content can have more than one author, and setting up an author's table containing important authors info would be important. This can link to the users table if need be, but not all author's may be users.
Field: content_id_fk
Foreign key to the content id.
Field: author_id_fk
Foreign key to the author id.
Table: content_category
Again, like the content_author table, content may be contained under more than one category. An article on PHP and MySQL may fall under 2 categories, PHP and MySQL.
Field: content_id_fk
Foreign key to the content id.
Field: category_id_fk
Foreign key to the category id.
What we have here is a working content model. As you can see in the diagram, we have defined content in a relatively simple matter.
Overall, it is important that content be managed as a core system. However, defining the content should be left up to the modules.
1569