手把手教你写项目之游戏陪玩app全栈开发---第三章:数据库的建立:数据的“户口本”

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

效果预览:
在这里插入图片描述

在这里插入图片描述

第三章:数据库:数据的“户口本”,我们来当一次“片儿警”

嘿,各位“建筑师”,欢迎回来!

在上一章,我们挥洒汗水,把项目的“地基”——本地开发环境给打得牢牢的。现在,我们的“工地”已经万事俱备,是时候深入地下,去探寻支撑整个项目的“数据管网”了。没错,这一章,我们就要来聊聊项目的“灵魂”——数据库设计。

如果说一个App是座城市,那数据库就是这座城市的“民政局”+“派出所”。它管理着所有“居民”(用户)的“户口本”(数据),记录着他们之间发生的各种“社会关系”(业务逻辑)。今天,我们就来当一次“片儿警”,把这个陪玩App的“户口本”给查个底朝天。

一、设计的艺术:表与表之间的“爱恨情仇”

在关系型数据库(比如MySQL)的世界里,所有的数据都不是孤立存在的,它们之间有着千丝万缕的联系。比如,一个“用户”会下很多“订单”,一个“订单”只属于一个“用户”,一个“订单”会关联一个“陪玩师”(陪玩师本身也是一个特殊的用户)。

把这些关系捋清楚,是数据库设计的核心。下面,我画了一张“关系图”,让你一秒看懂我们项目中几个核心数据表之间的“爱恨情仇”。

USER int id PK 用户ID (主键) varchar nickname 昵称 varchar mobile 手机号 varchar openid 微信OpenID int group_id 用户组ID (区分普通用户/陪玩师) decimal balance 账户余额 ORDER int id PK 订单ID (主键) varchar order_sn 订单号 int user_id FK 下单用户ID int clerk_id FK 陪玩师ID int category_id FK 服务类目ID int status 订单状态 (待支付/进行中/已完成) decimal amount 订单金额 CLERK_APPLY int id PK 申请ID (主键) int user_id FK 申请人ID varchar real_name 真实姓名 varchar id_card 身份证号 int status 审核状态 (待审核/通过/拒绝) CATEGORY int id PK 类目ID (主键) varchar name 类目名称 (如: 王者荣耀, 英雄联盟) int parent_id 父类目ID (用于多级分类) places applies to be belongs to

这张图就是我们数据库设计的核心骨架。接下来,我们来逐一解析这几个关键的“户口本”。

二、核心“户口本”详解

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 表的理解,开发出用户的注册和登录接口。

准备好敲下你的第一行后端代码了吗?我们下期见!

源码下载地址:
https://thmail.lanzouu.com/iveW134b31qj

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

THMAIL

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值