SQLITE入门至精通(下)

SQLITE入门至精通(下)

2010年06月03日 星期四 15:24

http://wangleifire.javaeye.com/blog/635770   如何在字符串中使用单引号(')？ SQL 标准规定，在字符串中，单引号需要使用逃逸字符，即在一行中使用两个单引号。在这方面 SQL 用起来类似 Pascal 语言。 SQLite 尊循标准。如：     INSERT INTO xyz VALUES('5 O''clock'); Sqlite 中如何返回本地化当前时间？ 在做ClinicOS的时候遇到一个问题，在保存病历登记时间时，我使用了“CURRENT_TIMESTAMP”，但这有个问题，它返回的是UTC Time，这对我们中国人没啥用，一直希望能想办法将它转为localtime。今天刚好有空，所以去查了查Sqlite 的Mail List，果然也有人遇到了这个问题，我从一篇名为《translate time comparison statement》（http://www.mail-archive.com/sqlite -users@sqlite .org /msg12350.html）中看到这样的回复： Mark Wyszomierski wrote: You may want WHERE julianday(date('now')) - julianday(date(arrival_date)) > 7 Mark, You should still use the 'localtime' modifier on the 'now' value if your timestamps are local time since 'now' always returns UTC times. WHERE julianday(date('now', 'localtime')) - julianday(date(arrival_date)) > 7 嘿嘿，看来如果想得到一个符合本机区域设置的当前时间，必须用date函数来转换， 但date只函数只返回当前日期，而我需要的是返回当前日期及时间，所以这里把它换成datetime函数，即： datetime(CURRENT_TIMESTAMP,'localtime') 以下是sqlite 下测试的输出信息： sqlite > select CURRENT_TIMESTAMP; 2006-06-18 09:23:36 sqlite > select datetime(CURRENT_TIMESTAMP,'localtime'); 2006-06-18 17:23:44 sqlite > SQLITE 分页 刚开始的时候没注意语法 后来才发现，原来用SQLite 分页是世界上最简单的。 如果我要去11-20的Account表的数据 Select * From Account Limit 9 Offset 10; 以上语句表示从Account表获取数据，跳过10行，取9行 嗯，我觉得这个特性足够让很多的web中型网站使用这个了。 也可以这样写 select * from account limit10,9和上面的的效果一样。 这种写法MySQL也支持。 SQLite 适用的范围   SQLite 不同于其他大部分的SQL数据库引擎,因为它的首要设计目标就是简单化: 易于管理 易于使用 易于嵌入其他大型程序 易于维护和配置 许多人喜欢SQLite 因为它的小巧和快速. 但是这些特性只是它的部分优点, 使用者还会发现SQLite 是非常稳定的. 出色的稳定性源于它的简单, 越简单就越不容易出错. 除了上述的简单、小巧和稳定性外, 最重要的在于SQLite 力争做到简单化. 简单化在一个数据库引擎中可以说是一个优点, 但也可能是个缺点, 主要决定于你想要做什么. 为了达到简单化, SQLite 省略了一些人们认为比较有用的特性, 例如高并发性、严格的存取控制、 丰富的内置功能、 存储过程、复杂的SQL语言特性、 XML以及Java的扩展, 超大的万亿级别的数据测量等等. 如果你需要使用上述的这些特性并且不介意它们的复杂性, 那么SQLite 也许就不适合你了. SQLite 没有打算作为一个企业级的数据库引擎, 也并不打算和Oracle或者PostgreSQL竞争. 仅凭经验来说SQLite 适用于以下场合: 当你更看中简单的管理、使用和维护数据库, 而不是那些企业级数据库提供的不计其数的复杂功能的时候，使用SQLite 是一个比较明智的选择. 事实也证明, 人们在许多情况下已经清楚的认识到简单就是最好的选择. SQLite 最佳试用场合 网站 作为数据库引擎SQLite 适用于中小规模流量的网站(也就是说, 99.9%的网站). SQLite 可以处理多少网站流量在于网站的数据库有多大的压力. 通常来说, 如果一个网站的点击率少于100000次/天的话, SQLite 是可以正常运行的. 100000次/天是一个保守的估计, 不是一个准确的上限. 事实证明, 即使是10倍的上述流量的情况下SQLite 依然可以正常运行. 嵌入式设备和应用软件 因为SQLite 数据库几乎不需要管理, 因此对于那些无人值守运行或无人工技术支持的设备或服务, SQLite 是一个很好的选择. SQLite 能很好的适用于手机, PDA, 机顶盒, 以及其他仪器. 作为一个嵌入式数据库它也能够很好的应用于客户端程序. 应用程序文件格式 SQLite 作为桌面应用程序的本地磁盘文件格式取得了巨大成功.例如金融分析工具、CAD 包、档案管理程序等等. 一般的数据库打开操作需要调用sqlite3_open()函数，并且标记一个显式本地事务的起始点（BEGIN TRANSACTION）来保证以独占的方式得到文件的内容. 文件保存将执行一个提交（COMMIT）同时标记另一个显式本地事务起始点. 这种事务处理的作用就是保证对于应用程序数据文件的更新是原子的、持久的、独立的和一致的. 数据库里可以加入一些临时的触发器,用来把所有的改变记录在一张临时的取消/重做日志表中. 当用户按下取消/重做按钮的时候这些改变将可以被回滚. 应用这项技术实现一个无限级的取消/重做功能只需要编写很少的代码. 替代某些特别的文件格式 许多程序使用fopen(), fread(), 或 fwrite()函数创建和管理一些自定义的文件用来保存数据. 使用SQLite 替代这些自定义的文件格式将是一种很好的选择. 内部的或临时的数据库 对于那些有大量的数据需要用不同的方式筛选分类的程序, 相对于编写同样功能的代码, 如果你把数据读入一个内存中的SQLite 数据库, 然后使用连接查询和ORDER BY子句按一定的顺序和排列提取需要的数据, 通常会更简单和快速. 按照上述的方法使用内嵌的SQLite 数据库将会使程序更富有灵活性, 因为添加新的列或索引不用重写任何查询语句. 命令行数据集分析工具 有经验的SQL用户可以使用SQLite 命令行程序去分析各种混杂的数据集. 原是数据可以从CSV（逗号分隔值文件）文件中导入, 然后被切分产生无数的综合数据报告. 可能得用法包括网站日志分析, 运动统计分析, 编辑规划标准, 分析试验结果. 当然你也可以用企业级的客户端/服务器数据库来做同样的事情. 在这种情况下使用SQLite 的好处是: SQLite 的部署更为简单并且结果数据库是一个单独的文件, 你可以把它存储在软盘或者优盘或者直接通过email发给同事. 在Demo或测试版的时候作为企业级数据库的替代品 如果你正在编写一个使用企业级数据库引擎的客户端程序, 使用一个允许你连接不同SQL数据库引擎的通用型数据库后台将是很有意义的. 其更大的意义在于将SQLite 数据库引擎静态的连接到客户端程序当中，从而内嵌SQLite 作为混合的数据库支持. 这样客户端程序就可以使用SQLite 数据库文件做独立的测试或者验证. 本文来自: (www.91linux.com) 详细出处参考：http://www.91linux.com/html/article/database/sqlite /200812/12-14611.html   数据库教学 因为SQLite 的安装和使用非常的简单(安装过程几乎忽略不计, 只需要拷贝SQLite 源代码或sqlite .exe可执行文件到目标主机, 然后直接运行就可以) 所以它非常适合用来讲解SQL语句. 同学们可以非常简单的创建他们喜欢的数据库, 然后通过电子邮件发给老师批注或打分. 对于那些感兴趣怎样实现一个关系型数据库管理系统（RDBMS）的高层次的学生, 按照模块化设计且拥有很好的注释和文档的SQLite 源代码, 将为他们打下良好的基础. 这并不是说SQLite 就是如何实现其他数据库引擎的精确模型, 但是很适合学生们了解SQLite 是如何快速工作的, 从而掌握其他数据库系统的设计实现原则. 试验SQL语言的扩展 SQLite 简单且模块化的设计使得它可以成为一个用来测试数据库语言特性或新想法的优秀的原型平台. 哪些场合适合使用其他的关系型数据库管理系统（RDBMS） 客户端/服务器程序   如果你有许多的客户端程序要通过网络访问一个共享的数据库, 你应当考虑用一个客户端/服务器数据库来替代SQLite . SQLite 可以通过网络文件系统工作, 但是因为和大多数网络文件系统都存在延时, 因此执行效率不会很高. 此外大多数网络文件系统在实现文件逻辑锁的方面都存在着bug(包括Unix 和windows). 如果文件锁没有正常的工作, 就可能出现在同一时间两个或更多的客户端程序更改同一个数据库的同一部分, 从而导致数据库出错. 因为这些问题是文件系统执行的时候本质上存在的bug, 因此SQLite 没有办法避免它们. 好的经验告诉我们, 应该避免在许多计算机需要通过一个网络文件系统同时访问同一个数据库的情况下使用SQLite . 高流量网站 SQLite 通常情况下用作一个网站的后台数据库可以很好的工作. 但是如果你的网站的访问量大到你开始考虑采取分布式的数据库部署, 那么你应当毫不犹豫的考虑用一个企业级的客户端/服务器数据库来替代SQLite . 超大的数据集 当你在SQLite 中开始一个事务处理的时候(事务处理会在任何写操作发生之前产生, 而不是必须要显示的调用BEGIN...COMMIT), 数据库引擎将不得不分配一小块脏页(文件缓冲页面)来帮助它自己管理回滚操作. 每1MB的数据库文件SQLite 需要256字节. 对于小型的数据库这些空间不算什么, 但是当数据库增长到数十亿字节的时候, 缓冲页面的尺寸就会相当的大了. 如果你需要存储或修改几十GB的数据, 你应该考虑用其他的数据库引擎. 高并发访问 SQLite 对于整个数据库文件进行读取/写入锁定. 这意味着如果任何进程读取了数据库中的某一部分, 其他所有进程都不能再对该数据库的任何部分进行写入操作. 同样的, 如果任何一个进程在对数据库进行写入操作, 其他所有进程都不能再读取该数据库的任何部分. 对于大多数情况这不算是什么问题. 在这些情况下每个程序使用数据库的时间都很短暂, 并且不会独占, 这样锁定至多会存在十几毫秒. 但是如果有些程序需要高并发, 那么这些程序就需要寻找其他的解决方案了