CMS内容发布系统数据库设计详解

需积分: 15 7 下载量 156 浏览量 更新于2024-07-16 收藏 115KB DOCX 举报
"该文档是CMS内容发布系统的数据库设计文档,详细介绍了数据库的结构、命名规则、关系模型图以及各个表的设计,旨在为开发者提供清晰的数据库设计方案。使用的数据库管理系统是MySQL 5.7,推荐在内网环境下使用Navicat for MySQL作为管理工具。" 在CMS(内容管理系统)中,数据库设计是核心部分,它决定了系统数据的存储、访问效率和整体架构的合理性。以下是根据提供的内容提取的关键知识点: 1. **背景与目的**: CMS内容发布系统主要用于管理网站内容的发布和管理。数据库设计文档的主要目的是为了让开发者更深入地理解系统的数据库结构,定义数据库的性能、环境,并划分子系统功能,为整个开发工作奠定基础,同时帮助团队成员理解和协作。 2. **数据库命名规则**: - 所有表名使用小写字母,保证名称的一致性和规范性。 - 表名长度控制在30个字符以内,避免过长导致的问题。 - 表名由明确的英文单词或缩写组成,多个单词间用下划线 "_" 分隔,以便于理解表的用途。 3. **关系模型图**: 虽未给出具体的关系模型图,但通常包含实体间的关系,如一对多、多对一、多对多等,用于描述数据之间的逻辑关系。 4. **数据库结构设计**: - **ADVERTISEMENT**:广告表,可能包括广告ID、广告内容、投放位置、有效期等字段。 - **ARTICLE**:文章表,可能包含文章ID、标题、内容、作者、发布时间、分类等字段。 - **ATTACHMENT**:附件表,存储与内容相关的文件,如图片、文档等,可能有附件ID、关联内容ID、文件路径等字段。 - **BLOGROLL**:博客表,记录博客相关信息,如博客ID、博主ID、博客标题、内容等。 - **COLUMNS**:栏目表,用于分类内容,可能包括栏目ID、名称、描述、父栏目ID等。 - **DICTIONARY**:字典表,通常用于存储固定选项,如状态码、性别等。 - **FTP**:FTP表,可能存储FTP服务器配置信息,如服务器地址、用户名、密码等。 - **LOG**:日志表,记录系统操作日志,包括操作ID、操作人、操作时间、操作描述等。 - **MENU**:菜单表,定义系统的菜单结构,包含菜单ID、名称、URL、权限标识等。 - **ROLE**:角色表,定义不同用户权限的角色,如管理员、编辑等。 - **ROLEMENU**:角色菜单中间表,用于连接角色和菜单,实现权限控制。 - **SHORTCUT**:用户菜单中间表,记录用户的自定义快捷菜单设置。 - **TEMPLATE**:模板表,存储页面布局和样式信息。 - **TIMEDTASK**:定时任务表,管理周期性执行的任务,如计划任务的ID、执行时间、任务内容等。 - **TOPIC**:话题表,用于论坛或讨论区,可能包含话题ID、标题、创建人、讨论内容等。 - **USER**:用户表,记录用户基本信息,如用户ID、用户名、密码、邮箱等。 - **USERROLE**:用户角色中间表,连接用户和角色,实现用户权限分配。 5. **数据库管理工具**: 推荐在内网环境下使用Navicat for MySQL,这是一款强大的数据库管理和开发工具,支持多种数据库类型,具有图形化的界面,便于数据库管理和维护。 6. **部署环境**: 数据库系统使用的是MySQL 5.7,通常在RDS(关系型数据库服务)上部署,提供了稳定、高效的数据库服务。 这个设计文档为CMS系统的开发提供了详细的数据库蓝图,确保了系统的数据结构清晰,便于开发和维护。
2023-01-08 上传
CMS之数据库设计 在园子里也混了三年多,随笔200多,一开始只是想把自己的经验写一下,后来呢弄出来了一个"自然框架",主要精力就放在了介绍自然框架的思路上面了。随笔多了就发现一个问题:有点乱。虽然博客有分组,但是只支持一级分组,不支持n级的。博客里也没有"栏目"这一类的设置。所以对于随笔的管理有有点力不从心了。有些兄弟看到我的博客,看到我说自然框架,然后就会很迷茫,自然框架到底是什么?能做什么?如果想看看的话,从什么地方开始看,按照什么顺序来看?   博客的这种形式就不大好解决这种需求了,当然也许是我对博客还不了解,没有用好吧。所以我想做一个网站,这个网站专门介绍自然框架。一开始只想做一个静态的,内容也不多嘛,做几个页面,介绍一下,把博客里的随笔整理一下做个目录便于阅读。但是试了一下才发现,静态页面好麻烦呀,也许是我太懒了吧,总是想简单一些。于是就想做一个简单的CMS,然后用这个CMS来做自然框架的介绍网站。   您可能会说了,海洋又在重复制造轮子了,网上有一大堆现成的,有很多成熟的不去用,自己写什么呀?   首先呢,我是程序员(嘿嘿),我先想到的是我自己能不能做出来?别人能做我为什么不行?我不是顾客,我也不是有钱人,到处去弄现成的。其次呢,做一个CMS也是一个练手的机会,同时也是自然框架的一个Demo,比较大的、完整的Demo。借此来说明自然框架的使用方式,和在网页里的作用。最后就是想借此说一下我的设计数据库的思路。我觉得我的设计数据库的思路还是有点特色的。   好了,开始进入正题。   首先是了解需求。一个网站会有什么?首页、新闻(图文形式的信息)、产品介绍、文件下载、图片浏览、在线视频等。这些都算是"内容"的几种形式吧,当然还可以有其他的形式。 CMS之数据库设计全文共5页,当前为第1页。  这个需求比较简单,也比较简陋,暂时就以这个需求来进行设计吧。如果是按照面向对象的方式要如何设计呢?这个我不太清楚,也许是要画一个UML吧,也许要建模。尝试一下,画了一个UML不知道对不对,拿出来请大家批批。 CMS之数据库设计全文共5页,当前为第1页。 【CMS的类图】   图很简单也没什么具体的属性,因为需求是变化的,现在也没有太具体的需求,所以属性就先设置几个主要的。另外俺英文不好,怕查出来的英文单词不正确产生歧义,所以直接用汉字了。可能您看着很别扭,但是至少不会产生什么歧义,理解起来也会比较容易吧,呵呵。   "内容"作为父类,其他的作为子类。内容是一种"抽象",把各种形式的内容的共同部分提炼出来,比如标题、内容、添加人、添加日期、点击量等。子类负责各自特有的属性。   我觉得这种提炼的方式比较好,在设计数据库表结构的时候可以借鉴一下。于是就有了这样的数据库设计。 CMS之数据库设计全文共5页,当前为第2页。【CMS ER图】 CMS之数据库设计全文共5页,当前为第2页。   "内容"作为主体和中心,其他的都是为了这个中心(内容)来服务的。左面是对内容的限制,栏目相当于大分类,分类就是小分类(可以是n级的),类型就是内容的形式,比如图文、下载、视频、图片等。右面是扩展。扩展和类型是一一对应的。   这就形成了一个"骨架",骨架是以"内容"为中心,ArticleID作为关联字段,可以增加扩展表,但是都要以ArticleID作为关联字段。至于有多少扩展表,那就可以根据实际需求来变化,表里的字段也是可以根据需求来增减。   设置这种"骨架"的好处:虽然扩展表、字段会有变化,但是"骨架"结构是不变的。这样一是可以让结构清晰,抓住中心、重点;二是当需求变化的时候,对结构的影响降到最低;三是,如果对于这种"骨架"习惯、掌握了之后,在看到其他项目的设计就会很容易进入和读懂。关于第三点,以后大家就会理解的。 CMS之数据库设计全文共5页,当前为第3页。  基本思路就是这样,抛砖引玉了。 CMS之数据库设计全文共5页,当前为第3页。 CMS之数据库设计全文共5页,当前为第4页。ps:CMS的字段说明 CMS之数据库设计全文共5页,当前为第4页。 表编号 字段编号 字段名 中文名 类型 大小 默认值 允许空 说明 5000 0 CMS_Channel 网站栏目           5000 10 ChannelID 主键 int 4 1 0 主键,自增 5000 20 channelName 栏目名称 nvarchar 30 _ 0 栏目名称 5000 30 Sort 排序 int 4 10 0 小号在前 5000 40 URL 栏目的网址 nvarchar 50 _ 0 新闻内容     5005 0 CMS_ArticleClass 内容的n级分组           5005 10 ClassID 主键 int 4 1 0 主键,自增