编程语言


深入理解08CMS的数据库表结构 (08cms数据库表结构)

网络编程 深入理解08CMS的数据库表结构 (08cms数据库表结构) 09-20

08CMS是一款开源的内容管理系统,广泛应用于各种网站和企业的信息管理工作中。在08CMS的背后,是一个复杂而庞大的数据库结构。本文将会,为用它开发网站的开发者提供更多的帮助。

一、数据库表结构的概览

08CMS的数据库表结构是一个大而复杂的系统,由各个不同的表构成。这些表包含了很多不同的信息,例如文章、分类、用户、权限等等。以下是08CMS的数据库表结构的主要部分:

1. arc_archives:文章表,包含文章的详细信息。

2. arc_attachment:附件表,包含文章的附加文件。

3. arc_clicks:点击数表,用于记录每篇文章的点击次数。

4. arc_index:文章首页表,包含了文章的基本信息以及文章的发布时间。

5. arc_keywords:文章关键字表,用于记录每篇文章的关键字和标签。

6. arc_special:专题表,包含专题的信息和专题的发布时间。

7. arc_type:栏目表,包含网站的所有栏目信息。

8. arcdir_1-4:自定义表,可以用于自定义文章内容。

9. att_albums:相册表,包含相册的基本信息以及相册的发布时间。

10. att_cclasses:附件分类表,用于分类附件。

11. atts:附件表,包含附件的详细信息。

12. bw_blinkevents:友情链接表,用于存储网站的友情链接信息。

13. bw_favorites:收藏表,用于存储用户的收藏夹信息。

14. bw_members:用户表,包含网站注册用户的信息。

15. bw_msgboxes:信箱表,用于存储网站用户的消息和私信信息。

16. bw_roles:角色表,用于定义用户的权限和角色。

17. bw_typehidden:栏目限制表,可以限制某些用户在访问某些栏目和文章时需要输入密码。

18. catalogs:分类表,用于对文章进行分类和管理。

19. concat:关联表,用于将不同表的数据进行关联。

20. cotypes:分类设置表,用于设置分类的一些默认属性。

21. dunliu:预留表,可以用于网站的功能扩展。

二、数据库表结构的详细解析

以上是08CMS的数据库表结构的主要部分,每个表都包含了不同的信息。下面将会对部分表进行详细的解析。

1. arc_archives表

arc_archives表是08CMS数据库的最重要的表之一,它包含了文章的所有信息,例如文章的标题、正文、发布时间、作者等等。以下是arc_archives表的详细信息:

字段名类型说明

dINT文章ID,自增,主键

typeidINT所属栏目ID,外键

typeid2INT所属分类ID,外键

sortrankINT发布时间戳

clickINT点击数

titleLONGTEXT文章标题

shorttitleLONGTEXT文章短标题

colorVARCHAR(10)文章标题颜色

writerVARCHAR(30)文章作者

sourceVARCHAR(30)文章来源

litpicVARCHAR(100)文章缩略图

pubdateDATETIME文章发布时间

senddateDATETIME文章审核时间

midINT会员ID,外键,可以没有

keywordsVARCHAR(255)文章关键字,多个用逗号隔开

descriptionVARCHAR(255)文章描述

weightINT文章权重

isjumpINT是否跳转,0表示不跳转,1表示跳转

jumpurlLONGTEXT跳转URL,当isjump=1,需填写

istopINT是否置顶,0表示不置顶,1表示置顶

recommendedINT是否推荐,0表示不推荐,1表示推荐

votesINT投票次数

noteLONGTEXT管理员备注

abstractLONGTEXT文章摘要

filenameVARCHAR(60)静态文件名

dutyadminINT管理员ID,用于记录审核员

tnameVARCHAR(60)内容模型名称

bodyLONGTEXT正文内容

梳理一下,arc_archives表包含了文章的所有信息,由于每篇文章可以属于不同的栏目和分类,所以typeid和typeid2是该表的重要外键,文章的发布时间在sortrank字段里保存。另外,文章也有一些可选项,比如是否跳转、是否置顶、是否推荐等等。

2. arc_special表

arc_special表包含了08CMS中的专题信息,也是08CMS数据库的重要组成部分。以下是arc_special表的详细信息:

字段名类型说明

spidINT专题ID,自增,主键

enameVARCHAR(60)专题保存文件名

arcrankTINYINT专题审核状态,0表示未审核,1表示已审核

clickINT点击次数

sortrankINT发布时间戳

typeidINT所属栏目ID,外键

createdateDATETIME创建时间

imgurlsLONGTEXT专题缩略图

keywordsVARCHAR(255)关键字,多个用逗号隔开

descriptionVARCHAR(255)专题描述

bodyLONGTEXT专题内容

梳理一下,arc_special表包含了专题的详细信息,包括专题的标题、描述、图片、内容等等。专题的所属栏目是作为外键存在的,同时还有一些可选项,比如是否审核、是否推荐等等。

3. arc_type表

arc_type表是08CMS中的栏目表,包含了网站的所有栏目信息。以下是arc_type表的详细信息:

字段名类型说明

typeidINT栏目ID,自增,主键

reidINT上级栏目ID

topidINT一级栏目ID

sortrankINT排序,用于栏目的排列

typenameVARCHAR(60)栏目名称

typedirVARCHAR(30)栏目保存目录名

isdefaultTINYINT是否默认

defaultnameVARCHAR(60)默认页名称

issendINT是否发送节点列表,0表示不发送,1表示发送

channeltypeVARCHAR(30)内容模型名称

maxpageINT更大分页数

linkurlVARCHAR(255)外部链接URL

typename2VARCHAR(60)二级栏目名称

clickTINYINT点击模式,0表示计数,1表示进入

latestVARCHAR(255)最新文章标题

latestidINT最新文章ID

latestscoresMEDIUMINT最新文章得分

ispartTINYINT是否地区分站,0表示否,1表示是

remoteaddrVARCHAR(100)远程地址,用于分网站访问

contentALLINT栏目访问权限,0表示公开,1表示会员级别,2表示加密

navtypeTINYINT是否在导航中显示,0表示不显示,1表示显示

stitleLONGTEXT栏目自定义SEO标题

keywordsVARCHAR(255)栏目自定义关键字

descriptionLONGTEXT栏目自定义描述

stitle_styleLONGTEXT栏目自定义SEO标题样式

title_styleVARCHAR(255)栏目标题自定义样式

content1MEDIUMTEXT自定义栏目列表页HTML

content2MEDIUMTEXT自定义栏目文章页HTML

content3MEDIUMTEXT自定义栏目首页HTML

梳理一下,arc_type表包含了08CMS中的所有栏目信息,上级栏目ID和一级栏目ID的区分让栏目之间有了更加严格的层级关系,内容模型名称就是栏目的类型,另外还有一些可选项,比如是否公开、是否地区分站等等。

三、

08CMS是一款强大灵活的开源内容管理系统,能够帮助企业和个人快速搭建和管理网站。了解08CMS的数据库表结构,可以更好地开发和维护网站,让网站更加高效稳定。本文深入解析了08CMS的数据库表结构,重点介绍了文章表、专题表、栏目表等等,相信可以为您的08CMS开发工作提供帮助。

相关问题拓展阅读:

  • 数据库问题:【站内发送消息】如何设计表结构

数据库问题:【站内发送消息】如何设计表结构

可给消息增加个STATUS,标记是否已读

1) 不应该针对整个系统进行数据库设计,而应该根据系统架构中的组件划分,针对每个组件所处理的业务进行组件单元的数据库设计;不同组件间所对应的数据库表之 间的关联应尽可能减少,如果不同组件间的表需要外键关联也尽量不要创建外键关联,而只是记录关联表的一个主键,确保组件对应的表之间的独立性,为系统或表 结构的重构提供可能性。

2)采用领域模型驱动的方式和自顶向下的思路进行数据库设计,首先分析系统业务,根据职责定义对象。对象要符合封 装的特性,确保与职责相关的数据项被定义在一个对象之内,这些数据项能够完整描述该职责,不会出现职责描述缺失。并且一个对象有且只有一项职责,如果一个 对象要负责两个或两个以上的职责,应进行分拆。

3)根据建立的领域模型进行数据库表的映射,此时应参考数据库设计第二范式:一个表中的所 有非关键字属性都依赖于整个关键字。关键字可以是一个属性,也可以是多个属性的,不论那种方式,都应确保关键字能够保证唯一性。在确定关键字时,应保 证关键字不会参与业务且不会出现更新异常,这时,更优解决方案为采用一个自增数值型属性或一个随机字符串作为表的关键字。

4)由于之一点所述的领域模型驱动的方式设计数据库表结构,领域模型中的每一个对象只有一项职责,所以对象中的数据项不存在传递依赖,所以,这种思路的数据库表结构设计从一开始即举指满足第三范式:一个表应满足第二范式,且属性正尺配间不存在传递依赖。

5)同样,由于对象职责的单一性以及对象之间的关系反映的是业务逻辑之间的关系,所以在领域模型中的对象存在主对象和从对象之分,从对象是从1-N 或N-N的角度进一步主对象的业务逻辑,所以从对象及对象关系映射为的表及表关联关系不存在删除和插入异常。

6) 在映射后得出的数据库表结构中,应再根据第四范式进行进一步修改,确保不存在多值依赖。这时,应根据反向工程的思路反馈给领域模型。如果表结构中存在多值 依赖,则证明领域模型中的对象具有至少两个以上的职责,应根据之一条进行设计修正。第四范式:一个表如果满足BCNF,不应存在多值依赖。

7) 在经过分析后确认所有的表都满足二、三、四范式的情况下,表和表之间的关联尽量采用弱关联以便于对表字段和表结构的调整和重构。并且,我认为数据库中的表 是用来持久化一个对象实例在特定时间及特定条件下的状态的,只是一个存储介质,所以,表和表之间也不应用强关联来表述业务(数据间的一致性),这一职责应 由系统的逻辑层来保证,这种方式也确保了系统对于不正确数困仔据(脏数据)的兼容性。当然,从整个系统的角度来说我们还是要尽更大努力确保系统不会产生脏数 据,单从另一个角度来说,脏数据的产生在一定程度上也是不可避免的,我们也要保证系统对这种情况的容错性。这是一个折中的方案。

8)应针 对所有表的主键和外键建立索引,有针对性的(针对一些大数据量和常用检索方式)建立组合属性的索引,提高检索效率。虽然建立索引会消耗部分系统资源,但比 较起在检索时搜索整张表中的数据尤其时表中的数据量较大时所带来的性能影响,以及无索引时的排序操作所带来的性能影响,这种方式仍然是值得提倡的。

9) 尽量少采用存储过程,目前已经有很多技术可以替代存储过程的功能如“对象/关系映射”等,将数据一致性的保证放在数据库中,无论对于版本控制、开发和部 署、以及数据库的迁移都会带来很大的影响。但不可否认,存储过程具有性能上的优势,所以,当系统可使用的硬件不会得到提升而性能又是非常重要的质量属性 时,可经过平衡考虑选用存储过程。

10)当处理表间的关联约束所付出的代价(常常是使用性上的代价)超过了保证不会出现修改、删除、更改 异常所付出的代价,并且数据冗余也不是主要的问题时,表设计可以不符合四个范式。四个范式确保了不会出现异常,但也可能由此导致过于纯洁的设计,使得表结 构难于使用,所以在设计时需要进行综合判断,但首先确保符合四个范式,然后再进行精化修正是刚刚进入数据库设计领域时可以采用的更好办法。

11)设计出的表要具有较好的使用性,主要体现在查询时是否需要关联多张表且还需使用复杂的SQL技巧。

12)设计出的表要尽可能减少数据冗余,确保数据的准确性,有效的控制冗余有助于提高数据库的性能。

消息 和 会员 是多对多的关系,应该用一个关系表将2者联系起来,这个关系表中在加入|标记

VipMessage(Vip_Id,Message_Id,Read),前2个字颂孙戚段为主键。

公告消息(所有会员),这样的公告,就需要在这个VipMessage表中添加所有Vip和该消息的主键,Read为未读,

会员消息(指定会员),也是如此。

这似乎有点冗余,但是你需要 “标记”就必须这样设计。

如果不需要野陵“”,这可以将会员分组(分类型或等级),消息表中添加Level字段,这样属于这个等级的vip就可以阅读消息凯誉。

— 一起4张表 消息类别表,消息表,发送消息人员表,接收消息人员表

— 至于会员要接收到信息后删除自己,其实可用标记处理而无作废,也就存在—回收站的概念,最后败粗弊也可以彻底删除

— 消息表单独拿出来不做任何处理,这样数据也不会冗余,发送人与接收人的处理分别可以单独处理

-消息类别表—

TMessageType

FTypeID

FTypeName

FTypeMemo

-消息表-

TMessageInfo

FMessageID

FTypeName –(这里也不需要放置ID,为提高性能)直接放类别名称

FContent

FSendDate

-发送消息人员表-与消息表关联获取所有信息

TSendMessage

FSendID主键ID

FMessageID –TMessageInfo主键ID

FUserID用户ID

FSendPerson –发送人凳孙

FCancel是否作废标记,也可作为删除删除标记

-接收消息人员表-与消息表关联获取所有信息—-

TReceiveMessage

FReceiveID

FMessageID

FUserID

FReadFtatus –是否读取

FCancel

—用户表—

TUserInfo(结构为你自己的)FUserID为主键ID

–SQL语句大概写法(我用SQLSERVER)

–1.发送所有人

INSERT INTO TReceiveMessage

(FMessageID,FUserID,FReadFtatus,FCancel)

SELECT FMessageID,FUserID ,0,0 –默认未读察族

FROM TUserInfo,TSendMessage

WHERE FSendID=@FSendID

.发送指定人

INSERT INTO TReceiveMessage

(FMessageID,FUserID,FReadFtatus,FCancel)

SELECT FMessageID,FUserID ,0,0 –默认未读

FROM TUserInfo,TSendMessage

WHERE FSendID=@FSendID AND FUserID=@FUserID

–TMessageInfo与其它2张消息表 建立好主外键约束就行了

表衡并Message

MessageID 主键

Content

MessageDate

CreatorID

表孝或User

UserID

UserName

UserPwd

UserType

表咐慎迹Message_MM_User

UserID

MessageID

08cms数据库表结构的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于08cms数据库表结构,深入理解08CMS的数据库表结构,数据库问题:【站内发送消息】如何设计表结构的信息别忘了在本站进行查找喔。


编辑:编程语言

标签:栏目,文章,数据库,结构,对象