毕设规划

2024年1月11日 12点33分

功能需求部分

美食教程小程序应能够满足用户的基本需求

  • 食谱浏览:
    • 分类浏览:按照不同的菜系等分类浏览食谱。
    • 热门推荐:展示热门、受欢迎的食谱。
  • 搜索菜谱
    • 根据菜谱的名字,内容搜索
  • 发布菜谱
    • 菜谱的帖子中要包含文字和图片,图片怎么弄呢?难道还要买个OSS,应该还是要买一个OSS的,不然图片传不上取啊
    • 一个难点在于,菜谱中的图片,传上来,然后怎么确定就在那个位置呢?
    • 一个上传按钮,上传完图片就会在光标位置生成markdown的图片引用,这不就刚刚好了
  • 评论
    • 评论主要是针对菜谱进行的,而这里的菜谱代表的就是帖子,然后菜谱的评论可以嵌套,也就是对评论也可以进行评论
  • 收藏
    • 而收藏,也就是收藏菜谱了
  • 点赞
    • 点赞菜谱

杂谈

登录部分设计成什么样的呢?

  • 手机验证码登录
  • 手机号密码登录
  • 微信扫码登录,这个做不了,要认证啥的,很麻烦.

数据库设计

user:用户表

  • id
  • nick_name
  • account:手机号
  • password
  • avatar_url:头像url
  • bio:个人简介
  • create_time
  • update_time
  • role_id(待定,对于前台用户是否要求有角色,因为还不确定要不要板块的管理员什么的)
  • last_read_like_time:上一次查看点赞时间戳
  • last_read_message_time:上一次查看评论的时间戳

recipe菜谱表

  • id
  • title:标题
  • content:内容
  • author_id:作者id
  • image_url:封面图
  • create_time:发布时间
  • update_time
  • views:浏览量

category分类表

  • id
  • recipe_id:菜谱id
  • name:分类名称

tag标签表

  • id
  • recipe_id
  • name:标签名

comment评论表

  • id
  • recipe_id:评论绑定的菜谱id
  • content:评论内容
  • user_id:评论者
  • parent_id:父评论id,如果为null就是顶级评论
  • create_time:评论时间

like点赞表

  • id
  • recipe_id:菜谱id
  • user_id:点赞人id
  • create_time

favorite收藏表

  • id
  • user_id
  • recipe_id
  • create_time

建表语句:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
-- 用户表
CREATE TABLE user (
id INT PRIMARY KEY AUTO_INCREMENT,
nick_name VARCHAR(255) NOT NULL,
account VARCHAR(20) NOT NULL UNIQUE,
password VARCHAR(255) NOT NULL,
avatar_url VARCHAR(255),
bio TEXT,
create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
update_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
role_id INT, -- 如果角色表存在,此为外键
last_read_like_time BIGINT,
last_read_message_time BIGINT
);

-- 菜谱表
CREATE TABLE recipe (
id INT PRIMARY KEY AUTO_INCREMENT,
title VARCHAR(255) NOT NULL,
content TEXT NOT NULL,
author_id INT NOT NULL, -- 外键关联到用户表的id字段
image_url VARCHAR(255),
create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
update_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
views INT DEFAULT 0
);

-- 分类表
CREATE TABLE category (
id INT PRIMARY KEY AUTO_INCREMENT,
recipe_id INT NOT NULL, -- 外键关联到菜谱表的id字段
name VARCHAR(255) NOT NULL
);

-- 标签表
CREATE TABLE tag (
id INT PRIMARY KEY AUTO_INCREMENT,
recipe_id INT NOT NULL, -- 外键关联到菜谱表的id字段
name VARCHAR(255) NOT NULL
);

-- 评论表
CREATE TABLE comment (
id INT PRIMARY KEY AUTO_INCREMENT COMMENT '评论ID',
recipe_id INT NOT NULL COMMENT '外键关联到菜谱表的id字段',
content TEXT NOT NULL COMMENT '评论内容',
user_id INT NOT NULL COMMENT '外键关联到用户表的id字段',
root_id INT COMMENT '根评论ID,如果不为空则是回复评论-二级评论,该值是顶级评论的ID',
to_id INT COMMENT '如果为NULL则是回复的顶级评论,不为NULL则是回复的二级评论,表示被回复的评论的ID',
create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP COMMENT '评论创建时间'
);

-- 点赞表
CREATE TABLE likes (
id INT PRIMARY KEY AUTO_INCREMENT,
content_type VARCHAR(10) NOT NULL,
content_id INT NOT NULL,
user_id INT NOT NULL,
create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
UNIQUE KEY unique_like (content_type, content_id, user_id)
);


-- 收藏表
CREATE TABLE favorite (
id INT PRIMARY KEY AUTO_INCREMENT,
user_id INT NOT NULL, -- 外键关联到用户表的id字段
recipe_id INT NOT NULL, -- 外键关联到菜谱表的id字段
create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

逻辑判断

  1. 点赞逻辑:点赞按钮设计成第一次点就是点赞,后面的每一次点就是给当前状态置非
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
<template>
<div>
<button @click="toggleLike">
{{ isLiked ? '取消点赞' : '点赞' }}
</button>
<p>{{ likesCount }} 人赞过</p>
</div>
</template>

<script>
export default {
data() {
return {
isLiked: false,
likesCount: 0
};
},
methods: {
toggleLike() {
// 切换点赞状态
this.isLiked = !this.isLiked;

// 调用后端接口,将当前点赞状态发送给后端
this.$axios.post(`/recipes/${recipeID}/like`, {
isLiked: this.isLiked
})
.then(response => {
// 更新点赞数量等信息(如果后端返回了)
this.likesCount = response.data.likesCount;
})
.catch(error => {
console.error('Failed to toggle like', error);
// 如果请求失败,需要回滚前端的点赞状态
this.isLiked = !this.isLiked;
});
},
fetchLikeInfo() {
// 调用后端接口获取点赞信息
this.$axios.get(`/recipes/${recipeID}/likeInfo`)
.then(response => {
this.isLiked = response.data.isLiked;
this.likesCount = response.data.likesCount;
})
.catch(error => {
console.error('Failed to fetch like info', error);
});
}
},
mounted() {
// 在组件加载时获取点赞信息
this.fetchLikeInfo();
}
};
</script>

技术选型

看样子公司开发都是vue3了,不如这次就直接Springboot3+vue3+jdk17

算了,Springboot3用了之后项目都跑不起来..

待修改的地方

  1. 是否留评论回复的功能
  2. 收藏要有收藏夹

评论如何设计

评论表还是设计成这样吧,网上能找到类似的材料

1
2
3
4
5
6
7
8
9
CREATE TABLE comment (
id INT PRIMARY KEY AUTO_INCREMENT COMMENT '评论ID',
recipe_id INT NOT NULL COMMENT '外键关联到菜谱表的id字段',
content TEXT NOT NULL COMMENT '评论内容',
user_id INT NOT NULL COMMENT '外键关联到用户表的id字段',
root_id INT COMMENT '根评论ID,如果不为空则是回复评论-二级评论,该值是顶级评论的ID',
to_id INT COMMENT '如果为NULL则是回复的顶级评论,不为NULL则是回复的二级评论,表示被回复的评论的ID',
create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP COMMENT '评论创建时间'
);

如果 root_id 和 to_id 都是空,则表示这是一个顶级评论。
如果 root_id 不为空,但是 to_id 为空,则表示这是一个回复顶级评论的二级评论。
如果 root_id 和 to_id 都不为空,则表示这是一个二级评论的回复评论。

放几个头像在这
灼灼某人:
粥粥:https://img01.zzmr.buzz/img/zz.jpg
不靠谱先生:https://img01.zzmr.buzz/img/bkpxs.jpg
定西:https://img01.zzmr.buzz/img/dx.jpg
潘西:https://img01.zzmr.buzz/img/px.jpg

搜索顶级评论的sql:

1
2
3
4
5
6
SELECT c.*,
(SELECT u.nick_name FROM `user` u WHERE u.user_id = c.user_id) AS sender_name,
(SELECT u.avatar_url FROM `user` u WHERE u.user_id = c.user_id) AS sender_avatar_url
FROM `comment` c
WHERE c.recipe_id = #{commentDto.recipeId}
AND c.root_id IS NULL

根据顶级评论id搜索二级评论

1
2
3
4
5
6
7
8
9
10
11
12
SELECT c.*,
s.nick_name AS sender_name,
s.avatar_url AS sender_avatar_url,
s.user_id AS sender_id,
r.nick_name AS receiver_name,
r.avatar_url AS receiver_avatar_url,
r.user_id AS receiver_id
FROM comment c
LEFT JOIN user s ON c.user_id = s.user_id
LEFT JOIN user r ON c.to_id = r.user_id
WHERE c.recipe_id = #{commentDto.recipeId}
AND c.root_id = #{commentDto.rootId}

调研报告

对于微信上热门的菜谱类应用,做出以下总结,分析哪些功能可以做出来,哪些功能没必要做

下厨房

首页内容

  • 搜索框,用于搜索菜谱
  • 展示各种菜类:家常菜,快手菜,下饭菜,早饭等
  • 最后是热门菜谱推荐
  • 23123212937

选菜匹配

  • 搜索框,用于搜索添加自定义食材(数据库中存在的食材)
  • 已选食材,展示已经选中的食材
  • 最近记录,展示最近搜索过的食材
  • 流行食材
    • 时令食材
    • 蔬菜
    • 肉类
  • 20240120213733
    选中食材后进行搜索,根据食材搜索相关菜谱:
  • 024-01-20213811

收藏

  • 显示所搜的收藏夹(分成 所有收藏菜谱自定义收藏夹)
  • 024-01-22203028
  • 所有收藏菜谱点开后,就是一个菜谱列表,并不能进行排序等操作
  • 2024-01-22203246
  • 自定义收藏夹里多了整理,选中后可以进行删除,移动
  • 024-01-22203501
  • 还可以进行添加-从所有菜谱中选
  • 编辑-编辑收藏夹信息-标题和描述
  • 分享
  • 2024-01-22203637

我的

  • 2024-01-22203732
  • 展示用户名,什么时候创建的账号,IP归属地,头像,关注量,粉丝量
  • 菜谱列表,作品列表
  • 设置(编辑个人信息-切换账号)
  • 菜篮子
  • 分享

菜谱分类展示页面

  • 024-01-2204820
  • 2024-01-2204143
  • 分为三种排序方式
    • 综合(默认)
    • 评分
    • 做过最多

菜谱展示页面

  • 2024-01-2204522
  • 封面图
  • 标题
  • 评分
  • 头像-用户名-关注
  • 简介
  • 用料
  • 步骤
  • 作者其他菜谱
  • 最下方是收藏,传作品,分享三个选项

下厨房总结

  • 具有传作品的功能,用户能够在菜谱下面发布自己的作品
  • 具有菜篮子的功能,用户可以将菜谱中的用料加入到菜篮子中
  • 没有评论功能,但是作品功能相当于评论
  • 菜谱中的用料和步骤是单独的,并不是一篇文章到底
  • 能根据食材匹配菜谱

所以,这要求用料单独一张表存

服务器配置

用docker起了一个redis:

1
docker run -p 6379:6379 --name myredis --privileged=true -v /usr/myConfig/myredis/redis.conf:/etc/redis/redis.conf -v /usr/myData/myredis/data:/data -d redis:6.0.8 redis-server /etc/redis/redis.conf

分类设计

有关分类的接口

  1. 获取所有分类
  2. 获取分类对应的菜谱

那么新增分类的接口应该放到哪里呢?

预先设置好大致的分类,不失为一种好的解决方案

TODO:新增菜谱时加上对应的分类

Bug:分类搜索得到的菜谱,其中的时间变成了时间戳

好长时间没写了啊,现在小程序端已经完成了大半了,挺快的?目前好像改有的功能都差不多有了

真不错啊真不错