这段时间在做cms（客户管理系统，不是内容管理）的访问管理功能，要求实现对服务提供设备，客户端，计费，权限认证等信息的存储统计，远程管理。要求系统发布要方便，远程管理软件要跑在win平台。考虑到系统规模，客户要求，最后选择了win+access的方案，而最近又发现一个免费的sqlite，而且可能在以后的手持设备上用，花点时间做了如下的简单性能测试。
access 插入性能测试：
平台：sys:winxp;cpu:2*1.6ghz;ram:1g;app:vc+ado
1.单条显式事务：
1 00条： 0.55s
1000条： 5s
10000条： 50s
2.单条非显式事务：
100条：31ms
1000条：156ms
10000条：1500ms
3.批量事务：
1 00条：16ms
1000条：141ms
10000条：1469ms
以上可以看出，access单条非显式事务插入的时间几乎和批量事务的插入时间一样。但是，单条非显式事务的
方式只能用单连接，如果有多个连接并发访问，则会出现严重问题，在一个链接插入后的相当长一段时间内（有时数s），其它链接都无法插入数据库。可以推理
ado+access是采用了一种类似cache的做法缓存了操作，但是却一直锁住数据库。单条的显式事务可以保证多链接的访问，但是速度会慢很多，下面再对比一下
sqlite的测试性能；
sqlite pc平台插入性能测试：
平台：sys:winxp+vmware+fedora7(linux2.6.21)；cpu;1.6ghz;ram:412m; app:c+sqlite
1.单条显式事务（sqlite默认为每个操作开启事务）
100条：0.587s
1000条：6.962s
10000条：56.004s
2.批量事务
100条：81ms（可能误差较大）
1000条：124ms
10000条：1257ms
sqlite 嵌入式平台插入性能测试：
平台：sys:linux2.6.14;cpu:hi3512 arm9 200mhz级别；ram:32m,rom:32m nor flash;app:c+sqlite
1.单条显式事务（sqlite默认为每个操作开启事务）
100条：1.98s
1000条：19.97s
10000条：34.63s
2.批量事务
100条：0.15s
1000条：0.89s
10000条：8.24s
在arm+linux的平台，nor flash较慢的写入速度应该是拉低插入速度的原因。