数据库 2023-07-14

PHPcms数据库表结构详解 (phpcms数据库表结构)

作为一种用于网站构建的内容管理系统，PHPcms 在很多网站中得到了广泛的应用。其中，在 PHPcms 的数据库表结构中，有一些关键的表格和字段，通过这些表格和字段，我们可以更加深入地了解该内容管理系统的内部运作机制以及其提供的功能。本篇文章将详细地介绍 PHPcms 的数据库表结构，以及这些表格和字段的作用和功能。

一、网站配置表（phpcms_config）

PHPcms 的网站配置表（phpcms_config）是该系统中最为重要的表格之一，它存储了网站的很多配置参数，对于整个系统的运作来说，都具有至关重要的作用。

网站配置表中所储存的配置参数包括：网站名称、网站域名、网站字符集、网站首页地址、用户注册、登录和找回密码的相关设置、文章发布相关设置、缩略图和水印相关设置、时间和日期格式等等。

表格中的字段名和含义如下：

“`sql

————— | ————– | —– | — | ——- | —–

“`

其中，name 字段为配置项名称，是该表的主键。value 表示对应的值，options 表示一些可选的值，type 表示该配置项的类型（例如单选框、下拉框等），inputtime 表示该配置项的添加时间。

二、菜单表（phpls_menus）

PHPcms 的菜单表（phpls_menus）存储了网站后台的菜单项，每个菜单项对应一个后台功能模块。管理员登录后台时，会根据该表中的菜单信息来生成相应的菜单项，从而实现对系统各项功能的控制和操作。

菜单表中的字段名和含义如下：

“`sql

———- | ————-| —– | — | ——- | —–

id | mediumint(8) | NO | PRI | NULL | auto_increment

parentid | mediumint(8) | YES | | 0 |

m | varchar(30) | YES | | NULL |

c | varchar(30) | YES | | NULL |

a | varchar(30) | YES | | NULL |

listorder | allint(5) | NO | | 0 |

“`

其中，id 为菜单编号，name 为菜单名称，parentid 为菜单的父级编号，m、c、a 分别表示一个 URL，在路由分发时使用，data 则表示一些可选的数据参数，listorder 表示该菜单在前台菜单中的各项排序。

三、模块表（phpls_module）

PHPcms 的模块表（phpls_module）存储了该内容管理系统中所支持的各种模块，例如文章模块、图片模块、分类模块等等。每个模块在系统中唯一对应一个模块编号，该编号可用于引用模块的相关数据。

模块表中的字段名和含义如下：

“`sql

———- | ————-| —– | — | ——- | —–

listorder | allint(5) | NO | | 0 |

“`

表格中，module 表示模块编号，name 表示模块名称，description 表示模块描述，issystem 用于表示该模块是否为系统自带，version 表示模块版本，enabled 表示该模块是否启用，listorder 表示该模块在列表中的排序。

四、文章表（phpls_content）

PHPcms 的文章表（phpls_content）是存储文章数据的核心表格，它包含了文章所属的分类、发布时间、作者、标题、内容等数据。

文章表中的字段名和含义如下：

“`sql

————– | ————-| —– | — | ——- | —–

contentid | int(10) | NO | PRI | NULL | auto_increment

url | varchar(255) | NO | | NULL |

listorder | int(10) | NO | | NULL |

inputtime | int(10) | NO | MUL | NULL |

updatetime | int(10) | NO | MUL | NULL |

“`

文章表中，contentid 为文章编号，catid 为分类编号，userid 为发布用户编号，username 表示发布用户名，title 表示文章标题，style 表示文章风格，thumb 表示文章缩略图，keywords 表示文章关键词，description 表示文章摘要，url 表示文章地址，listorder 表示文章在列表中的排序，status 表示文章状态（例如已审核、未审核等），sysadd 指示文章是否为管理员发布，islink 表示文章是否为外部链接，inputtime 表示文章发布时间，updatetime 表示文章更新时间。

五、附件表（phpls_attachment）

PHPcms 的附件表（phpls_attachment）存储了网站中所有的附件文件信息，包括附件名称、存储路径、文件大小等信息。

附件表中的字段名和含义如下：

“`sql

————– | ————-| —– | — | ——- | —–

d | mediumint(8) | NO | PRI | NULL | auto_increment

filesize | int(10) | NO | | NULL |

uploadtime | int(10) | NO | | NULL |

“`

附件表中，d 为附件编号，userid 表示上传用户编号，module 表示附件所属模块，filename 表示附件名称，filetype 表示附件类型，filesize 表示附件大小，filepath 表示附件存储路径，uploadtime 表示附件上传时间，isimage 表示附件是否为图片，image_width 和 image_height 则表示图片的宽度和高度。

综上所述，PHPcms 中的数据库表结构非常重要，这些表格和字段的作用和功能都直接影响到系统的运作和性能。因此，在使用 PHPcms 构建网站时，需要理解这些表格和字段的内容和作用，从而更好地使用和开发该内容管理系统。

相关问题拓展阅读：

数据库问题：【站内发送消息】如何设计表结构
数据库表的物理结构是什么

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

— 一起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张消息表建立好主外键约束就行了

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

会员消息（指定会员），也是如此。

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

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

表衡并Message

MessageID 主键

Content

MessageDate

CreatorID

表孝或User

UserID

UserName

UserPwd

UserType

表咐慎迹Message_MM_User

UserID

MessageID

数据库表的物理结构是什么

数据库设计的过程(六个阶段)

1.需求分析阶段

准确了解与分析用户需求（包括数据与处理）

是整个设计过程的基础，是最困难、最耗费时间的一步

2.概念结构设计阶段

是整个数据库设计的关键

通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型

3.逻辑结构设计阶段

将概念结构卖差转中判皮换为某个DBMS所支持的数据模型

对其进行优化

4.数据库物理设计阶段

为逻辑冲岩数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）

5.数据库实施阶段

运用DBMS提供的数据语言、工具及宿主语言，根据逻辑设计和物理设计的结果

建立数据库，编制与调试应用程序，组织数据入库，并进行试运行

6.数据库运行和维护阶段

数据库应用系统经过试运行后即可投入正式运行。

在数据库系统运行过程中必须不断地对其进行评价、调整与修改

设计特点:

在设计过程中把数据库的设计和对数据库中数据处理的设计紧密结合起来将这两个方面的需求分析、抽象、设计、实现在各个阶段同时进行，相互参照，相互补充，以完善两方面的设计

关于phpcms数据库表结构的介绍到此就结束了，不知道你从中找到你需要的信息了吗？如果你还想了解更多这方面的信息，记得收藏关注本站。

数据运维技术 » PHPcms数据库表结构详解 (phpcms数据库表结构)

分享到：

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

数据库表的物理结构是什么

相关推荐