Thought Persistence

SharpHSql 是一个纯C#写就的支持sql92标准的轻量数据库引擎，当我们为了便于发布而选用单DLL的数据库引擎时，SharpHsql以它的100% managed code而受到青睐。大家一下子欢呼：找到access的替代品了!

但实际上，我认为SharpHsql应该谨慎地用于实际生产环境，我们先来了解一下它的存储原理。

不像其它的纯内存数据库或文件型数据库，SharpHSql在存储数据时相当取巧，使用.cfg文件存放一些数据库的信息和其它文件的位置，使用.log存放所有的DDL SQL，使用.data文件存放Cache的二进制序列化流，用.backup存放.data一样的数据，相当于多一个存放多一层保险。

查看SharpHsql源码，里面的处理还是比较简单的：

每一次insert delete (update会分解成先 delete 再 insert，只是 check 会放到 insert 后进行)都分别有一个 transaction 来对应
这个transaction是用于事务回滚时的rollback的，当rollback时，则用 delete 对应 insert ,用 insert 对应 delete
Table 是通过 Cache 来存放 Rows 的，也就是说数据的实际存储是在 Cache 这个类中
Index类是一棵AVL树，用来数据检索，当有row更新时，如果有索引存在，则需要更新这棵树
Channel就是用了区分transaction和权限检查，实际只是一个process中可以多channel访问同一数据库，而其它的process想访问是不行的
因为Database类打开数据库时，使用的是独占式文件打开，因为如果不独占的话，Cache的写入是会出问题的

数据库打开时的步骤：
1、取cfg文件，得到信息
2、反序列化.data，得到Cache
3、执行.log得到数据库结构

所以我们可以看出SharpHsql是独占式访问的，而且是完全加载所有数据到内存的
这样的结构我觉得仍然应该视其为一个内存数据库引擎，对于数据量会逐渐变大的实际生产环境来说，慎用；对于多并发环境来说，别用
所以SharpHsql要出pocket版本，使用compact framework，看来它的定位也是很准确的

如果利用SharpHSql的sql parser和 execute engine，使用 dataset 代替它的 index 和 cache，是可以很容易写出一个in memory database的，不过这种剽窃意义不大，只是说可行。