Open your thoughts

在确定某一索引适合某一查询之后，可以自定义最适合具体情况的索引类型。索引分为：

1. 聚集还是非聚集（有称聚簇）
2. 唯一还是不唯一
3. 单列还是多列（有称组合索引）
4. 索引中的列顺序为升序还是降序
5. 覆盖还是非覆盖

在考虑是否为一个列创建索引时，应考虑被索引的列是否以及如何用于查询中。索引对下列查询很有帮助：

1）搜索符合特定搜索关键字值的行（精确匹配查询）。精确匹配比较是指查询使用 WHERE 语句指定具有给定值的列条目。例如：
WHERE emp_id = ‘VPA30890F’

2）搜索其搜索关键字值为范围值的行（范围查询）。范围查询是指查询指定其值介于两个值之间的任何条目。例如：
WHERE job_lvl BETWEEN 9 and 12
或
WHERE job_lvl >= 9 and job_lvl <= 12

3）在表 T1 中搜索根据联接谓词与表 T2 中的某个行匹配的行（索引嵌套循环联接）。

4）在不进行显式排序操作的情况下产生经排序的查询输出，尤其是经排序的动态游标。

5）在不进行显式排序操作的情况下，按一种有序的顺序对行进行扫描，以允许基于顺序的操作，如合并联接和流聚合。

6）以优于表扫描的性能对表中所有的行进行扫描，性能提高是由于减少了要扫描的列集和数据总量（该查询有覆盖索引可供使用）。

7）搜索插入和更新操作中重复的新搜索关键字值，以实施 PRIMARY KEY 和 UNIQUE 约束。

8）搜索已定义了 FOREIGN KEY 约束的两个表之间匹配的行。

9）使用 LIKE 比较进行查询时，如果模式以特定字符串如”abc%”开头，使用索引则会提高效率；如果模式以通配符如”%xyz”开头，则索引不起作用。

设计索引时还要考虑的其它准则包括：

1）一个表如果建有大量索引会影响 INSERT、UPDATE 和 DELETE 语句的性能，因为在表中的数据更改时，所有索引都须进行适当的调整。另一方面，对于不需要修改数据的查询（SELECT 语句），大量索引有助于提高性能，因为 SQL Server 有更多的索引可供选择，以便确定以最快速度访问数据的最佳方法。

2）覆盖的查询可以提高性能。覆盖的查询是指查询中所有指定的列都包含在同一个索引中。例如，如果在一个表的 a、b 和 c 列上创建了组合索引，则从该表中检索 a 和 b 列的查询被视为覆盖的查询。创建覆盖一个查询的索引可以提高性能，因为该查询的所有数据都包含在索引自身当中；检索数据时只需引用表的索引页，不必引用数据页，因而减少了 I/O 总量。尽管给索引添加列以覆盖查询可以提高性能，但在索引中额外维护更多的列会产生更新和存储成本。

3）对小型表进行索引可能不会产生优化效果，因为 SQL Server 在遍历索引以搜索数据时，花费的时间可能会比简单的表扫描还长。

4）应使用 SQL 事件探查器和索引优化向导帮助分析查询，确定要创建的索引。为数据库及其工作负荷选择正确的索引是非常复杂的，需要在查询速度和更新成本之间取得平衡。窄索引（搜索关键字中只有很少的列的索引）需要的磁盘空间和维护开销都更少。而另一方面，宽索引可以覆盖更多的查询。确定正确的索引集没有简便的规则。经验丰富的数据库管理员常常能够设计出很好的索引集，但是，即使对于不特别复杂的数据库和工作负荷来说，这项任务也十分复杂、费时和易于出错。可以使用索引优化向导使这项任务自动化。

5）可以在视图上指定索引。

6）可以在计算列上指定索引。

在关系数据库设计理论中，规范化规则指出了在设计良好的数据库中必须出现或不出现的某些特性。关于规范化规则的完整讨论不属于本主题的范畴。不过，有几个可帮助获得合理的数据库设计的规则：

1）表应该有一个标识符。
数据库设计理论的基本原理是：每个表都应有一个唯一的行标识符，可以使用列或列集将任何单个记录同表中的所有其它记录区别开来。每个表都应有一个 ID 列，任何两个记录都不可以共享同一 ID 值。作为表的唯一行标识符的一列或多列是表的主键。

2）表应只能存储单一类型实体的数据。
试图在表中存储过多的信息会妨碍对表的数据进行有效、可靠的管理。在 SQL Server 2000 的 pubs 数据库中，书名和出版商的信息存储在两个独立的表内。尽管在 titles 表中同时创建书籍及其出版商的信息列是可能的，但是这种设计会导致几个问题。必须为出版商出版的每本书添加并存储出版商信息，而这是没有必要的，并且会占用数据库中的额外存储空间。如果出版商的地址更改了，则必须对每本书进行更改。出版商的最后一本书从标题表中删除后，该出版商的信息就会丢失。

在 pubs 数据库中，书和出版商的信息存储在 titles 和 publishers 表中，有关出版商的信息只须输入一次，然后即链接到每本书上。当出版商信息更改时，只需要在数据库中的一个地方进行更改，即使该出版商在数据库中没有书，出版商信息仍然存在。

3）表应避免可为空的列。
表中的列可定义为允许空值。空值表示没有值。尽管在个别情况下，允许空值有用，但是最好少用空值，因为空值需要进行特殊的处理，这样会增加数据操作的复杂性。如果某一表中有几个可为空的列，并且列中的几行有空值，则应考虑将这些列置于链接到主表的其它表中。将数据存储在两个独立的表中使主表的设计更为简单，但能够满足存储空值信息的偶尔需要。

4）表不应有重复的值或列。
数据库中某一项目的表不应包含特定信息的值列表。例如，pubs 数据库中的书可以是合著的。如果在 titles 表中有一列是作者的名称，这就会出现问题。一种解决方法是：在列中存储两位作者的姓名，但这样会很难显示单个作者的列表。另一种解决方法：是更改表的结构，为第二位作者的姓名添加另一列，但这只能包含两位作者。当然，如果一本书有三位作者，则必须再添一列。

如果发现需要在单个列中存储值的列表，或者如果单个数据需要多列（au_lname1、au_lname2 等等），则应考虑将重复的数据置于与主表有链接的另一个表中。pubs 数据库有一个表存储书信息，另一个表存储书的 ID 值和书作者的 ID 值。这种设计允许书有任意数目的作者，而不用修改表的定义，同时不用为单个作者的书分配未使用的存储空间。

数据库规范化：  有大量窄表（列较少的表）是规范化数据库的特征。而拥有少量宽表（列较多的表）是非规范化数据库的特征。
通常，合理的规范化将提高性能。规范化的一些益处包括：

1. 排序和索引创建更快。
2. 聚集索引的数目更大。
3. 索引更窄、更精简。
4. 每个表的索引更少，这样将提高 INSERT、UPDATE 和 DELETE 语句的性能。
5. 空值更少，出现不一致性的机会更少，从而提高数据库紧凑性。
6. 随着规范化的不断提高，检索数据所需的联接数和复杂性也将不断增大。太多表间的关系联接太多、太复杂可能会影响性能。合理的规范化通常很少包括经常性执行的、所用的联接涉及 4 个以上表的查询。

其实还有一些没有指出来的很明显的好处：

1. 消除数据冗余
2. 利于维护数据的一致性和完整性

规范化实质上是一个对客观世界不断细化从而得到更具体对象的过程，可以这么说，每个经过规范化的表，都对应着客观世界的一个事物。

在计划数据库时，不管其大小和复杂性如何，都要经过下列基本步骤：

1. 收集信息。
2. 标识对象。
3. 建立对象模型。
4. 标识每个对象的信息类型。
5. 标识对象之间的关系。

作者：不详

注意:这里说的delete是指不带where子句的delete语句

相同点:truncate和不带where子句的delete, 以及drop都会删除表内的数据

不同点:
1. truncate和 delete只删除数据不删除表的结构(定义)
drop语句将删除表的结构被依赖的约束(constrain),触发器(trigger),索引(index); 依赖于该表的存储过程/函数将保留,但是变为invalid状态.

2.delete语句是DML,这个操作会放到rollback segement中,事务提交之后才生效;如果有相应的trigger,执行的时候将被触发.
truncate,drop是DDL, 操作立即生效,原数据不放到rollback segment中,不能回滚. 操作不触发trigger.

3.delete语句不影响表所占用的extent, 高水线(high watermark)保持原位置不动
显然drop语句将表所占用的空间全部释放
truncate 语句缺省情况下见空间释放到 minextents个 extent,除非使用reuse storage; truncate会将高水线复位(回到最开始).

4.速度,一般来说: drop> truncate > delete

5.安全性:小心使用drop 和truncate,尤其没有备份的时候.否则哭都来不及
使用上,想删除部分数据行用delete,注意带上where子句. 回滚段要足够大.
想删除表,当然用drop
想保留表而将所有数据删除. 如果和事务无关,用truncate即可. 如果和事务有关,或者想触发trigger,还是用delete.
如果是整理表内部的碎片,可以用truncate跟上reuse stroage,再重新导入/插入数据.

注意：From Oracle 10g a table can be “undropped”.

今天下午浏览CSDN,吃惊发现ORACLE真的把BEA给吞了.之前,一直有新闻报道这件事情,但因为BEA认为oracle提出的收购报价不能真正体现BEA的真实价值,所以拒绝了oracle的”求婚”.没想到oracle为了增加自己在中间件领域的实力和市场,很下血本,ORACLE也快成为另一个”微软”了.

另一业界新闻便是SUN收购了MySQL, 对于SUN这样一家极富创造力的公司, 我是非常佩服的, 软硬通吃, 但在市场及销售策略上逊色于其它公司而导致业绩不佳. 单单以Java语言为例, 本由自己研究出来的,反而自己没有赚得多少利润, 倒是给IBM这样的行业巨头搭建了唱戏的平台.

衷心祝愿SUN在开源道路上健步前行……

set names GBK