DAL 又更新了
经过一个月的忙碌，DAL 又更新了，内部版本号为 2.3.5。这个版本主要改进以下几点：
协议改进。之前版本的 DAL 使用 php 序列化作为数据传输协议，这是一个历史遗留的问题，因为最早的 DAL 是完全用 php 实现的。现在仔细考虑过后认为 php 序列化肯定不是好的编码格式，首先 php 序列化是文本格式的，并不高效；还有很致命的一点就是 php 对数据类型支持很差。比如：php 不支持 double 类型，如果打算用 java 语言实现一个 DAL 客户端，那么这里无疑是丢失了数据类型信息，所以 php 序列化肯定是不够用的。新的编码格式目标就是高效，并且对数据类型有良好支持。参考了 mysql 数据库协议和 igbinary 序列化格式，最终考虑采用二进制协议。如何支持数据库的多种数据类型呢？我们是这么做的，server 端返回的查询数据是一个表格，表格有表头和表内容，我们在传输表头时就传输了每列的列名和列类型，这里列类型和 JDBC 的数据类型是一致的，表内容全部采用字符串编码，这样可能会多传输一些字节，但是避免了精度问题，因为数字也是用字符串编码的，当然没有精度问题。这样的好处是 DAL 不同的客户端可以根据各自语言特点来解码。协议设计好后先用 php 实现了一个版本的解码器，由于 php 本身性能问题导致 php 版的解码器效率比较低。接下来又用 php 扩展实现了解码器，性能有大幅度提高。在大数据解码方面比 php 序列化快几十倍，比 igbinary 快一点点。
对数据库函数的处理。DAL 需要操作缓存，需要考虑数据库切分，所以不得不分析用户的查询请求。如果用户使用了数据库函数，这个分析就变的异常困难，因为你不知道（很难知道）用户调用的函数中使用了什么函数，涉及到哪些字段。目前的临时解决办法是：只要用户使用了数据库函数，用户就必须显示的指定是否缓存；如果用户这个请求需要辅助表完成，那么 DAL 会强制选择第一个辅助表而不进行任何优化选择（关于辅助表选择优化请看《DAL 最近的一些进展》）。
数据库条目缓存结构调整。以前数据库条目缓存包含了条目的属性和数据两部分信息。很显然，没必要缓存条目的属性，因为条目属性在系统启动时就可以加载，在整个系统运行期间不会改变，没必要每次写到缓存里。缓存数据库条目时所有字段都是按字符串格式存储的，这样做无疑增加了缓存条目的体积，但换来的是保证不会在 server 端丢失数据精度，同时数据格式和协议是一致的，便于操作。
大体就是这些改进，关于 DAL 的介绍可以看超前同学的博客。在这段开发过程中接触了很多开源软件，也浏览过一些源代码，个人认为 [...]