Php+MySql分页机制两种方案的比较测试

硬件环境：PIII550,128M,15.2G
软件环境：Win98+Apache+Php4+MySql
方案一：
    1.第一次查询时用Select count(1) from tab where condition 取得满足条件的记录数$rows
    2.通过前页数$page，每页记录数$rpp取回记录集
    select * from tab where condition limit ($page-1)*$rpp,$rpp
    3.显示返回记录集的所有记录。
    4.页面转移时将$rows传递给以后页面。
方案二：
    1.取回满足条件的记录集
    select * from tab where condition
    2.移动指针到($page-1)*$rpp
    3.显示$rpp条记录
==============+======+==============================================+======+======+========
    记录数    | 方案 | 次数     1     2     3     4     5     6     7     8     9     0 | 平均 | 平均 | 效率比
==============+======+==============================================+======+======+========
           |        |第一页    2 , 1 , 1 , 2 , 1 , 1 , 2 , 2 , 1 , 2 |    1.3 |        |
           |    一    +----------------------------------------------+------+    1.6 |
10000条记录时 |        |其它页    2 ，2 , 2 , 3 , 1 , 1 , 2 , 2 , 2 , 2 |    1.9 |        | 4.8125
sql2000的服务器版本是8.0,sql2005是9.0
首先要读安装必须配置(见后记)
1.我是先装2000的,安装好后打上sp4补丁,(sa密码不要太简单)
1.然后安装sql2005,安装的时候只要找到tools目录下的setup.exe 安装就可以了,安装完毕会有个SQL Server Management Studio,这个就是sql2000的企业管理器,
2,好多人都连接不上SQL Server Management Studio2005的数据库,开始的时候我也试了好多,
其实只要选择数据库引擎,然后服务器名称里面要填写"机器名SQLEXPRESS",如果你的机器名是haha,那么"hahaSQLEXPRESS",验证方式根据你的需求选择,点连接就能连上sql数据库引擎了,你要是自定义服务名了就用你的自定义服务名替换SQLEXPRESS
我在附加数据库的时候2005附加过后的数据库,不能被2000附加了
Q:ms sql 2005 的数据库可以导到(还原or恢复)ms sql 2000 里面么?
A:可以在sql 2005中生成数据库的脚本, 注意生成的时候, 要选择生成sql 2000这个版本的脚本然后在2000中用这个脚本建立目标库, 再用数据导入/导出把数据从2005导到2000即可.
Q:SQL Sever2005的用户名和口令应如何设置？
A:--把chinawn替换成你要建的用户
sp_addlogin 'chinawn','a','pubs'
go
EXEC sp_adduser 'chinawn', 'chinawn', 'db_owner'
后记:
安装 SQL Server 2005 的硬件和软件要求
http://msdn2.microsoft.com/zh-cn/library/ms166016.aspx
安装 SQL Server 的安全注意事项
升级到 SQL Server 2005

作者：陆阳
学习oracle,最好首先了解Oracle的框架。这样对Oracle有一个整体的认识，有高屋建瓴的作用
1、物理结构（由控制文件、数据文件、重做日志文件、参数文件、归档文件、口令文件组成）

一个数据库中的数据存储在磁盘上物理文件，被使用时，调入内存。
其中控制文件、数据文件、重做日志文件、跟踪文件及警告日志（trace files,alert files）属于数据库文件；
参数文件（parameter file）口令文件（password file）是非数据库文件

1.1数据文件：存储数据的文件.数据文件典型地代表了根据他们使用的磁盘空间和数量所决定的一个Oracle数据库的容积。
由于性能原因，每一种类型的数据放在相应的一个或一系列文件中，将这些文件放在不同的磁盘中。
types:
.data dictionary .data
.redo data .index
.temporary data 等等
1.2控制文件：包含维护和验证数据库完整性的必要信息、例如，控制文件用于识别数据文件和重做日志文件，一个数据库至少需要一个控制文件.
控制文件内容
。数据库名
。表空间信息
。所有数据文件的名字和位置
。所有redo日志文件的名字和位置
。当前的日志序列号
。检查点信息
。关于redo日志和归档的当前状态信息
控制文件的使用过程
控制文件把Oracle引导到数据库文件的其它部分。启动一个实例时，Oracle 从参数文件中读取控制文件的名字和位置。安装数据库时，Oracle 打开控制文件。最终打开数据库时，Oracle 从控制文件中读取数据文件的列表并打开其中的每个文件。
1.3重做日志文件：含对数据库所做的更改记录，这样万一出现故障可以启用数据恢复。一个数据库至少需要两个重做日志文件.
1.4 跟踪文件及警告日志(Trace Files and Alert Files)
在instance 中运行的每一个后台进程都有一个跟踪文件（trace file）与之相连。Trace file 记载后台进程所遇到的重大事件的信息。
警告日志（ Alert Log）是一种特殊的跟踪文件，每个数据库都有一个跟踪文件,同步记载数据库的消息和错误.
1.5参数文件：包括大量影响Oracle数据库实例功能的设定，如以下设定：
。数据库控制文件的定位
。Oracle用来缓存从磁盘上读取的数据的内存数量
。默认的优化程序的选择.

和数据库文件相关，执行两个重要的功能
Write once - run anywhere
一次编写——随处运行
这是Java的一句行销口号，但是它同时也是PHP的关键特性之一。许多商业模型依赖于操作系统无关性来保证产品能够销售给广泛的客户群体。因而，为什么要把你自己绑在某种数据库厂商的身上呢？数据库抽象层使得你能够与数据库独立的开发你的应用程序。但是，通常情况下它们对性能的影响超过了你所希望的，要么他们并不足够抽象以消除所有和特定数据库相关的代码。
这篇文章将教给我什么？
这篇文章将对数据库抽象包 PEAR MDB 有一个很好的介绍。文章的焦点将是对 MDB 超越类似包所提供的更先进的特性，例如数据类型抽象和基于 XML 的 schema 管理。对 PHP 和 SQL 的基本理解是推荐的。
为什么另外再要一个数据库类？
通常， web 工程在客户已经确定了要使用那种 RDBMS （关系型数据库管理系统）之后被添加给已经存在的 IT 基础结构。即使那并不是因为不同的预算可能影响的你选择何种数据用于部署的情况。最终，你作为开发者可能简单的偏好于不把自己绑在某个厂商身上。自此，意味着给每个支持的数据保持版本或者牺牲更多性能但是获得多于必须的易用性：走入 PEAR MDB 吧。
MDB 是着眼于使得编写 RDBMS 无关的 PHP 程序成为简单的过程的数据库抽象层。大部分其他的 PHP 的所谓数据库抽象层紧紧给所有支持的数据库提供了一个公用 API 以及非常有限的抽象（大部分只是针对序列的）。MDB 另一方面能够用来抽象所有数据库发送和接收的数据。甚至数据库 schema 都能被定义为 RDBMS 无关的格式。但是它提供这些功能的同时仍然保持了很高的性能以及简单易用。这是通过深入观察两个流行的数据库抽象层，PEAR DB 和 Metabase， 之后并且对它们进行了融合后获得的。而且在融合过程中，趁着这个机会清理了它们融合后的 API 以及任何影响性能的设计。
MDB 是怎样出现的？
早在 2001 年的秋天，我就在寻找一种可能能够让我公司的程序框架与 RDBMS 独立的数据库抽象包。这个目标是把特定数据库相关的代码数量减少到零。我发现提供这样的功能的唯一的一个包是 Metabase。但是 Metabase有一些部分是因为为了和 PHP3 兼容的让人不舒服的 API。尽管如此，我们决定 Metabase 是我们唯一的选择。但是即使是在给 Metabase 增加了一个性能改进的补丁之后，我们仍然感到我们放弃了太多的性能。我们在 2001 年的 PHP 国际会议上碰到了 Metabase 的作者，并且我们谈论了让像 Metabase 这样的东西成为 PEAR 工程一部分的好处。后来不久，在 PEAR 邮件列表上就 PEAR DB 和 Metabase 融合的可能的好处又开始了一场讨论。在我们公司进行了许多讨论之后，我们决定承担这个任务。数个月的艰辛工作之后，我们现在有了 MDB 的第一个稳定的 release。
1.为应用在多条记录的字段建立独立的表格
2.通过一个foreign key来关联这些表格的值
　　我们将url的值放在一个独立的表格中，这样我们就可以在以后加入更多的数据，而无需担心产生重复的值。我们还通
过主键值来关联这些字段：
　　users
　　userId name company company_address
　　1 Joe ABC 1 Work Lane
　　2 Jill XYZ 1 Job Street
　　urls
　　urlId relUserId url
　　1 1 abc.com
　　2 1 xyz.com
　　3 2 abc.com
　　4 2 xyz.com
　　如上所示，我们创建了独立的表格，users表中的主键userid现在与url表中的foreign key relUserId关联。现在的情
况好象已经得到了明显的改善。不过，如果我们要为ABC公司加入一个员工记录呢？或者更多，200个？这样我们就必须重
复使用公司名和地址，这明显不够冗余。因此我们将应用第三级正规化方法：
　　第三级正规化形式
　　1.消除不依赖于该键的字段
　　公司名及地址与User Id都是没有关系的，因此它们应用拥有自己的公司Id：
　　users
　　userId name relCompId
　　1 Joe 1
　　2 Jill 2
　　companies
　　compId company company_address
　　1 ABC 1 Work Lane
　　2 XYZ 1 Job Street
　　urls
　　urlId relUserId url
　　1 1 abc.com
　　2 1 xyz.com
　　3 2 abc.com
　　4 2 xyz.com
　　这样我们就将companies表中的主键comId和users表中名字为relCompId的foreign key关联起来，就算为ABC公司加入
200个员工，在companies中也只有一条记录。我们的users和urls表可以不断地扩大，而无需担心插入不必要的数据。大部
分的开发者都认为经过三步的正规化就足够了，这个数据库的设计已经可以很方便地处理整个企业的负担，此看法在大多
数的情况下是正确的。
　　我们可以留意一下URL的字段--你注意到数据的冗余了吗？如果给用户用户输入这些url数据的HTML页面是一个文本
框，可任意输入的话，这并没有问题，两个用户输入同样收藏夹的概率较少，不过，如果是通过一个下拉式的菜单，只让
用户选择两个url输入，或者更多一点。这种情况下，我们的数据库还可以进行下一级别的优化--第四步，对于大多数的开
发者来说，这一步都是忽略的，因为它要依赖一个很特别的关系--一个多对多的关系，这在我们的应用中是还没有遇到过的.