Fighting for Dream

SQLite

　　★技术上的优点和特性
　　SQLite是一个轻量级、跨平台的关系型数据库。既然号称关系型数据库，支持SQL92标准中常用的玩意儿（比如视图、事务、触发器等）就是理所当然的了，咱今天就不细说了。今天主要聊聊一些有点特色的玩意儿。

　　◇轻量级
　　先说它的第一个特色：轻量级。想必SQLite的作者很看重这个特性，连它的Logo都是用的“羽毛”，来显摆它的轻飘飘。
　　SQLite和C/S模式的数据库软件不同，它是进程内的数据库引擎，因此不存在数据库的客户端和服务器。使用SQLite一般只需要带上它的一个动态库，就可以享受它的全部功能。而且那个动态库的尺寸也挺小，以版本3.6.11为例，Windows下487KB、Linux下347KB。

　　◇绿色软件
　　SQLite的另外一个特点是绿色：它的核心引擎本身不依赖第三方的软件，使用它也不需要“安装”。所以在部署的时候能够省去不少麻烦。

　　◇单一文件
　　所谓的“单一文件”，就是数据库中所有的信息（比如表、视图、触发器、等）都包含在一个文件内。这个文件可以copy到其它目录或其它机器上，也照用不误。

　　◇跨平台/可移植性
　　如果光支持主流操作系统，那就没啥好吹嘘的了。除了主流操作系统，SQLite还支持了很多冷门的操作系统。我个人比较感兴趣的是它对很多嵌入式系统（比如Android、Windows Mobile、Symbin、Palm、VxWorks等）的支持。

　　◇内存数据库（in-memory database）
　　这年头，内存越来越便宜，很多普通PC都开始以GB为单位来衡量内存（服务器就更甭提了）。这时候，SQLite的内存数据库特性就越发显得好用。
　　SQLite的API不区分当前操作的数据库是在内存还是在文件（对于存储介质是透明的）。所以如果你觉得磁盘I/O有可能成为瓶颈的话，可以考虑切换为内存方式。切换的时候，操作SQLite的代码基本不用大改，只要在开始时把文件Load到内存，结束时把内存的数据库Dump回文件就OK了。在这种情况下，前面提到的“online backup API”就派上用场了，聪明的同学应该明白我为啥这么期待backup功能了吧？

　　★技术上的缺点和不足
　　前面光聊了特性和优点，为了避免枪手写软文的嫌疑，再来说说SQLite的一些缺点。列位看官将来如果想用它，这些缺点要权衡一下。

　　◇并发访问的锁机制
　　SQLite在并发（包括多进程和多线程）读写方面的性能一直不太理想。数据库可能会被写操作独占，从而导致其它读写操作阻塞或出错。

　　◇SQL标准支持不全
　　在它的官方网站上，具体列举了不支持哪些SQL92标准。我个人感觉比较不爽的是不支持外键约束。

　　◇网络文件系统（以下简称NFS）
　　有时候需要访问其它机器上的SQLite数据库文件，就会把数据库文件放置到网络共享目录上。这时候你就要小心了。当SQLite文件放置于NFS时，在并发读写的情况下可能会出问题（比如数据损坏）。原因据说是由于某些NFS的文件锁实现上有Bug。

　　★编程语言接口
　　SQLite支持很多种语言的编程接口。这对于我这种喜欢混用多种编程语言的人来说，是很爽的。下面我大概介绍一下。

　　◇C/C++
　　由于SQLite本身是C写的，它自带的API也是C接口的。所以C/C++用起来最直接了。假如你不喜欢面向过程的C API风格，可以另外找个C++的包装库。想重新发明轮子的同学，也可以自己包装一个。
　　◇Java
　　如果要用Java访问SQLite，可以通过SQLite的JDBC驱动，或者通过专门的SQLite包装库。我个人建议走JDBC方式，万一将来要换数据库，代码就不用大改。
　　◇Python
　　pysqlite是Python操作SQLite的首选。从Python 2.5开始，它已经被整合到Python的标准库中。看来Python社区还是蛮喜欢SQLite嘛。
　　◇dotNet
　　对于喜欢dotNet的同学，可以通过SQLite的ADO.NET驱动来访问。
　　◇Ruby
　　Ruby可以通过SQLite-Ruby操作SQLite数据库，不过我没用过。
　　◇Perl
　　在CPAN上有DBD::SQLite，不过我也没用过。

　　★一些非技术的参考因素
　　前面讲的都是技术层面的话题，如果你考虑在公司的商业软件项目中使用SQLite。还需要根据“如何选择开源项目”里面提到的几个参考因素，再评估一下。
　　◇授权协议（License）
　　SQLite使用的是Public Domain协议，这是最爽一种，可以放心大胆地用。
　　◇用户的普及程度
　　最近这几年，使用SQLite的人越来越多（从Google Trends可以反应出来）。包括一些大公司也开始把它整合到产品中（比如Google的Gears、Apple的Safari、Adobe的AIR）。这说明它的健壮性、稳定性等方面不会有太大问题。
　　◇开发的活跃程度
　　如果到SQLite的Change Log上大致了解一下，可以看出最近5年基本上每1-2个月都会有更新。说明开发的活跃度还是非常高的。
　　从上述几个非技术因素来看，SQLite用于商业公司的软件项目还是非常靠谱的。

ORACLE客户端与服务器连接

　　对于初学者，关于客户端工具与数据库服务器的连接总是会存在如下的疑问：
　　我一定要在本地机器上面安装Oracle数据库吗？
　　如果我在本地安装了Oracle数据库，为什么还要配置一个TNS来连接数据库呢，它怎么这么笨呢？
　　如果本地可以不安装数据库，那又怎么弄呢？
　　还有SQL*Plus，PL/SQL Developer和Oracle数据库有什么关系呢？
　　要弄清楚上面的问题和这些名词之间的关系，我下面就以一个比较笨拙的比喻来说明：
　　首先需要了解两个进程(Windows平台)：Oracle数据库进程和Oracle数据库服务监听进程。如果按照这两个进程来划分安装阶段的话，我们可以将安装阶段分为数据库后台系统安装和创建数据库两个阶段，而数据库进程和数据库服务监听进程分别就是两个安装阶段创建的。
　　而第一个阶段安装完成后，其实Oracle数据库并没有“真正数据库”的功能，因为它只是具备了管理数据库能力的一个基础系统，并不能存储数据。就像盖房子，需要先有块地皮，才能盖房子，但是光地皮它还不是房子。而如果Oracle数据库进程成功启动了，说明养?上面我们可以清楚，如果我需要操作数据库服务器，只要如下条件就可以了：
　　知道TNS，即数据库地址相关的信息
　　具备Oracle Net软件层
　　客户端应用
　　TNS的知识已经足够了，那怎么样才能使自己的系统中拥有Oracle Net软件层呢？有几种途径：
　　专门安装Oracle Client软件，可以从Oracle网站下载
　　安装Oracle开发工具，如Form、Report、Discoverer等等，因为这些软件也带了Oracle Net软件层
　　安装Oracle数据库，它也带了Oracle Net软件层
　　而我们需要的是一个客户端应用，以便我们来操作数据库，SQL*Plus就是Oracle很多产品中自带的一个应用工具，而PL/SQL Developer则是第三方公司开发的一个Oracle客户端工具。因此要使用SQL*Plus或者PL/SQL Developer操作数据库之前，我们一般要做的就是进行TNS配置，而要进行TNS配置就需要安装Oracle Net软件层。
　　综上所述，要操作Oracle数据库，或者说在Oracle数据库环境下进行数据库应用开发，我们最常见的环境组合：
　　开发机器上安装Oracle Client软件，让其具备Oracle Net软件层，进而配置TNS，标识出要连接的数据库信息；并安装PL/SQL Developer这样的Oracle客户端开发工具。而Oracle数据库服务器系统安装在公司的服务器或者“遥远的地方”，和开发人员没有关系，只要TNS配置好就行
　　开发机器上安装Oracle数据库，同时也具备了Oracle Net软件层的功能，配置TNS，标识出连接本机上的数据库；同时安装Oracle客户端开发工具
　　这样一来没有条件在自己机器上面安装一个Oracle数据库的同学就可以选择第一个方案，然后找一个有条件同学的数据库服务器或者公司的数据库服务器来进行学习，当然前提是要保证网络连接！

ubuntu 9.10下linuxqq经常挂掉的解决方案

ubuntu 9.10下linuxqq（官方的QQ，八百年不更新的那个了）

sudo vim /usr/bin/qq

增加

#!/bin/sh

export GDK_NATIVE_WINDOWS=true

cd /usr/share/tencent/qq/

./qq

经试验正确无误。。。linuxqq不再挂

Gearman for MySQL

　　Gearman是一个开源的分布式调度框架，支持多种语言。在分布式环境中，如何管理大量的服务器，将某些任务分发到大量的机器上调度执行，是一个比较大的挑战，Gearman为该类任务提供了一个不错的思路。在未来的MySQL集群环境中，Gearman这类工具应当大有用武之地，所以它也提供了MySQL UDF的支持。

　　一个Gearman请求的处理过程涉及三个角色：Client -> Job -> Worker。
　　Client：请求的发起者，可以是 C，PHP，Perl，MySQL UDF 等等。
　　Job：请求的调度者，用来负责协调把 Client 发出的请求转发给合适的 Worker。
　　Worker：请求的处理者，可以是 C，PHP，Perl 等等。
　　因为 Client，Worker 并不限制用一样的语言，所以有利于多语言多系统之间的集成。

SQL语句优化注意

1.尽量不要对列名进行函数处理.而是针对后面的值进行处理
例如where col1 = -5的效率比where -col1=5的效率要高
因为后面的条件对列值进行了计算.这样的条件下优化器无法使用索引
而是要针对所有值进行计算之后才能再比较

2.尽量使用和数剧列一样的值进行操作
如果col1是数值型
那么例如where col1 = 2和where col1= ‘2′
则前者效率更高
因为比较字符和数值型的时候
引擎需要把两者都转化成双精度然后进行比较
这样col1上的索引就失去作用了

3.减少函数的使用
例如where col1 >= ‘2009-10-26′ and col1 <= ‘2009-10-27′ 和where datediff(day,col1,getdate())=0 后者因为用到函数处理.所以col1上的索引又无法使用了 4.尽量不要用OR 一般对于OR的条件 优化器一般会使用全表扫描

Oracle数据库视图与权限问题

　　前几天客户遇上这样一个问题，某个用户A将视图的Select给予另一个用户B，但是用户B查询这个视图时，仍然报错：ORA-01031: 权限不足。这是怎么一回事呢?下面来模拟一下这个过程：
　　有三个用户test1,test2,test3， 三个用户都具有DBA色色权限。
　　用TEST1用户创建一个表T1，并将其查询权限授予TEST2：
　　SQL> create table t1 as select * from all_objects;
　　表已创建。
　　SQL> grant select on t1 to test2;
　　授权成功。
　　SQL> create table t1 as select * from all_objects;
　　表已创建。
　　SQL> grant select on t1 to test2;
　　授权成功。　　用TEST2用户创建一个视图，视图的基表是TEST1.T1，并将查询权限授予TEST3：
　　SQL> create view v_t1 as select * from test1.t1;
　　视图已建立。
　　SQL> grant select on v_t1 to test3;
　　授权成功。
　　SQL> create view v_t1 as select * from test1.t1;
　　视图已建立。
　　SQL> grant select on v_t1 to test3;
　　授权成功。　　TEST3用户查询视图TEST2.V_T1：
　　SQL> select * from test2.v_t1 where rownum<1; 　　select * from test2.v_t1 where rownum<1 　　* 　　ERROR 位于第 1 行: 　　ORA-01031: 权限不足 　　SQL> select * from test2.v_t1 where rownum<1; 　　select * from test2.v_t1 where rownum<1 　　* 　　ERROR 位于第 1 行: 　　ORA-01031: 权限不足　　可以看到报了权限不足的错误，就算这里TEST3用户有DBA权限。 　　这到底是怎么回事呢? 　　其实视图的权限，有两点需要引起注意： 　　1. 视图中，类似于定义者权限的存储过程，是屏蔽了角色权限的。比如如果TEST1没有显式地将T1表的Select权限给予TEST2，那么TEST2在创建视图V_T1时也会报ORA-01031错误，即使TEST2用户拥有DBA角色权限。 　　2.如果在用户A的视图中，引用了其他用户B的表，用户A将视图的访问权限给予用户C，那么就变相地将用户B的表的访问权限给予了用户C，因此，用户A必须有将用户B的表的访问权限转授用户C的权限，也就是用户B在授予A权限时，必须使用with grant option。 　　显然这里正是由于第2点的原因，导致用户TEST3不能访问视图。用户TEST1执行下面的操作，将解决这个问题： 　　SQL> grant select on t1 to test2 with grant option;
　　授权成功。
　　SQL> grant select on t1 to test2 with grant option;
　　授权成功。　　对于视图的Update，Delete权限，同样是如此。
　　在测试时，有一个现象，有点意思。就是如果用户TEST2没有显式地把V_T1的Select权限授予TEST3，而TEST3在有Select ANY TABLE或DBA权限时，则查询这个视图时不会报权限不足的错误。由于有Select ANY TABLE权限的存在，所有的用户表都可以被访问。但是显式授予表的权限时，似乎表的权限有更高的优先级，并且没有跟系统权限和角色权限进行结合。或者版本不同，表现得不一样，在我的测试中，是Oracle 9.2.0.8 for Windows。

MySQL数据库的双向加密方式

如果你正在运行使用MySQL的Web应用程序，那么你把密码或者其他敏感信息保存在应用程序里的机会就很大。保护这些数据免受黑客或者窥探者的获取 是一个令人关注的重要问题，因为您既不能让未经授权的人员使用或者破坏应用程序，同时还要保证您的竞争优势。幸运的是，MySQL带有很多设计用来提供这 种类型安全的加密函数。本文概述了其中的一些函数，并说明了如何使用它们，以及它们能够提供的不同级别的安全。
双向加密
就让我们从最简单的加密开始：双向加密。在这里，一段数据通过一个密钥被加密，只能够由知道这个密钥的人来解密。MySQL有两个函数来支持这种类型的加密，分别叫做ENCODE()和DECODE()。下面是一个简单的实例：
mysql> Insert INTO users (username, password)
VALUES ('joe', ENCODE('guessme', 'abracadabra'));
Query OK, 1 row affected (0.14 sec)
其中，Joe的密码是guessme，它通过密钥abracadabra被加密。要注意的是，加密完的结果是一个二进制字符串，如下所示：
mysql> Select * FROM users Where username='joe';
+———-+———-+
| username | password |
+———-+———-+
| joe | ¡?i??!? |
+———-+———-+
1 row in set (0.02 sec)
abracadabra这个密钥对于恢复到原始的字符串至关重要。这个密钥必须被传递给DECODE()函数，以获得原始的、未加密的密码。下面就是它的使用方法：
mysql> Select DECODE(password, 'abracadabra')
FROM users Where username='joe';
+———————————+
| DECODE(password, 'abracadabra') |
+———————————+
| guessme |
+———————————+
1 row in set (0.00 sec)
应该很容易就看到它在Web应用程序里是如何运行的——在验证用户登录的时候，DECODE()会用网站专用的密钥解开保存在数据库里的密码，并和用户输入的内容进行对比。假设您把PHP用作自己的脚本语言，那么可以像下面这样进行查询：
undefined undefined
$query = "Select COUNT(*) FROM users Where
username='$inputUser' AND DECODE(password,
'abracadabra') = '$inputPass'";?>
注意：虽然ENCODE()和DECODE()这两个函数能够满足大多数的要求，但是有的时候您希望使用强度更高的加密手段。在这种情况下，您可以使用AES_ENCRYPT()和AES_DECRYPT()函数，它们的工作方式是相同的，但是加密强度更高。