说起数据抽象层，大家可能首先想起的就是ADODB。这里要为大家介绍的是一个全新的数据抽象层：Creole。说它新，是因为它是用PHP5写的，是一个基于真正意义的OO的层；它的API接口以JDBC为基础，熟悉JDBC的朋友用起来应该会很亲切；它现在支持的数据库有MySQL， MS SQL Server， PostgreSQL， SQLite。Oracle的driver正在开发中，当然，你也可以为自己要使用的数据库写Driver。


安装
下面我们就来看看在Windows+Apache+PHP5上Creole的安装和初步使用。首先你要安装好PEAR，如果你还没有安装好，可以双击php目录下的go-pear.bat文件，然后这个程序会引导你进行安装。关于PEAR的安装不是本文的内容，请自行查阅相关资料。当你安装好PEAR后，我们就要利用它的install功能了。
首先进入命令行方式，Cd到你安装php的目录下。然后在命令行中键入下边命令，这样PEAR会自动帮我们下载并安装好Creole包。

pear install http://creole.phpdb.org/pear/creole-current.tgz 

如果你键入的命令正确的话，应该看到下边的安装提示。




这样我们就已经成功安装好了Creole，不过为了能使用它我们还得再安装一个jargon包，这个包封装了数据表和字段层次的一些信息。安装的方法和上边一样，键入如下命令就可以了：

pear install http://creole.phpdb.org/pear/jargon-current.tgz

配置
下面我们就可以使用Creole了。在web可以访问的目录下建立一个PHP文件，我们先来尝试包含Creole类，这是每一个要使用Creole的程序都要做的事。我们加入下边的代码：

require_once 'creole/Creole.php';

然后在浏览器中访问这个页面，结果出现了下边的错误：

Warning: main(/creole/Creole.php) [function.main]: failed to open stream: No such file or directory in c:\program files\EasyPHP5\home\dev\test.php on line 2

Fatal error: main() [function.require]: Failed opening required '/creole/Creole.php' (include_path='.;C:\php5\pear') in c:\program files\EasyPHP5\home\dev\test.php on line 2

这是因为我们没有设置好php.ini来包含PEAR库的路径，所以php.exe找不到文件，只好报错了。现在我们把PEAR库的地址添加到php.ini中。在php.ini中找到这段：

;;;;;;;;;;;;;;;;;;;;;;;;;
; Paths and Directories ;
;;;;;;;;;;;;;;;;;;;;;;;;;
 
; UNIX: "/path1:/path2"
;include_path = ".:/php/includes"
;
; Windows: "path1;path2"
;include_path = ".;c:\php\includes"

将最后一行改成：

include_path = ".;C:\Program Files\EasyPHP5\php\PEAR"

其中C:\Program Files\EasyPHP5\php\PEAR是PEAR在你机器上的绝对路径。注意要去掉行首的分号。然后重启Apache。再访问看看，好了。：）



试用
现在开始我们就可以在程序中使用Creole了。下边我们将连接数据库，并从中取出user表的全部用户。下边是完整的代码：

<?php
require_once 'creole/Creole.php'; 
$dsn = "mysql://root@localhost/r4"; 
$conn = Creole::getConnection($dsn); 
$rs = $conn->executeQuery("SELECT * FROM user");
while($rs->next())
{
  echo $rs->getString("login_name") . " (" . $rs->getInt("id") . ")";
}
?>

这里讲解下上边代码的含义。第一行载入了Creole类，第二行定义了一个用于连接数据库的字符串，格式是“数据库类型名://用户名:密码@HOST/数据库名”。第三行创建了一个连接对象，第四行利用这个对象执行了一句SQL，并返回一个结果集。第五到八行遍历了这个结果集并输出数据。


析构
怎么样，看起来不错吧，如果你感兴趣可以按照Creole站上的Guide一步一步做下去。不过我们就要做别的事情了:P 前边说过了，Creole更多的注重于OO，同时又带有很强的Java风格，因此对于我们学习使用PHP5来设计OO方式的程序是很好的范例。下边我们就来看看它的架构。首先要了解的是它的目录结构，在Windows命令行方式键入tree，就可以打印出一个目录的结构（一个有用的小技巧哦），下边是由此得到的Creole目录结构，目录后边加上了简要的说明。
我们以Statement为例，看看Creole是怎么组织的。首先在根目录下的Statement.php中定义了Statement接口，这个接口规定了Statement必须实现的一些方法。然后，在/common目录下的StatementCommon.php中定义了名为StatementCommon的抽象类，在这个类中，包含了Statement.php中定义的接口的实现代码，但是并没有定义为实现Statement接口。

Root // Creole的根目录 
├─common // 存放了Creole的抽象类
├─drivers
│  ├─mssql 
│  │  └─metadata // mssql实现
│  ├─mysql 
│  │  └─metadata // mysql实现
│  ├─pgsql
│  │  └─metadata
│  └─sqlite
│      └─metadata
├─metadata // 数据表原始信息类
└─util 
    └─sql

而在/drivers/mysql/目录下的MysqlStatement则继承了StatementCommon和实现Statement方法。这样MysqlStatement可以共享到StatementCommon中的方法，需要定制时可以重载StatementCommon的方法；同时，MysqlStatement又受到Statement接口的约束。

下一页的图表示了Statement，StatementCommon和MysqlStatement之间的关系。正是这样的结构，使定义和实现得到了有效的分离。Creole中大量采用了这样的结构，在我们编写自己的Driver时非常方便。如果要添加一个TextStatement，可以自己实现一个class，只要这个class实现了Statement接口就可以了。而Driver正是由这样的一组class组成的。





参考
我们对Creole的介绍到这里就告一个段落了，而对你来说，一切才刚刚开始。下边是从两个常用类的接口程序内中整理出来的方法，希望能对你有所帮助。

Statement

public function setLimit($v);
public function getLimit();
public function setOffset($v);
public function getOffset();
public function close();
public function execute($sql, $fetchmode = null);
public function getResultSet();
public function executeQuery($sql, $fetchmode = null);
public function executeUpdate($sql);
public function getMoreResults();
public function getConnection();

ResultSet

public function getResource();
public function setFetchmode($mode);
public function getFetchmode();       
public function isIgnoreAssocCase();
public function next();
public function previous();
public function relative($offset);
public function absolute($pos);
public function seek($rownum);    
public function first();
public function last();
public function beforeFirst();
public function afterLast();
public function isAfterLast();
public function isBeforeFirst();
public function getCursorPos();
public function getRow();
public function getRecordCount();
public function close();
public function get($column);
public function getArray($column);
public function getBoolean($column);
public function getBlob($column);
public function getClob($column);
public function getDate($column, $format = '%x');   
public function getFloat($column);
public function getInt($column);      
public function getString($column);
public function getTime($column, $format = '%X');
public function getTimestamp($column, $format = 'Y-m-d H:i:s');

一
个成功的管理系统，是由：[50% 的业务 + 50% 的软件] 所组成，而 50% 的成功软件又有 [25% 的数据库 + 25% 的程序]
所组成，数据库设计的好坏是一个关键。如果把企业的数据比做生命所必需的血液，那么数据库的设计就是应用中最重要的一部分。有关数据库设计的材料汗牛充
栋，大学学位课程里也有专门的讲述。不过，就如我们反复强调的那样，再好的老师也比不过经验的教诲。所以我归纳历年来所走的弯路及体会，并在网上找了些对
数据库设计颇有造诣的专业人士给大家传授一些设计数据库的技巧和经验。精选了其中的 60
个最佳技巧，并把这些技巧编写成了本文，为了方便索引其内容划分为 5 个部分：

第 1 部分 - 设计数据库之前
这一部分罗列了 12 个基本技巧，包括命名规范和明确业务需求等。
第 2 部分 - 设计数据库表
总共 24 个指南性技巧，涵盖表内字段设计以及应该避免的常见问题等。
第 3 部分 - 选择键
怎么选择键呢？这里有 10 个技巧专门涉及系统生成的主键的正确用法，还有何 时以及如何索引字段以获得最佳性能等。
第 4 部分 - 保证数据完整性
讨论如何保持数据库的清晰和健壮，如何把有害数据降低到最小程度。
第 5 部分 - 各种小技巧
不包括在以上 4 个部分中的其他技巧，五花八门，有了它们希望你的数据库开发工作会更轻松一些。
第 1 部分 - 设计数据库之前
考察现有环境
在
设计一个新数据库时，你不但应该仔细研究业务需求而且还要考察现有的系统。大多数数据库项目都不是从头开始建立的；通常，机构内总会存在用来满足特定需求
的现有系统（可能没有实现自动计算）。显然，现有系统并不完美，否则你就不必再建立新系统了。但是对旧系统的研究可以让你发现一些可能会忽略的细微问题。
一般来说，考察现有系统对你绝对有好处。
定义标准的对象命名规范
一定要定义数据库对象的命名规范。对数据库表来说，从项目一开始就要
确定表名是采用复数还是单数形式。此外还要给表的别名定义简单规则（比方说，如果表名是一个单词，别名就取单词的前 4
个字母；如果表名是两个单词，就各取两个单词的前两个字母组成 4 个字母长的别名；如果表的名字由 3
个单词组成，你不妨从头两个单词中各取一个然后从最后一个单词中再取出两个字母，结果还是组成 4
字母长的别名，其余依次类推）对工作用表来说，表名可以加上前缀 WORK_
后面附上采用该表的应用程序的名字。表内的列[字段]要针对键采用一整套设计规则。比如，如果键是数字类型，你可以用 _N
作为后缀；如果是字符类型则可以采用 _C
后缀。对列[字段]名应该采用标准的前缀和后缀。再如，假如你的表里有好多“money”字段，你不妨给每个列[字段]增加一个 _M
后缀。还有，日期列[字段]最好以 D_ 作为名字打头。

检查表名、报表名和查询名之间的命名规范。你可能会很快就被这些不同的数据库要素的名称搞糊涂了。假如你坚持统一地命名这些数据库的不同组成部分，至少你应该在这些对象名字的开头用 Table、Query 或者 Report 等前缀加以区别。

如
果采用了 Microsoft Access，你可以用 qry、rpt、tbl 和 mod 等符号来标识对象（比如
tbl_Employees）。我在和 SQL Server 打交道的时候还用过 tbl 来索引表，但我用 sp_company （现在用
sp_feft_）标识存储过程，因为在有的时候如果我发现了更好的处理办法往往会保存好几个拷贝。我在实现 SQL Server 2000 时用
udf_ （或者类似的标记）标识我编写的函数。
工欲善其事, 必先利其器
采用理想的数据库设计工具，比如：SyBase 公司的
PowerDesign，她支持 PB、VB、Delphe 等语言，通过 ODBC 可以连接市面上流行的 30 多个数据库，包括
dBase、FoxPro、VFP、SQL Server 等，今后有机会我将着重介绍 PowerDesign 的使用。
获取数据模式资源手册
正
在寻求示例模式的人可以阅读《数据模式资源手册》一书，该书由 Len Silverston、W. H. Inmon 和 Kent
Graziano
编写，是一本值得拥有的最佳数据建模图书。该书包括的章节涵盖多种数据领域，比如人员、机构和工作效能等。其他的你还可以参考：[1]萨师煊　王珊著　数
据库系统概论(第二版)高等教育出版社 1991、[2][美] Steven M.Bobrowski 著 Oracle 7
与客户／服务器计算技术从入门到精通　刘建元等译　电子工业出版社，1996、[3]周中元　信息系统建模方法(下)　电子与信息化　1999年第3期，
1999
畅想未来，但不可忘了过去的教训
我发现询问用户如何看待未来需求变化非常有用。这样做可以达到两个目的：首先，你可以清楚地了解应用设计在哪个地方应该更具灵活性以及如何避免性能瓶颈；其次，你知道发生事先没有确定的需求变更时用户将和你一样感到吃惊。

一定要记住过去的经验教训！我们开发人员还应该通过分享自己的体会和经验互相帮助。即使用户认为他们再也不需要什么支持了，我们也应该对他们进行这方面的教育，我们都曾经面临过这样的时刻“当初要是这么做了该多好..”。
在物理实践之前进行逻辑设计
在深入物理设计之前要先进行逻辑设计。随着大量的 CASE 工具不断涌现出来，你的设计也可以达到相当高的逻辑水准，你通常可以从整体上更好地了解数据库设计所需要的方方面面。
了解你的业务
在你百分百地确定系统从客户角度满足其需求之前不要在你的 ER（实体关系）模式中加入哪怕一个数据表（怎么，你还没有模式？那请你参看技巧 9）。了解你的企业业务可以在以后的开发阶段节约大量的时间。一旦你明确了业务需求，你就可以自己做出许多决策了。

一旦你认为你已经明确了业务内容，你最好同客户进行一次系统的交流。采用客户的术语并且向他们解释你所想到的和你所听到的。同时还应该用可能、将会和必须等词汇表达出系统的关系基数。这样你就可以让你的客户纠正你自己的理解然后做好下一步的 ER 设计。
创建数据字典和 ER 图表
一
定要花点时间创建 ER 图表和数据字典。其中至少应该包含每个字段的数据类型和在每个表内的主外键。创建 ER
图表和数据字典确实有点费时但对其他开发人员要了解整个设计却是完全必要的。越早创建越能有助于避免今后面临的可能混乱，从而可以让任何了解数据库的人都
明确如何从数据库中获得数据。

有一份诸如 ER 图表等最新文档其重要性如何强调都不过分，这对表明表之间关系很有用，而数据字典则说明了每个字段的用途以及任何可能存在的别名。对 SQL 表达式的文档化来说这是完全必要的。
创建模式
一张图表胜过千言万语：开发人员不仅要阅读和实现它，而且还要用它来帮助自己和用户对话。模式有助于提高协作效能，这样在先期的数据库设计中几乎不可能出现大的问题。模式不必弄的很复杂；甚至可以简单到手写在一张纸上就可以了。只是要保证其上的逻辑关系今后能产生效益。
从输入输出下手
在
定义数据库表和字段需求（输入）时，首先应检查现有的或者已经设计出的报表、查询和视图（输出）以决定为了支持这些输出哪些是必要的表和字段。举个简单的
例子：假如客户需要一个报表按照邮政编码排序、分段和求和，你要保证其中包括了单独的邮政编码字段而不要把邮政编码糅进地址字段里。
报表技巧
要
了解用户通常是如何报告数据的：批处理还是在线提交报表？时间间隔是每天、每周、每月、每个季度还是每年？如果需要的话还可以考虑创建总结表。系统生成的
主键在报表中很难管理。用户在具有系统生成主键的表内用副键进行检索往往会返回许多重复数据。这样的检索性能比较低而且容易引起混乱。
理解客户需求
看
起来这应该是显而易见的事，但需求就是来自客户（这里要从内部和外部客户的角度考虑）。不要依赖用户写下来的需求，真正的需求在客户的脑袋里。你要让客户
解释其需求，而且随着开发的继续，还要经常询问客户保证其需求仍然在开发的目的之中。一个不变的真理是：“只有我看见了我才知道我想要的是什么”必然会导
致大量的返工，因为数据库没有达到客户从来没有写下来的需求标准。而更糟的是你对他们需求的解释只属于你自己，而且可能是完全错误的。
第 2 部分 - 设计表和字段
检查各种变化
我
在设计数据库的时候会考虑到哪些数据字段将来可能会发生变更。比方说，姓氏就是如此（注意是西方人的姓氏，比如女性结婚后从夫姓等）。所以，在建立系统存
储客户信息时，我倾向于在单独的一个数据表里存储姓氏字段，而且还附加起始日和终止日等字段，这样就可以跟踪这一数据条目的变化。
采用有意义的字段名
有一回我参加开发过一个项目，其中有从其他程序员那里继承的程序，那个程序员喜欢用屏幕上显示数据指示用语命名字段，这也不赖，但不幸的是，她还喜欢用一些奇怪的命名法，其命名采用了匈牙利命名和控制序号的组合形式，比如 cbo1、txt2、txt2_b 等等。
除非你在使用只面向你的缩写字段名的系统，否则请尽可能地把字段描述的清楚些。当然，也别做过头了，比如 Customer_Shipping_Address_Street_Line_1，虽然很富有说明性，但没人愿意键入这么长的名字，具体尺度就在你的把握中。
采用前缀命名
如果多个表里有好多同一类型的字段（比如 FirstName），你不妨用特定表的前缀（比如 CusLastName）来帮助你标识字段。

时效性数据应包括“最近更新日期/时间”字段。时间标记对查找数据问题的原因、按日期重新处理/重载数据和清除旧数据特别有用。
标准化和数据驱动
数
据的标准化不仅方便了自己而且也方便了其他人。比方说，假如你的用户界面要访问外部数据源（文件、XML
文档、其他数据库等），你不妨把相应的连接和路径信息存储在用户界面支持表里。还有，如果用户界面执行工作流之类的任务（发送邮件、打印信笺、修改记录状
态等），那么产生工作流的数据也可以存放在数据库里。预先安排总需要付出努力，但如果这些过程采用数据驱动而非硬编码的方式，那么策略变更和维护都会方便
得多。事实上，如果过程是数据驱动的，你就可以把相当大的责任推给用户，由用户来维护自己的工作流过程。
标准化不能过头
对那些不熟悉
标准化一词（normalization）的人而言，标准化可以保证表内的字段都是最基础的要素，而这一措施有助于消除数据库中的数据冗余。标准化有好几
种形式，但 Third Normal Form（3NF）通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说，3NF 规定：
* 表内的每一个值都只能被表达一次。
* 表内的每一行都应该被唯一的标识（有唯一键）。
* 表内不应该存储依赖于其他键的非键信息。
遵
守 3NF 标准的数据库具有以下特点：有一组表专门存放通过键连接起来的关联数据。比方说，某个存放客户及其有关定单的 3NF
数据库就可能有两个表：Customer 和 Order。Order 表不包含定单关联客户的任何信息，但表内会存放一个键值，该键指向
Customer 表里包含该客户信息的那一行。
更高层次的标准化也有，但更标准是否就一定更好呢？答案是不一定。事实上，对某些项目来说，甚至就连 3NF 都可能给数据库引入太高的复杂性。

为
了效率的缘故，对表不进行标准化有时也是必要的，这样的例子很多。曾经有个开发餐饮分析软件的活就是用非标准化表把查询时间从平均 40
秒降低到了两秒左右。虽然我不得不这么做，但我绝不把数据表的非标准化当作当然的设计理念。而具体的操作不过是一种派生。所以如果表出了问题重新产生非标
准化的表是完全可能的。
Microsoft Visual FoxPro 报表技巧
如果你正在使用 Microsoft
Visual FoxPro，你可以用对用户友好的字段名来代替编号的名称：比如用 Customer Name 代替
txtCNaM。这样，当你用向导程序 [Wizards，台湾人称为‘精灵’] 创建表单和报表时，其名字会让那些不是程序员的人更容易阅读。
不活跃或者不采用的指示符
增
加一个字段表示所在记录是否在业务中不再活跃挺有用的。不管是客户、员工还是其他什么人，这样做都能有助于再运行查询的时候过滤活跃或者不活跃状态。同时
还消除了新用户在采用数据时所面临的一些问题，比如，某些记录可能不再为他们所用，再删除的时候可以起到一定的防范作用。
使用角色实体定义属于某类别的列[字段]
在需要对属于特定类别或者具有特定角色的事物做定义时，可以用角色实体来创建特定的时间关联关系，从而可以实现自我文档化。
这
里的含义不是让 PERSON 实体带有 Title 字段，而是说，为什么不用 PERSON 实体和 PERSON_TYPE
实体来描述人员呢？比方说，当 John Smith, Engineer 提升为 John Smith, Director 乃至最后爬到
John Smith, CIO 的高位，而所有你要做的不过是改变两个表 PERSON 和 PERSON_TYPE
之间关系的键值，同时增加一个日期/时间字段来知道变化是何时发生的。这样，你的 PERSON_TYPE 表就包含了所有 PERSON
的可能类型，比如 Associate、Engineer、Director、CIO 或者 CEO 等。
还有个替代办法就是改变 PERSON 记录来反映新头衔的变化，不过这样一来在时间上无法跟踪个人所处位置的具体时间。
采用常用实体命名机构数据
组
织数据的最简单办法就是采用常用名字，比如：PERSON、ORGANIZATION、ADDRESS 和 PHONE
等等。当你把这些常用的一般名字组合起来或者创建特定的相应副实体时，你就得到了自己用的特殊版本。开始的时候采用一般术语的主要原因在于所有的具体用户
都能对抽象事物具体化。
有了这些抽象表示，你就可以在第 2 级标识中采用自己的特殊名称，比如，PERSON 可能是
Employee、Spouse、Patient、Client、Customer、Vendor 或者 Teacher
等。同样的，ORGANIZATION 也可能是
MyCompany、MyDepartment、Competitor、Hospital、Warehouse、Government 等。最后
ADDRESS 可以具体为 Site、Location、Home、Work、Client、Vendor、Corporate 和
FieldOffice 等。
采用一般抽象术语来标识“事物”的类别可以让你在关联数据以满足业务要求方面获得巨大的灵活性，同时这样做还可以显著降低数据存储所需的冗余量。
用户来自世界各地
在设计用到网络或者具有其他国际特性的数据库时，一定要记住大多数国家都有不同的字段格式，比如邮政编码等，有些国家，比如新西兰就没有邮政编码一说。
数据重复需要采用分立的数据表
如果你发现自己在重复输入数据，请创建新表和新的关系。
每个表中都应该添加的 3 个有用的字段
* dRecordCreationDate，在 VB 下默认是 Now()，而在 SQL Server 下默认为 GETDATE()
* sRecordCreator，在 SQL Server 下默认为 NOT NULL DEFAULT USER
* nRecordVersion，记录的版本标记；有助于准确说明记录中出现 null 数据或者丢失数据的原因
对地址和电话采用多个字段
描述街道地址就短短一行记录是不够的。Address_Line1、Address_Line2 和 Address_Line3 可以提供更大的灵活性。还有，电话号码和邮件地址最好拥有自己的数据表，其间具有自身的类型和标记类别。

过分标准化可要小心，这样做可能会导致性能上出现问题。虽然地址和电话表分离通常可以达到最佳状态，但是如果需要经常访问这类信息，或许在其父表中存放“首选”信息（比如 Customer 等）更为妥当些。非标准化和加速访问之间的妥协是有一定意义的。
使用多个名称字段
我觉得很吃惊，许多人在数据库里就给 name 留一个字段。我觉得只有刚入门的开发人员才会这么做，但实际上网上这种做法非常普遍。我建议应该把姓氏和名字当作两个字段来处理，然后在查询的时候再把他们组合起来。

我最常用的是在同一表中创建一个计算列[字段]，通过它可以自动地连接标准化后的字段，这样数据变动的时候它也跟着变。不过，这样做在采用建模软件时得很机灵才行。总之，采用连接字段的方式可以有效的隔离用户应用和开发人员界面。
提防大小写混用的对象名和特殊字符
过
去最令我恼火的事情之一就是数据库里有大小写混用的对象名，比如 CustomerData。这一问题从 Access 到 Oracle
数据库都存在。我不喜欢采用这种大小写混用的对象命名方法，结果还不得不手工修改名字。想想看，这种数据库/应用程序能混到采用更强大数据库的那一天吗？
采用全部大写而且包含下划符的名字具有更好的可读性（CUSTOMER_DATA），绝对不要在对象名的字符之间留空格。
小心保留词
要
保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突，比如，最近我编写的一个 ODBC 连接程序里有个表，其中就用了 DESC
作为说明字段名。后果可想而知！DESC 是 DESCENDING 缩写后的保留词。表里的一个 SELECT *
语句倒是能用，但我得到的却是一大堆毫无用处的信息。
保持字段名和类型的一致性
在命名字段并为其指定数据类型的时候一定要保证一致
性。假如字段在某个表中叫做“agreement_number”，你就别在另一个表里把名字改成“ref1”。假如数据类型在一个表里是整数，那在另一
个表里可就别变成字符型了。记住，你干完自己的活了，其他人还要用你的数据库呢。
仔细选择数字类型
在 SQL 中使用 smallint 和 tinyint 类型要特别小心，比如，假如你想看看月销售总额，你的总额字段类型是 smallint，那么，如果总额超过了 $32,767 你就不能进行计算操作了。
删除标记
在表中包含一个“删除标记”字段，这样就可以把行标记为删除。在关系数据库里不要单独删除某一行；最好采用清除数据程序而且要仔细维护索引整体性。
避免使用触发器
触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器，你最好集中对它文档化。
包含版本机制
建
议你在数据库中引入版本控制机制来确定使用中的数据库的版本。无论如何你都要实现这一要求。时间一长，用户的需求总是会改变的。最终可能会要求修改数据库
结构。虽然你可以通过检查新字段或者索引来确定数据库结构的版本，但我发现把版本信息直接存放到数据库中不更为方便吗？。
给文本字段留足余量
ID
类型的文本字段，比如客户 ID
或定单号等等都应该设置得比一般想象更大，因为时间不长你多半就会因为要添加额外的字符而难堪不已。比方说，假设你的客户 ID 为 10
位数长。那你应该把数据库表字段的长度设为 12 或者 13 个字符长。这算浪费空间吗？是有一点，但也没你想象的那么多：一个字段加长 3
个字符在有 1 百万条记录，再加上一点索引的情况下才不过让整个数据库多占据 3MB
的空间。但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。身份证的号码从 15 位变成 18 位就是最好和最惨痛的例子。

列[字段]命名技巧
我们发现，假如你给每个表的列[字段]名都采用统一的前缀，那么在编写 SQL
表达式的时候会得到大大的简化。这样做也确实有缺点，比如破坏了自动表连接工具的作用，后者把公共列[字段]名同某些数据库联系起来，不过就连这些工具有
时不也连接错误嘛。举个简单的例子，假设有两个表：
Customer 和 Order。Customer 表的前缀是 cu_，所以该表内的子段名如下：cu_name_id、cu_surname、cu_initials 和cu_address 等。Order 表的前缀是 or_，所以子段名是：
or_order_id、or_cust_name_id、or_quantity 和 or_description 等。
这样从数据库中选出全部数据的 SQL 语句可以写成如下所示：
Select * From Customer, Order Where cu_surname = "MYNAME" ;
and cu_name_id = or_cust_name_id and or_quantity = 1
在没有这些前缀的情况下则写成这个样子（用别名来区分）：
Select * From Customer, Order Where Customer.surname = "MYNAME" ;
and Customer.name_id = Order.cust_name_id and Order.quantity = 1
第 1 个 SQL 语句没少键入多少字符。但如果查询涉及到 5 个表乃至更多的列[字段]你就知道这个技巧多有用了。

一、数据库设计过程

数据库技术是信息资源管理最有效的手段。数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。
数
据库设计中需求分析阶段综合各个用户的应用需求（现实世界的需求），在概念设计阶段形成独立于机器特点、独立于各个DBMS产品的概念模式（信息世界模
型），用E-R图来描述。在逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型如关系模型，形成数据库逻辑模式。然后根据用户处理的要求，安全
性的考虑，在基本表的基础上再建立必要的视图（VIEW）形成数据的外模式。在物理设计阶段根据DBMS特点和处理的需要，进行物理存储安排，设计索引，
形成数据库内模式。
1. 需求分析阶段
需求收集和分析，结果得到数据字典描述的数据需求（和数据流图描述的处理需求）。
需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。
需求分析的方法：调查组织机构情况、调查各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。
常用的调查方法有： 跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。
分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法（Structured Analysis，简称SA方法）从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并把每一层用数据流图和数据字典描述。
数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典（Data Dictionary，简称DD）来描述。
数据字典是各类数据描述的集合，它是关于数据库中数据的描述，即元数据，而不是数据本身。数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分(至少应该包含每个字段的数据类型和在每个表内的主外键)。
数据项描述＝｛数据项名，数据项含义说明，别名，数据类型，长度，
　　　　　　　　　取值范围，取值含义，与其他数据项的逻辑关系｝
数据结构描述＝｛数据结构名，含义说明，组成:｛数据项或数据结构｝｝
数据流描述＝｛数据流名，说明，数据流来源，数据流去向，
　　　　　　　　　组成:｛数据结构｝，平均流量，高峰期流量｝
数据存储描述＝｛数据存储名，说明，编号，流入的数据流，流出的数据流， 　　
　　　　　　　　组成:｛数据结构｝，数据量，存取方式｝
处理过程描述＝｛处理过程名，说明，输入:｛数据流｝，输出:｛数据流｝,
　　　　　　　　　　处理:｛简要说明｝｝
2. 概念结构设计阶段
通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型，可以用E-R图表示。
概念模型用于信息世界的建模。概念模型不依赖于某一个DBMS支持的数据模型。概念模型可以转换为计算机上某一DBMS支持的特定数据模型。
概念模型特点：
(1) 具有较强的语义表达能力，能够方便、直接地表达应用中的各种语义知识。
(2) 应该简单、清晰、易于用户理解，是用户与数据库设计人员之间进行交流的语言。
概念模型设计的一种常用方法为IDEF1X方法，它就是把实体-联系方法应用到语义数据模型中的一种语义模型化技术，用于建立系统信息模型。
  使用IDEF1X方法创建E-R模型的步骤如下所示:
2.1 第零步——初始化工程
这个阶段的任务是从目的描述和范围描述开始，确定建模目标，开发建模计划，组织建模队伍，收集源材料，制定约束和规范。收集源材料是这阶段的重点。通过调查和观察结果，业务流程，原有系统的输入输出，各种报表，收集原始数据，形成了基本数据资料表。
2.2 第一步——定义实体
实
体集成员都有一个共同的特征和属性集，可以从收集的源材料——基本数据资料表中直接或间接标识出大部分实体。根据源材料名字表中表示物的术语以及具有“代
码”结尾的术语，如客户代码、代理商代码、产品代码等将其名词部分代表的实体标识出来，从而初步找出潜在的实体，形成初步实体表。
2.3 第二步——定义联系
IDEF1X
模型中只允许二元联系，n元联系必须定义为n个二元联系。根据实际的业务需求和规则，使用实体联系矩阵来标识实体间的二元关系，然后根据实际情况确定出连
接关系的势、关系名和说明，确定关系类型，是标识关系、非标识关系（强制的或可选的）还是非确定关系、分类关系。如果子实体的每个实例都需要通过和父实体
的关系来标识，则为标识关系，否则为非标识关系。非标识关系中，如果每个子实体的实例都与而且只与一个父实体关联，则为强制的，否则为非强制的。如果父实
体与子实体代表的是同一现实对象，那么它们为分类关系。
2.4 第三步——定义码
通过引入交叉实体除去上一阶段产生的非确定关系，然后从
非交叉实体和独立实体开始标识侯选码属性，以便唯一识别每个实体的实例，再从侯选码中确定主码。为了确定主码和关系的有效性，通过非空规则和非多值规则来
保证，即一个实体实例的一个属性不能是空值，也不能在同一个时刻有一个以上的值。找出误认的确定关系，将实体进一步分解，最后构造出IDEF1X模型的键
基视图（KB图）。
2.5 第四步——定义属性
从源数据表中抽取说明性的名词开发出属性表，确定属性的所有者。定义非主码属性，检查属性
的非空及非多值规则。此外，还要检查完全依赖函数规则和非传递依赖规则，保证一个非主码属性必须依赖于主码、整个主码、仅仅是主码。以此得到了至少符合关
系理论第三范式的改进的IDEF1X模型的全属性视图。
2.6 第五步——定义其他对象和规则
  定义属性的数据类型、长度、精度、非空、缺省值、约束规则等。定义触发器、存储过程、视图、角色、同义词、序列等对象信息。
3. 逻辑结构设计阶段
  将概念结构转换为某个DBMS所支持的数据模型（例如关系模型），并对其进行优化。设计逻辑结构应该选择最适于描述与表达相应概念结构的数据模型，然后选择最合适的DBMS。
将E-R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转化为关系模式,这种转换一般遵循如下原则：
1）一个实体型转换为一个关系模式。实体的属性就是关系的属性。实体的码就是关系的码。
2）一个m:n联系转换为一个关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性。而关系的码为各实体码的组合。
3）一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。
4）一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。
5）三个或三个以上实体间的一个多元联系转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性。而关系的码为各实体码的组合。  
6）同一实体集的实体间的联系，即自联系，也可按上述1:1、1:n和m:n三种情况分别处理。
7）具有相同码的关系模式可合并。
为了进一步提高数据库应用系统的性能，通常以规范化理论为指导，还应该适当地修改、调整数据模型的结构，这就是数据模型的优化。确定数据依赖。消除冗余的联系。确定各关系模式分别属于第几范式。确定是否要对它们进行合并或分解。一般来说将关系分解为3NF的标准，即：
表内的每一个值都只能被表达一次。
•?表内的每一行都应该被唯一的标识（有唯一键）。
表内不应该存储依赖于其他键的非键信息。  
4. 数据库物理设计阶段
为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）。根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。
5. 数据库实施阶段
运
用DBMS提供的数据语言（例如SQL）及其宿主语言（例如C），根据逻辑设计和物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试
运行。 数据库实施主要包括以下工作：用DDL定义数据库结构、组织数据入库 、编制与调试应用程序、数据库试运行  
6. 数据库运行和维护阶段
数据库应用系统经过试运行后即可投入正式运行。在数据库系统运行过程中必须不断地对其进行评价、调整与修改。包括：数据库的转储和恢复、数据库的安全性、完整性控制、数据库性能的监督、分析和改进、数据库的重组织和重构造。

建模工具的使用
为加快数据库设计速度，目前有很多数据库辅助工具（CASE工具），如Rational公司的Rational Rose，CA公司的Erwin和Bpwin，Sybase公司的PowerDesigner以及Oracle公司的Oracle Designer等。
ERwin
主要用来建立数据库的概念模型和物理模型。它能用图形化的方式，描述出实体、联系及实体的属性。ERwin支持IDEF1X方法。通过使用ERwin建模
工具自动生成、更改和分析IDEF1X模型，不仅能得到优秀的业务功能和数据需求模型，而且可以实现从IDEF1X模型到数据库物理设计的转变。
ERwin工具绘制的模型对应于逻辑模型和物理模型两种。在逻辑模型中，IDEF1X工具箱可以方便地用图形化的方式构建和绘制实体联系及实体的属性。在
物理模型中，ERwin可以定义对应的表、列，并可针对各种数据库管理系统自动转换为适当的类型。
设计人员可根据需要选用相应的数据库设计建模工具。例如需求分析完成之后，设计人员可以使用Erwin画ER图，将ER图转换为关系数据模型，生成数据库结构；画数据流图，生成应用程序。
二、数据库设计技巧
1. 设计数据库之前（需求分析阶段）
1) 理解客户需求，询问用户如何看待未来需求变化。让客户解释其需求，而且随着开发的继续，还要经常询问客户保证其需求仍然在开发的目的之中。
2) 了解企业业务可以在以后的开发阶段节约大量的时间。
3) 重视输入输出。
在定义数据库表和字段需求（输入）时，首先应检查现有的或者已经设计出的报表、查询和视图（输出）以决定为了支持这些输出哪些是必要的表和字段。
举例：假如客户需要一个报表按照邮政编码排序、分段和求和，你要保证其中包括了单独的邮政编码字段而不要把邮政编码糅进地址字段里。
4) 创建数据字典和ER 图表
ER 图表和数据字典可以让任何了解数据库的人都明确如何从数据库中获得数据。ER图对表明表之间关系很有用，而数据字典则说明了每个字段的用途以及任何可能存在的别名。对SQL 表达式的文档化来说这是完全必要的。
5) 定义标准的对象命名规范
数据库各种对象的命名必须规范。
2. 表和字段的设计（数据库逻辑设计）
表设计原则
1) 标准化和规范化
数
据的标准化有助于消除数据库中的数据冗余。标准化有好几种形式，但Third Normal Form（3NF）通常被认为在性能、扩展性和数据完整性方
面达到了最好平衡。简单来说，遵守3NF 标准的数据库的表设计原则是：“One Fact in One Place”即某个表只包括其本身基本的属
性，当不是它们本身所具有的属性时需进行分解。表之间的关系通过外键相连接。它具有以下特点：有一组表专门存放通过键连接起来的关联数据。
举例：某个存放客户及其有关定单的3NF 数据库就可能有两个表：Customer 和Order。Order 表不包含定单关联客户的任何信息，但表内会存放一个键值，该键指向Customer 表里包含该客户信息的那一行。
事实上，为了效率的缘故，对表不进行标准化有时也是必要的。
2) 数据驱动
采用数据驱动而非硬编码的方式，许多策略变更和维护都会方便得多，大大增强系统的灵活性和扩展性。
举
例，假如用户界面要访问外部数据源（文件、XML 文档、其他数据库等），不妨把相应的连接和路径信息存储在用户界面支持表里。还有，如果用户界面执行工
作流之类的任务（发送邮件、打印信笺、修改记录状态等），那么产生工作流的数据也可以存放在数据库里。角色权限管理也可以通过数据驱动来完成。事实上，如
果过程是数据驱动的，你就可以把相当大的责任推给用户，由用户来维护自己的工作流过程。
3) 考虑各种变化
在设计数据库的时候考虑到哪些数据字段将来可能会发生变更。
举例，姓氏就是如此（注意是西方人的姓氏，比如女性结婚后从夫姓等）。所以，在建立系统存储客户信息时，在单独的一个数据表里存储姓氏字段，而且还附加起始日和终止日等字段，这样就可以跟踪这一数据条目的变化。

字段设计原则
4) 每个表中都应该添加的3 个有用的字段
•?dRecordCreationDate，在VB 下默认是Now()，而在SQL Server 下默认为GETDATE()
•?sRecordCreator，在SQL Server 下默认为NOT NULL DEFAULT USER
•?nRecordVersion，记录的版本标记；有助于准确说明记录中出现null 数据或者丢失数据的原因
5) 对地址和电话采用多个字段
描述街道地址就短短一行记录是不够的。Address_Line1、Address_Line2 和Address_Line3 可以提供更大的灵活性。还有，电话号码和邮件地址最好拥有自己的数据表，其间具有自身的类型和标记类别。
6) 使用角色实体定义属于某类别的列
在需要对属于特定类别或者具有特定角色的事物做定义时，可以用角色实体来创建特定的时间关联关系，从而可以实现自我文档化。
举
例：用PERSON 实体和PERSON_TYPE 实体来描述人员。比方说，当John Smith, Engineer 提升为
John Smith, Director 乃至最后爬到John Smith, CIO 的高位，而所有你要做的不过是改变两个表PERSON 和
PERSON_TYPE 之间关系的键值，同时增加一个日期/时间字段来知道变化是何时发生的。这样，你的PERSON_TYPE 表就包含了所有
PERSON 的可能类型，比如Associate、Engineer、Director、CIO 或者CEO 等。还有个替代办法就是改变
PERSON 记录来反映新头衔的变化，不过这样一来在时间上无法跟踪个人所处位置的具体时间。
7) 选择数字类型和文本类型尽量充足
在SQL 中使用smallint 和tinyint 类型要特别小心。比如，假如想看看月销售总额，总额字段类型是smallint，那么，如果总额超过了$32,767 就不能进行计算操作了。
而ID 类型的文本字段，比如客户ID 或定单号等等都应该设置得比一般想象更大。假设客户ID 为10 位数长。那你应该把数据库表字段的长度设为12 或者13 个字符长。但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。
8) 增加删除标记字段
在表中包含一个“删除标记”字段，这样就可以把行标记为删除。在关系数据库里不要单独删除某一行；最好采用清除数据程序而且要仔细维护索引整体性。
3. 选择键和索引（数据库逻辑设计）
键选择原则：
1) 键设计4 原则
•?为关联字段创建外键。
•?所有的键都必须唯一。
•?避免使用复合键。
•?外键总是关联唯一的键字段。
2) 使用系统生成的主键
设计数据库的时候采用系统生成的键作为主键，那么实际控制了数据库的索引完整性。这样，数据库和非人工机制就有效地控制了对存储数据中每一行的访问。采用系统生成键作为主键还有一个优点：当拥有一致的键结构时，找到逻辑缺陷很容易。
3) 不要用用户的键(不让主键具有可更新性)
在确定采用什么字段作为表的键的时候，可一定要小心用户将要编辑的字段。通常的情况下不要选择用户可编辑的字段作为键。
4) 可选键有时可做主键
把可选键进一步用做主键，可以拥有建立强大索引的能力。

索引使用原则：
索引是从数据库中获取数据的最高效方式之一。95%的数据库性能问题都可以采用索引技术得到解决。
1) 逻辑主键使用唯一的成组索引，对系统键（作为存储过程）采用唯一的非成组索引，对任何外键列采用非成组索引。考虑数据库的空间有多大，表如何进行访问，还有这些访问是否主要用作读写。
2) 大多数数据库都索引自动创建的主键字段，但是可别忘了索引外键，它们也是经常使用的键，比如运行查询显示主表和所有关联表的某条记录就用得上。
3) 不要索引memo/note 字段，不要索引大型字段（有很多字符），这样作会让索引占用太多的存储空间。
4) 不要索引常用的小型表
不要为小型数据表设置任何键，假如它们经常有插入和删除操作就更别这样作了。对这些插入和删除操作的索引维护可能比扫描表空间消耗更多的时间。

4. 数据完整性设计（数据库逻辑设计）
1) 完整性实现机制：
实体完整性：主键
参照完整性：
父表中删除数据：级联删除；受限删除；置空值
父表中插入数据：受限插入；递归插入
父表中更新数据：级联更新；受限更新；置空值
DBMS对参照完整性可以有两种方法实现：外键实现机制（约束规则）和触发器实现机制
用户定义完整性：
  NOT NULL；CHECK；触发器
2) 用约束而非商务规则强制数据完整性
采用数据库系统实现数据的完整性。这不但包括通过标准化实现的完整性而且还包括数据的功能性。在写数据的时候还可以增加触发器来保证数据的正确性。不要依赖于商务层保证数据完整性；它不能保证表之间（外键）的完整性所以不能强加于其他完整性规则之上。
3) 强制指示完整性
在有害数据进入数据库之前将其剔除。激活数据库系统的指示完整性特性。这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。
4) 使用查找控制数据完整性
控制数据完整性的最佳方式就是限制用户的选择。只要有可能都应该提供给用户一个清晰的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性。某些公共数据特别适合查找：国家代码、状态代码等。
5) 采用视图
为了在数据库和应用程序代码之间提供另一层抽象，可以为应用程序建立专门的视图而不必非要应用程序直接访问数据表。这样做还等于在处理数据库变更时给你提供了更多的自由。
5. 其他设计技巧
1) 避免使用触发器
触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器，你最好集中对它文档化。
2) 使用常用英语（或者其他任何语言）而不要使用编码
在创建下拉菜单、列表、报表时最好按照英语名排序。假如需要编码，可以在编码旁附上用户知道的英语。
3) 保存常用信息
让
一个表专门存放一般数据库信息非常有用。在这个表里存放数据库当前版本、最近检查/修复（对Access）、关联设计文档的名称、客户等信息。这样可以实
现一种简单机制跟踪数据库，当客户抱怨他们的数据库没有达到希望的要求而与你联系时，这样做对非客户机/服务器环境特别有用。
4) 包含版本机制
在数据库中引入版本控制机制来确定使用中的数据库的版本。时间一长，用户的需求总是会改变的。最终可能会要求修改数据库结构。把版本信息直接存放到数据库中更为方便。
5) 编制文档
对所有的快捷方式、命名规范、限制和函数都要编制文档。
采用给表、列、触发器等加注释的数据库工具。对开发、支持和跟踪修改非常有用。
对数据库文档化，或者在数据库自身的内部或者单独建立文档。这样，当过了一年多时间后再回过头来做第2 个版本，犯错的机会将大大减少。
6) 测试、测试、反复测试
建立或者修订数据库之后，必须用用户新输入的数据测试数据字段。最重要的是，让用户进行测试并且同用户一道保证选择的数据类型满足商业要求。测试需要在把新数据库投入实际服务之前完成。
7) 检查设计
在开发期间检查数据库设计的常用技术是通过其所支持的应用程序原型检查数据库。换句话说，针对每一种最终表达数据的原型应用，保证你检查了数据模型并且查看如何取出数据。
三、数据库命名规范
1. 实体（表）的命名
1)
表以名词或名词短语命名，确定表名是采用复数还是单数形式，此外给表的别名定义简单规则（比方说，如果表名是一个单词，别名就取单词的前4 个字母；如
果表名是两个单词，就各取两个单词的前两个字母组成4 个字母长的别名；如果表的名字由3 个单词组成，从头两个单词中各取一个然后从最后一个单词中再取
出两个字母，结果还是组成4 字母长的别名，其余依次类推）
对工作用表来说，表名可以加上前缀WORK_ 后面附上采用该表的应用程序的名字。在命名过程当中，根据语义拼凑缩写即可。注意，由于ORCLE会将字段名称统一成大写或者小写中的一种，所以要求加上下划线。
举例：
定义的缩写 Sales: Sal 销售；
Order: Ord 订单；
Detail: Dtl 明细；
则销售订单明细表命名为：Sal_Ord_Dtl;
2) 如果表或者是字段的名称仅有一个单词，那么建议不使用缩写，而是用完整的单词。
举例：
定义的缩写 Material Ma 物品；
物品表名为：Material, 而不是 Ma.
但是字段物品编码则是：Ma_ID;而不是Material_ID
3) 所有的存储值列表的表前面加上前缀Z
目的是将这些值列表类排序在数据库最后。
4) 所有的冗余类的命名(主要是累计表)前面加上前缀X
冗余类是为了提高数据库效率，非规范化数据库的时候加入的字段或者表
5) 关联类通过用下划线连接两个基本类之后，再加前缀R的方式命名,后面按照字母顺序罗列两个表名或者表名的缩写。
关联表用于保存多对多关系。
如果被关联的表名大于10个字母，必须将原来的表名的进行缩写。如果没有其他原因，建议都使用缩写。
举例：表Object与自身存在多对多的关系,则保存多对多关系的表命名为：R_Object；
表 Depart和Employee;存在多对多的关系；则关联表命名为R_Dept_Emp
2. 属性（列）的命名
1)
采用有意义的列名，表内的列要针对键采用一整套设计规则。每一个表都将有一个自动ID作为主健,逻辑上的主健作为第一组候选主健来定义,如果是数据库自
动生成的编码，统一命名为：ID;如果是自定义的逻辑上的编码则用缩写加“ID”的方法命名。如果键是数字类型，你可以用_NO 作为后缀；如果是字符类
型则可以采用_CODE 后缀。对列名应该采用标准的前缀和后缀。
举例：销售订单的编号字段命名：Sal_Ord_ID；如果还存在一个数据库生成的自动编号，则命名为：ID。
2) 所有的属性加上有关类型的后缀，注意，如果还需要其它的后缀，都放在类型后缀之前。
注: 数据类型是文本的字段，类型后缀TX可以不写。有些类型比较明显的字段，可以不写类型后缀。
3) 采用前缀命名
给每个表的列名都采用统一的前缀，那么在编写SQL表达式的时候会得到大大的简化。这样做也确实有缺点，比如破坏了自动表连接工具的作用，后者把公共列名同某些数据库联系起来。
3. 视图的命名
1) 视图以V作为前缀，其他命名规则和表的命名类似；
2) 命名应尽量体现各视图的功能。
4. 触发器的命名
触发器以TR作为前缀，触发器名为相应的表名加上后缀，Insert触发器加 _I ，Delete触发器加 _D ，Update触发器加 _U ，如：TR_Customer_I，TR_Customer_D，TR_Customer_U。
5. 存储过程名
存储过程应以 UP_ 开头，和系统的存储过程区分，后续部分主要以动宾形式构成，并用下划线分割各个组成部分。如增加代理商的帐户的存储过程为 UP_Ins_Agent_Account 。
6. 变量名
变量名采用小写，若属于词组形式，用下划线分隔每个单词，如@my_err_no。
7. 命名中其他注意事项
1)  以上命名都不得超过30个字符的系统限制。变量名的长度限制为29（不包括标识字符@）。
2)  数据对象、变量的命名都采用英文字符，禁止使用中文命名。绝对不要在对象名的字符之间留空格。
3) 小心保留词，要保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突
5) 保持字段名和类型的一致性，在命名字段并为其指定数据类型的时候一定要保证一致性。假如数据类型在一个表里是整数，那在另一个表里可就别变成字符型了。

<?php

/*

* @url: 文件地址

* @filename: 要保存的文件名

*/

function _download($url, $filename)

{

// 获得文件大小, 防止超过2G的文件, 用sprintf来读

$filesize = sprintf("%u", filesize($url));



if (!$filesize)

{

return;

}



header("Content-type:application/x-msdownload\n"); //application/octet-stream

header("Content-type:unknown/unknown;");

header("Content-disposition: inline; filename=\"".$filename."\"");

header('Content-transfer-encoding: binary');



if ($range = getenv('HTTP_RANGE')) // 当有偏移量的时候，采用206的断点续传头

{

$range = explode('=', $range);

$range = $range[1];



header("HTTP/1.1 206 Partial Content");

header("Date: " . gmdate("D, d M Y H:i:s") . " GMT");

header("Last-Modified: ".gmdate("D, d M Y H:i:s", filemtime($url))." GMT");

header("Accept-Ranges: bytes");

header("Content-Length:".($filesize - $range));

header("Content-Range: bytes ".$range.($filesize-1)."/".$filesize);

header("Connection: close"."\n\n");

}

else

{

header("Content-Length:".$filesize."\n\n");

$range = 0;

}



$fp = fopen($url, 'rb');

fseek($fp, $range);

while ($bbsf = fread($fp, 4096))

{

echo $bbsf;

}

fclose($fp);



}

?>