Python-FastAPI异步框架博客系统开发（一）数据建模篇

Frodo的第一个版本已经实现了，在下一个版本前，我将目前的开发思路整理成三篇文章，分别是数据篇、通信篇、异步篇。

项目地址
Frodo

简要系统分析

数据库设计是紧跟需求来的，在我本科学UML时，数据库设计是在需求分析和系统分析之后，架构设计之前的设计。但博客项目的需求比较简单，主要大需求:

• 内容管理（文章、用户、标签、评论、反馈、动态的增删改查）
• 管理员用户的验证、评论人用户的验证
• 小功能：边栏组件、归档、分类等

再简单地做一个系统分析：

• 博客前台页面（不需要认证，内容展示）
  • 博文内容
  • 博客作者
  • 标签
  • 访问量
• 管理页面（需要登录认证进行内容管理）
• 动态页面（需要认证）
• 评论（访问者需要登录认证）

接下来的工作就是根据功能需求设计前后台API，一般如果你是全栈自己开发的话，API形式可以随意些，因为后续还可以灵活调整。如果需要和前端同事合作的话，你需要严格按照restful风格编写，接口的参数、命名、方法和返回体的构造上严格体现需求。

API 格式理应最大化地体现功能需求

前后台API的形式也取决于所用技术，Frodo前台页面是选择模板渲染的，后台是使用Vue, 那么模板就可以在页面上编程，可以实时决定上下文，可以不事先指定。

后台API

url	method	params	response	info
api/posts	GET	limit:1 page: 页面数 with_tag	{‘items’: [post.*.,], ‘total’: number}	查询Posts 需要登录
api/posts/new	POST	FormData title slug summary content is_page can_comment author_id status	x	x
api/post/<post_id>	GET/PUT/DELETE	x	items.*.created_at items.*.author_id items.*.slug items.*.id items.*.title items.*.type items.*._pageview items.*.summary status items.*.can_comment items.*.author_name items.*.tags.* total	需要登录
api/users	GET	x	{‘items’:[user.*.,], ‘total’: num}	需要登录
api/user/new	POST	FormData active name email password avatar: avatar.png	x	需要登录
api/user/<user_id>	GET/PUT	x	user.created_at user.avatar user.id user.active user.email user.name user.url(/user/3/) ok (true)	需要登录
api/upload	POST/OPTIONS	x	x	na
api/user/search	GET	name	items.*.id items.*.name	需要登录
api/tags	GET	x	items.*.name	需要登录
api/user/info	GET	user (token)	user{‘name’, ‘avartar’}	相当于current_user
api/get_url_info	POST	url	x	na
api/status	POST	text, url, fids = [“png”, …]	r, msg, activity.id, activity.layout, activity.n_comments, activity.n_likes, activity.created_at, activity.can_comment, activity.attachments.*.layout, activity.attachments.*.url, activity.attachments.*.title, activity.attachments.*.size

数据库设计

设计数据库就是设计表、表字段、表关系。严格上要先绘制E-R模型图，他金石停留在逻辑层面的关系图。下一步根据E-R图，结合使用的数据库类型（关系、Nosql、KV还是图数据库）设计表关系图，随后要考虑如下几个方面：

• 数据存储在哪里？
  • 小型记录数据存储在mysql （查询较快）
  • 长数据如「博客内容」查询较慢 适合存储在内存数据库
  • 分布式还是单一式存储？
• 那些是高频使用数据？
  • 经常需要做查询的
  • 需要经常累加、统计计算的
  • 经常不变化的
• 持久化方案
  • 数据库如何定期备份？
  • KV数据库的过期策略、定期存储策略

其实博客项目很多都不需要考虑，但再大的项目这些都需要考虑了。其实还应该考虑的是数据库并发访问的问题，这涉及到锁与同步机制，这部分我再通信 部分阐述。

思考过上述问题后，大致有如下图形：

上图中不同的颜色字段考虑了不同的特点，分别是：

• 数据库存储，选用mysql
• KV存储，选用redis
• 高频字段项，需要缓存选用redis或memcached

ORM类设计模式

ORM 是简化SQL操作的产物，python将其做的最好的就是Django框架，主要做两件事：

• 类到数据库表的映射(通过改造元类实现，达到创建这些_类_时便有了table属性，注意不是类实例)
• 提供简化的面向对象的sql操作接口

表结构与表迁移

表结构在类中体现，Frodo使用的sqlalchemy是采用Column()类的形式。在类比较多是，建议先写一个_基类_，规定共有字段，在会面还可以规定共有方法。