2020/02/24 05-核心表设计

用框架是把精力放在逻辑处理上,我们只需要写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表

用着三张表可以完成最核心功能