sqlite想到一些事2
sqlite是不错的内存数据库，内存数据库是处理大量并发数据的优先选择。但有些大量数据的并发并不是数据处理本身的问题，例如逻辑上必须有先后次序的数据是并发速度不能解决的问题。抛开这些问题一个简单大容量的解决方案是用一个内存数据库做前端一个硬盘数据库做后端，内存数据库定期把数据同步到后端的硬盘数据库。这个方案有个问题就是如何同步，同步分为两种一种是更新合并，一种是直接复制。更新合并是指把更改过的数据提交到后端数据库进行合并，直接复制指无论是否更改都把整个数据库的数据同步过来。处理这两种方式的办法是不同的，更新合并可以记录更改数据的指令简单的可以记录更改的表，复杂的可以记录更改的列甚至项。第一种方式只要简单的匹配sql指令后一种方式需要模拟运行。在某一时间点上把更改过的表更新到备份数据库上。直接复制就是无论表项是否更改都更新到备份数据库。sqlite有个看起来是个问题的问题，就是不能线程安全的插入和更新。这个问题sqlite在linux系统上解决的是满好的使用的是硬盘分区的锁可以和sqlite页缓冲系统完美的结合在一起。不过要是拿sqlite当内存数据库脱离硬盘的文件系统恐怕就要自己想办法解决多线程问题。才用软件锁解决线程安全是一个伪命题。用一个软件标示锁住库或表或表项，都会存在一个问题。无论锁在哪访问数据都变成了，询问锁再读取数据的两个步骤。极端的情况下对一个数据的访问由原来的一次操作变成了两次操作查询和插入。如果查询不成功那么要对插入指令排序，这个指令的排序当然要先进先出而不能是争用的。sqlite内存数据库很迷人最大的优点是平衡的读取和写入的在硬盘数据库上的差距。
相关文档：
这两天C/S的项目中用到了sqlite，这个小东西还真是好用。访问速度很快不说，生成的数据库文件也很小。非常适合小型项目的数据库。wince中强烈建议使用。
不过今天遇到一个问题让人头大，delete数据的时候提示no such table。
数据库中的表明明存在，在数据库中执行delete的sql也没有问题。看来不是sql语句的问题。
但是� ......
SQLite和其他大部分现代SQL数据库在基本设计目标上是不同的，它的目标是简单。SQLite遵循这一目标，即使这样偶尔会导致某些特性实现的低效化。下面列举了SQLite的一些缺陷：
SQL-92特性方面
正如前面提到的，SQLite不支持SQL-92的在很多企业数据库系统中可用的一些特性。
如：
外键约束（可解析的，但非强制）
很多ALT ......
主要通过pragma指令来实现。
比如： 空间释放、磁盘同步、Cache大小等。
不要打开。前文提高了，Vacuum的效率非常低！
PRAGMA auto_vacuum;
PRAGMA auto_vacuum = 0 | 1;
查询或设置数据库的auto-vacuum标记。
正常情况下，当提交一个从数据库中删除数据的事务时，数据库文件不改变大小。未使用的文件页被标记并在以 ......
这篇文章是使用SQLite C/C++接口的一个概要介绍和入门指南。
由于早期的SQLite只支持5个C/C++接口，因而非常容易学习和使用，但是随着SQLite功能的增强，新的C/C++接口不断的增加进来，到现在有超过150个不同的API接口。这往往使初学者望而却步。幸运的是，大多数SQLite中的C/C++接口是专用的，因而很少被使用到。尽管有这 ......
import os
import unittest # 包含单元测试模块
import sqlite3 as sqlite # 包含sqlite3模块
def get_db_path():
return "sqlite_testdb"
class TransactionTests(unittest.TestCase): # 单元测试第一步: 由TestCase派生类
def setUp(self): # 单元测试环境配置
......
