2016-7-1 杂感

数据库中视图是什么，可以理解为视图是物理表的一种抽象，其建立在select语句之上，提供了对频繁访问的列聚合，视图不仅仅是只读的，同时也可以进行写操作，对视图的写入操作同步到物理存储的表格的过程有不同的算法，和其他算法类似，有立即同步的，也有延迟同步的。对于视图的理解，联想到了之前看的数据库中select的执行过程，具体是结果的组织，MySQL的命令行中Select的执行结果的展示和一个表格一样，有列名和对应的数值，在数据库的实现中，也有临时表的概念，即Select的执行结果是通过这个临时表来组织的，也是通过读取这个临时表来展示的，具体表格的内容通过Select语句来定义，但是想一想，这个表格中的数据存放在哪？内存？磁盘？现在想到的是，对于结果集小的数据，可以放在内存中，但是如果结果集太大，或者是多个表联合查询，怎么处理？具体数据怎么组织，还需要多了解了解。

通过视图这种定义方式，也为数据库中的数据提供了一层逻辑保障，即用户看到的是更高一层的数据展示。

另一个话题，MOBA类游戏的同步怎么做。

  先说通信，通信协议选TCP还是UDP，今天的老师说TCP的重传啊，拥塞控制啊，使得TCP的效率不如UDP，这个我不是很同意，首先，在网络状况好的情况下，UDP的通信效率是要比TCP高一点，因为从协议栈的层面来看，UDP的传输路径要短一点，协议实现的复杂度也低；其次，在网络状况不好的情况下，TCP的重传和拥塞控制是在内核层实现的，而可靠UDP是在应用层实现的，这个效率是不是比TCP高，还需要具体验证；最后，提到说TCP头部长度要长于UDP，使得有效载荷低，这个我觉得可以忽略了，TCP头部长度20字节，UDP 8字节。

再来说具体的同步方案，C/S 还是 帧同步

（1）C/S，在有网络延迟的情况下，会出现操作有延迟的情况，或者说客户端有预展示逻辑时，和服务器不同步时，会出现拉扯，影响用户体验

（2）帧同步，第一视角操作流畅，但是同样考虑到网络情况，第三方视角中会出现不一致现象。帧同步也需要考虑作弊问题

之前项目中是采用C/S，但是后面客户端拉扯的问题没有解决，后面更新为帧同步方式，现在还存在小幅度的不同步现象，还需要进一步调试。

实践出真知，先简单的使用，然后有可能了看看源码，看看人家是怎么实现的，算法，思路等等。不像现在这样，脑袋一拍，信口胡说，理论都不一定掌握好了。

明天早上如果天气好，跑步~