blog 和 wiki 技术概述
从 20 世纪 90 年代末起（那时 Web 的繁荣正达到某个饱和点），一些用户开始编辑他们最喜欢的网站清单，这些网站符合一定的兴趣或主题。许多包含在用户清单上的条目都被加了评论，并标注了日期。这样的清单很快被称为 weblog 或 blog（博客），维护这样的 blog 的人被称为 blogger。后来，blog 开始变成文章的集合，通常以时间倒序的形式呈现，并与一个特定的主题相关。Wikipedia 对 blog 的定义如下：
早期的 weblog 仅仅是普通网站的手动更新组件。然而用于简化网络文章（以所谓时序性风格发表）生成及维护的工具的发展使得发表的过程在规模上更为庞大、技术含量更低并更加流行。最终导致了这种在线发布的类型，由此产生了今天的 blog。例如，使用一些基于浏览器的软件是当今 “blog” 的一种典型表现。可以通过专门的 blog 主机服务来托管 blog，blog 也能通过使用 blog 软件在一般的网络主机服务上运行。像其他媒体一样，blog 通常关注某一特定的主题，诸如食品、政治或本地新闻。一些 blog 以在线日记的形式存在。
在 blog 开始出现的同一段时间里，Ward Cunningham 发明了一项技术，这项技术允许任何人通过简单的编辑为 Web 页面做贡献。他将这项技术命名为 Wiki Wiki Web（来源于夏威夷语单词 wiki ，意为迅速 或快），后来这个名字被缩略到只有 wiki 。使用 wiki 的一项显著优势是用户可以当场向 Web 页面贡献内容。另外，因为编辑起来很简单，因而贡献内容时不需要任何特殊的软件。可以在 Wikipedia Web 的百科全书上找到更多关于 wiki 技术的信息，该网站本身就是使用 wiki 技术实现的。（参见 参考资料 上的链接）。
协作性应用程序
这就是 Web 2.0 的全部，尽管该术语出现才几乎一年的时间，但现在好像只有烹饪杂志还没有加入到讨论 Web 2.0 未来出路的行列中。自从出现了里程碑式的文章 “What Is Web 2.0: Design Patterns and Business Models for the Next Generation of Software”（此文由 Tim O'Reilly 在 2005 年 9 月所写，参见 参考资料 中的链接），对 Web 2.0 这一由该文创造的术语的赞同或反对之声一直没有间断。尽管如此，大多数人都认同了 Web 业已改变并进入了一个新的发展阶段，这是带其步入下一个逻辑高度的阶段。在 O'Reilly 的文章中，他阐释了任何 Web 2.0 公司必须具备的核心元素：
交易日志（Transaction logs）是数据库结构中非常重要但又经常被忽略的部分。由于它并不像数据库中的schema那样活跃，因此很少有人关注交易日志。
交易日志是针对数据库改变所做的记录，它可以记录针对数据库的任何操作，并将记录结果保存在独立的文件中。对于任何每一个交易过程，交易日志都有非常全面的记录，根据这些记录可以将数据文件恢复成交易前的状态。从交易动作开始，交易日志就处于记录状态，交易过程中对数据库的任何操作都在记录范围，直到用户点击提交或后退后才结束记录。每个数据库都拥有至少一个交易日志以及一个数据文件。
出于性能上的考虑，SQL Server将用户的改动存入缓存中，这些改变会立即写入交易日志，但不会立即写入数据文件。交易日志会通过一个标记点来确定某个交易是否已将缓存中的数据写入数据文件。当SQL Server重启后，它会查看日志中最新的标记点，并将这个标记点后面的交易记录抹去，因为这些交易记录并没有真正的将缓存中的数据写入数据文件。这可以防止那些中断的交易修改数据文件。
维护交易日志
因为很多人经常遗忘交易日志，因此它也会给系统带来一些问题。随着系统的不断运行，日志记录的内容会越来越多，日志文件的体积也会越来越大，最终导致可用磁盘空间不足。除非日常工作中经常对日志进行清理，否则日志文件最终会侵占分区内的全部可用空间。日志的默认配置为不限容量，如果以这种配置工作，它就会不断膨胀，最终也会占据全部可用空间。这两种情况都会导致数据库停止工作。
对交易日志的日常备份工作可以有效的防止日志文件过分消耗磁盘空间。备份过程会将日志中不再需要的部分截除。截除的方法是首先把旧记录标记为非活动状态，然后将新日志覆盖到旧日志的位置上，这样就可以防止交易日志的体积不断膨胀。如果无法对日志进行经常性的备份工作，最好将数据库设置为"简单恢复模式"。在这种模式下，系统会强制交易日志在每次记录标记点时，自动进行截除操作，以新日志覆盖旧日志。
截除过程发生在备份或将旧标记点标为非活动状态时，它使得旧的交易记录可以被覆盖，但这并不会减少交易日志实际占用的磁盘空间。就算不再使用日志，它依然会占据一定的空间。因此在维护时，还需要对交易日志进行压缩。压缩交易日志的方法是删除非活动记录，从而减少日志文件所占用的物理硬盘空间。
一般情况下，SQL数据库的收缩并不能很大程度上减小数据库大小，其主要作用是收缩日志大小，应当定期进行此操作以免数据库日志过大。
1、设置数据库模式为简单模式：打开SQL企业管理器，在控制台根目录中依次点开Microsoft SQL Server-->SQL Server组-->双击打开你的服务器-->双击打开数据库目录-->选择你的数据库名称（如论坛数据库Forum）-->然后点击右键选择属性-->选择选项-->在故障还原的模式中选择“简单”，然后按确定保存
2、在当前数据库上点右键，看所有任务中的收缩数据库，一般里面的默认设置不用调整，直接点确定。
3、收缩数据库完成后，建议将您的数据库属性重新设置为标准模式，操作方法同第一点，因为日志在一些异常情况下往往是恢复数据库的重要依据 。
原文地址：http://www.111cn.net/?13542/action_viewspace_itemid_2928.html
MySQL从开发人员手中的“玩具”变为如今的“世界上最流行的开源数据库”，其中的过程伴随着产品版本升级，以及一些新功能（特别是企业数据库功能）的增加。现在，随着MySQL 5.0被完美地开发出来，已经很少有人将MySQL称为“玩具数据库”了。MySQL的丰富功能满足了许多用户的需求，Oracle最近的动作表明了他们对待MySQL非常重视——Oracle曾几次三番的表示有意收购MySQL。
MySQL的产品路线图
让我们先从MySQL的较有影响的版本产品开始，看一下MySQL的更新换代。
MySQL 4.0
MySQL 4.0是在2003年3月发布的，该版本使新的基于MySQL的应用程序获得了更广泛的应用。但是在4.0版中，MySQL不支持存储过程、触发程序、服务器端指针或视图。MySQL 4.0是从3.23发展而来，较之3.23版本有了很大的提高，主要适用于Web站点，这时候的MySQL还不是一个企业级数据库。
以下是MySQL 4.0的主要新特性：
FULLTEXT索引：最值得用户期待的可能就是FULLTEXT索引。
FULLTEXT在文本字段创建索引，为对该索引执行布尔搜索提供了一个强大而灵活的机制。依照一般的开发经验，开发人员通常必须创建索引并访问文本数据，而FULLTEXT索引比想象中的还要好得多。
许多解决方案仅限于全字索引，FULLTEXT索引没有这种限制，允许开发人员添加或拆分词组。
ANSI SQL UNION：支持ANSI SQL UNION语句，该语句将询问结果汇集到一个结果集。
多表操作：可以执行多表UPDATE和DELETE。
新语句：增加了其他DBMS用户所熟悉的一些非标准的新语句（如IDENTITY和TRUNCATE TABLE），以及FOUND_ROWS()等新功能，这些功能可以返回无需LIMIT子句就能返回的纪录的编号。
InnoDB存储引擎：InnoDB存储引擎在当时作为服务器的标准特性，在4.0版本中成为一个附加选项。InnoDb是允许ACID兼容事务的表类型，而非默认的MyISAM表类型，它可以加快一般性使用的速度，但对于关键操作不是十分有用。
InnoDB表使用行级别锁定特性，这意味着对一个记录的更新只锁定该记录，而不是整个表。当选择访问大量的数据库时（对于大多数Web站点而言），锁定整个表相当快，但是当插入和更新的数量接近于选项的数量时，则速度较慢。长期以来，对MySQL的批评一直集中在MyISAM表的安全性和一致性问题，兼容ACID的InnoDB表在解决这些问题上走过了很长一段路。
您需要了解如何使用某些SQL子句和运算符来安排SQL数据，从而对它进行高效分析。下面这些建议告诉您如何建立语句，获得您希望的结果。
以有意义的方式安排数据可能是一种挑战。有时您只需进行简单分类。通常您必须进行更多处理——进行分组以利于分析与总计。可喜的是，SQL提供了大量用于分类、分组和总计的子句及运算符。下面的建议将有助于您了解何时进行分类、何时分组、何时及如何进行总计。欲了解每个子句和运算符的详细信息，请查看在线书籍。
#1：分类排序
通常，我们确实需要对所有数据进行排序。SQL的ORDER BY子句将数据按字母或数字顺序进行排列。因此，同类数据明显分类到各个组中。然而，这些组只是分类的结果，它们并不是真正的组。ORDER BY显示每一个记录，而一个组可能代表多个记录。
#2：减少组中的相似数据
分类与分组的最大不同在于：分类数据显示（任何限定标准内的）所有记录，而分组数据不显示这些记录。GROUP BY子句减少一个记录中的相似数据。例如，GROUP BY能够从重复那些值的源文件中返回一个唯一的邮政编码列表：
SELECT ZIP
FROM Customers
GROUP BY ZIP
仅包括那些在GROUP BY和SELECT列列表中字义组的列。换句话说，SELECT列表必须与GROUP列表相匹配。只有一种情况例外：SELECT列表能够包含聚合函数。（而GROUP BY不支持聚合函数。）
记住，GROUP BY不会对作为结果产生的组分类。要对组按字母或数字顺序排序，增加一个ORDER BY子句（#1）。另外，在GROUP BY子句中您不能引用一个有别名的域。组列必须在根本数据中，但它们不必出现在结果中。
#3：分组前限定数据
您可以增加一个WHERE子句限定由GROUP BY分组的数据。例如，下面的语句仅返回肯塔基地区顾客的邮政编码列表。
SELECT ZIP
FROM Customers
WHERE State = 'KY'
GROUP BY ZIP
在GROUP BY子句求数据的值之前，WHERE对数据进行过滤，记住这一点很重要。
和GROUP BY一样，WHERE不支持聚合函数。
#4：返回所有组
当您用WHERE过滤数据时，得到的组只显示那些您指定的记录。符合组定义但不满足子句条件的数据将不会出现在组中。不管WHERE条件如何，如果您想包括所有数据，增加一个ALL子句。例如，在前面的语句中增加一个ALL子句会返回所有邮政编码组，而不仅仅是肯塔基地区的组。
SELECT ZIP