用框架是把精力放在逻辑处理上,我们只需要写request_handler,现在基本都是BS,BS的浏览器一般有兼容问题,还强行限制了程序员调用操作系统资源的能力,在html5做了升级,但是一硬件和软件的兼容性是个问题,我们用ES6就不害怕因为有babel的,可以抹平浏览器不支持的功能,这样开发就比较安全,浏览器兼容问题也解决的不错。
用html5就不行,因为调用的是浏览器本身的能力,渲染引擎没办法
内部如果需要高效通信,就是进程间通信,往往需要IPC,但是跨网络的就需要用RPC远程过程调用,而且要用通用框架,这样c端可以用python,服务端可以c++,因为只要把网络协议搞定即可,用什么语言写都可以
博客项目给客户用的,就应该选择BS开发,客户选择最通用的浏览器登录,使用我们的博客系统即可,对应server,用python,使用WSGI的django框架
博客最重要的功能就是增删改查博文,博文跟用户管理,核心两大功能,用户管理和博文管理。博客要让用户产生黏性,依然是好的博文,没有内容是客户不来的。
用户管理:增删改查用户
博客管理,增删改查博客,也可以公开私有。博文跟用户相关。
目前这些数据都要持久到数据库中,最常用的mysql。支持事务,innodb引擎。
博客的查,一般不需要用户登录。
一般先设计核心部分
有了用户才有文章,所以先把用户相关的内容设计出来
找一个空的数据库
建模可以脱离数据库,只是一种数据库的描述,可以转换成任何一种数据库,甚至可以生成代码,这周工具很多,比如IBM的,还有powerdesigner
百分之99.9的表上来先创建ID,单主键有单主键的好处。一般人一两个密码闯一个互联网。所以找一个运维差一点数据库,撞其他的网站,不是不可能,就看你值得不指的偷信息了。数据库密码一定不能放明文。删是假删,做一个标记,tinyint只有1个字节,但是有256种数据,2个字节就是65536种
先不要删除标记字段,把精力放在最主要的业务上
一般人不爱填兴趣爱好,但是我们又要做数据分析,有些网站就先让你填用户名密码登录,然后鼓励你去填写完,给你点积分,这样好做分析。
注册的时候,name可以重复,email不能重复,所以可以加索引
记得自增
**真的在生产情况下,是用模型工具建立模型好后,由它生成所有表的构建,create table。基本不太用ORM来生成表 **
现在来设计另外一张表,博文管理,也是一开始加ID,可以用字符串,但是整数相比字符串少点空间,主键只要是唯一,不为空即可,博客有标题title,控制下字数
postdate上传时间。
author一般一篇博客只有一个作者,使用int类型,其实就是作者id,这个作为外键关联起来,也就是当你在post添加记录,要求作者id必须在用户表里存在。
我们允许修改文章内容,但是不能修改作者,不符合业务,post作为从表在数据库是可以还换author_id的,但是外键约束也会控制你作者必须在user表里有,但是从业务上这是不允许
但是如果用户删除,可能就只能把值设置为null,但是一般不允许用户删除,可以换成打标签,禁用,一旦禁用,所有文章都不可看
一对多的关系,主表里有主键,从表里有一个引用了主键,外键放从表
如果不想在从表放外键,如何解决一对多关系,思考一下,比如用户可以上传多个文章,这一部分整体是一个字段,要查询5号文章谁写的
不真的添加,只是预算一下
可以描述一对多,但是like出现了就应该放弃,效率太低
这就是为什么一对多的总结就是用外键,外键放从表,这有这种才能表述出来
作者必须有,不能为空
加外键,默认restrict严格,限制你,主表里删除,阻止你,主表里做更新,阻止你
**post创建了一个,建了一个约束constarint 外键 post_ibfk_l author字段关联到了user表id **
还没完,存放文章的内容的字段还没有,如果用文本存,文件系统是很浪费空间的,需要考虑的东西更多
博客文章字数太多,就不用考虑char和varchar了,试试text,或者longtext(我们也需要限制下博客的长度)
longtext字符达2的32-1个次方,足够用了,也要限制长度
写博客的时候,如果图片拖拽一下,弄个URL,实际上这就是盗链,不合适,博客为生的网站不允许盗链,往往博客网站都会有一个在线文本编辑器,JS写的,都会提供一个上传图片的功能,会有两种能力,一种是使用url,第二种是上传图片。上传的图片就需要把你的图片从本地通过网络传递给服务器端,服务器端存文件系统(比如马蜂窝这个网站,专门存图片,该怎么存,对文件系统压力很大,分文件大小最小的是4K,小文件其实也是很占地方的)
图片是很难解决的问题,也有一般使用缩略图来看,符合网站布局,点击才从服务器下载原图,不然图片服务器根本扛不住
就算大小图可以解决一些问题,在线压缩也会浪费cpu时间,jpeg为例,其实压缩就是牺牲了细节,压得越狠,cpu耗费的越多,给图片打自己网站的logo。
也就是原来只有一个原图,现在变成了有缩略图,缩略图往往是小图,所以网站往往需要存储大小图,存储起来更难
数据库里存的其实就是url,还有一些人上传了图片,但是没有用,这么多图片也会增加压力,博客系统其实最大的问题还是在图片
text字段是否适合放在表中
分析业务:虽然有人看博客但是看标题的人更多,也就是实际上post这张表查的还是比较频繁的,但是内容相比查post的标题要少的很多,对于这种大字段,习惯是分离出去
把大内容字段分离
再建一张表,首先是id,text文本字段如果具有特殊性,建议和其他字段分离
一篇文章有一个内容,是一对一的关系,同一篇文章的内容插入,一一对应
典型的一一对应关系
保存content表
应该post表要删除,content表也要删除,id不允许更新,这里如果加ID就是保证content的id在post是一定存在的
content的表iD来自post表中的id
其实所有的外键都可以在代码的逻辑层控制外键约束,但是一开始开发人对表不熟悉,就需要加外键约束,可以保证数据完整性。
增删改用的少,查的多,外键带来的性能其实也是很少的
通过这样,主要业务的三张表设计并且分析完成
post和content是一对一的关系
这次试用django的orm工具来生成表
用户需要的功能
post表和content表
用着三张表可以完成最核心功能