阅读前请先下载项目源码,边读边看源码以加深理解和实操,
源码地址已放于文章末尾!
效果预览:


第三章:数据库:数据的“户口本”,我们来当一次“片儿警”
嘿,各位“建筑师”,欢迎回来!
在上一章,我们挥洒汗水,把项目的“地基”——本地开发环境给打得牢牢的。现在,我们的“工地”已经万事俱备,是时候深入地下,去探寻支撑整个项目的“数据管网”了。没错,这一章,我们就要来聊聊项目的“灵魂”——数据库设计。
如果说一个App是座城市,那数据库就是这座城市的“民政局”+“派出所”。它管理着所有“居民”(用户)的“户口本”(数据),记录着他们之间发生的各种“社会关系”(业务逻辑)。今天,我们就来当一次“片儿警”,把这个陪玩App的“户口本”给查个底朝天。
一、设计的艺术:表与表之间的“爱恨情仇”
在关系型数据库(比如MySQL)的世界里,所有的数据都不是孤立存在的,它们之间有着千丝万缕的联系。比如,一个“用户”会下很多“订单”,一个“订单”只属于一个“用户”,一个“订单”会关联一个“陪玩师”(陪玩师本身也是一个特殊的用户)。
把这些关系捋清楚,是数据库设计的核心。下面,我画了一张“关系图”,让你一秒看懂我们项目中几个核心数据表之间的“爱恨情仇”。
这张图就是我们数据库设计的核心骨架。接下来,我们来逐一解析这几个关键的“户口本”。
二、核心“户口本”详解
1. 用户表 (fa_user)
这是我们整个系统的基石,所有“进入”我们App的人,无论是普通玩家还是陪玩师,都得在这里“登记落户”。
文件路径: 在ThinkPHP中,通常会有一个模型文件来对应这张表,路径在 /application/common/model/User.php。
核心字段解读:
id (PK): 每个用户的唯一身份证号,主键,自动增加。nickname: 用户的昵称,行走江湖的“代号”。mobile: 手机号,用于注册和登录。openid: 微信的OpenID,如果要做微信一键登录,这个字段就是关键。group_id: 这个字段是设计的精髓! 我们用它来区分用户的身份。比如,group_id=1代表普通用户,group_id=2代表陪玩师,group_id=3代表管理员。这样,我们就不需要单独创建一张陪玩师表了,管理起来非常方便。balance: 账户余额,用户充值的钱就存在这里。
2. 订单表 (fa_order)
这张表记录了所有的“交易”行为。每一次下单,都会在这里生成一条新纪录。
核心字段解读:
id (PK): 订单的唯一ID。order_sn: 订单号,一个对外展示的、有规律的字符串,比如PEIWAN20230808XXXX。user_id (FK): 外键,关联fa_user表的id,记录是谁下的单。clerk_id (FK): 外键,同样关联fa_user表的id,记录是哪个陪玩师接的单。category_id (FK): 外键,关联fa_category表,记录用户下单的是什么服务。status: 订单状态,比如0-待支付,1-进行中,2-已完成,3-已取消。这是订单流程流转的核心依据。amount: 订单的总金额。
3. 陪玩师申请表 (fa_clerk_apply)
普通用户想成为陪玩师?可以,先填个“政审表”。这张表就是用来存储用户的申请信息的。
核心字段解读:
user_id (FK): 谁提交的申请。real_name/id_card: 真实身份信息,用于实名认证。status: 审核状态,0-待审核,1-审核通过,2-审核拒绝。后台管理员就是根据这个字段来处理申请的。当审核通过后,程序会自动将fa_user表里对应用户的group_id修改为陪玩师的ID。
4. 服务类目表 (fa_category)
陪玩师能提供哪些服务?王者荣耀、英雄联盟还是绝地求生?这些都由这张表来定义。
核心字段解读:
name: 类目名称,比如“王者荣耀”。parent_id: 如果我们的服务项目有层级关系,比如“手游”下面有“王者荣耀”和“和平精英”,就可以用这个字段来实现。
三、总结
好了,今天的“户口本”大调查就到这里。我们通过一张清晰的实体关系图,理清了项目中几个核心数据表之间的关系,并对关键表的关键字段进行了解读。
一个好的数据库设计,是项目成功的一半。它就像城市的地下管网,虽然平时看不见,却支撑着整个城市的运转。我们今天理清了这些“管网”的走向,为后续开发API接口、实现业务逻辑打下了坚实的基础。
在下一章 《后端API(上):用户的“身份证”与“通行证”》 中,我们将正式开始编码!我们会利用今天对 fa_user 表的理解,开发出用户的注册和登录接口。
准备好敲下你的第一行后端代码了吗?我们下期见!

被折叠的 条评论
为什么被折叠?



