CMS之数据库设计
首先是了解需求。一个网站会有什么？首页、新闻（图文形式的信息）、产品介绍、文件下载、图片浏览、在线视频等。这些都算是“内容”的几种形式吧，当然还可以有其他的形式。
这个需求比较简单，也比较简陋，暂时就以这个需求来进行设计吧。如果是按照面向对象的方式要如何设计呢？这个我不太清楚，也许是要画一个UML吧，也许要建模。尝试一下，画了一个UML不知道对不对，拿出来请大家批批。
【CMS的类图】
图很简单也没什么具体的属性，因为需求是变化的，现在也没有太具体的需求，所以属性就先设置几个主要的。另外俺英文不好，怕查出来的英文单词不正确产生歧义，所以直接用汉字了。可能您看着很别扭，但是至少不会产生什么歧义，理解起来也会比较容易吧，呵呵。
“内容”作为父类，其他的作为子类。内容是一种“抽象”，把各种形式的内容的共同部分提炼出来，比如标题、内容、添加人、添加日期、点击量等。子类负责各自特有的属性。
我觉得这种提炼的方式比较好，在设计数据库表结构的时候可以借鉴一下。于是就有了这样的数据库设计。
【CMS ER图】
建议：文章分成两个表，一个表只包含 id 和 content，一个表包含其他字段，如标题，日期，作者，类别等等
“内容”作为主体和中心，其他的都是为了这个中心（内容）来服务的。左面是对内容的限制，栏目相当于大分类，分类就是小分类（可以是n级的），类型就是内容的形式，比如图文、下载、视频、图片等。右面是扩展。扩展和类型是一一对应的。
这就形成了一个“骨架”，骨架是以“内容”为中心，ArticleID作为关联字段，可以增加扩展表，但是都要以ArticleID作为关联字段。至于有多少扩展表，那就可以根据实际需求来变化，表里的字段也是可以根据需求来增减。
设置这种“骨架”的好处：虽然扩展表、字段会有变化，但是“骨架”结构是不变的。这样一是可以让结构清晰，抓住中心、重点；二是当需求变化的时候，对结构的影响降到最低；三是，如果对于这种“骨架”习惯、掌握了之后，在看到其他项目的设计就会很容易进入和读懂。关于第三点，以后大家就会理解的。
基本思路就是这样，抛砖引玉了。
ps：CMS的字段说明
