我 14 年前从事 Web 方面的工作时，它是一个静态实体。使用数据库非常困难，主要是因为在用户单击至另一个页面的链接时无法保持数据库连接打开。

　　当我学习 HTML 时，数据库主要用于静态报告。要获得数据？只需将数据放到带有大量 HTML 标签的表中。对于我来讲，这实际上是一个 Web 0 年代。所有事情都很困难，每个人都必须重头做起。

　　很快，每个公司都需要拥有自己的内部网。很容易通过 Apache 或 IIS Web 服务器建立内部网。事实上，它们可能太容易建立：它们兴旺起来了吗？但是随后几个月就停止了。最后，建立内部网的人员被各种请求拖垮。可以添加休假时间表吗？可以添加公司事件吗？可以创建一个休假输入表单吗？（法国有许多休假，必须很好地安排这些休假）。

　　诸如 Day、DirectNews、Joomla、Drupal 和许多其它（参见 cmsmatrix.org 以获取更完整的列表）内容管理系统（Content Management System，CMS）开始出现，帮助建立和维护 Web 站点。每个人都能够添加和修改内容（借助于一些规则、权限等）。

　　在大部分 CMS 包中，内容不存储在文件中，而是存储在数据库中，通常以非常结构化的方法进行存储：内容以层次结构组织（带有分支和叶子的树，叶子通常是一系列特定主题的内容）。数据库可以进行这项工作。我们都经历过数据库 101，根据主题、副主题和 n 层主题存储数据。当您学习或教授表递归时，它是一个很好的例子。

　　这是 Web 1.0 的诞生，是一种更聪明地存储和共享信息的方法。 []

　　您可能听说过一个理论，两个互不相识的人可以通过数量有限的其他人而彼此认识（流行的说法是相隔六个人）。也就是说，如果我想要联系 Barack Obama，那么在他和我之间最多有六个人。或者，如果我想要与某个软件公司的 CEO 聊天，但是我被他的公共关系经理人阻隔。我可能会询问我认识的人，他们是否在该公司有任何联系人可以为我介绍那个 CEO。那个联系人可能知道某人（依次类推），而那个人能够直接将我介绍给 CEO。

　　对于我来讲，这个例子演示 Web 2.0 如何开始：人们开始创建社会网络和其它工件（这在今天的站点很常见，比如 LinkedIn、Xing、Viadeo 等）：用户生成的内容、自助服务和 mashup 等。

　　我为什么在数据库杂志中讨论 Web 和社会网络的历史？Web 最初从使用文件开始，然后是层次结构数据，最后是关系数据结构。听上去熟悉吗？回忆一下数据库的历史，您将想起它们也是从文件开始，然后是层次结构系统，最后是关系模型。

　　下面是如何应用我们已经了解的知识。

　　经验 1：随着时间的推移，Web 站点将变得越来越复杂。即使不变得复杂，它最终也会涉及到复杂的数据、非结构化的数据，以及来源不同的数据。

　　经验 2：Web 站点不仅仅是数据的缓冲区；它是一个活动的应用，将必须提供越来越多的交互式服务。采取什么样的 Web 项目数据库取决于项目需求。与其它开发任务不同，Web 项目随着需求的发展而发展。当建立您的公司 Web 站点时，有人考虑到添加博客、添加订购系统吗或添加社会网络吗？

　　有些人可能会说：“我们有一个很好的 Web 站点，不需要添加博客或客户网络”。很好，那么请等待营销经理从下一个会议带回来的消息吧。请记住，您的 Web 站点在过去的 12 至 13 年中是如何必须进行改变的。 []

　　如果您在小公司工作，不要认为您就是例外；公司规模无关紧要。小型公司和大型公司一样，都使用博客、Facebook、LinkedIn 或创建他们自己的在线网络。

　　经验 3：您的 Web 站点必须不断变化。每天都有添加新服务的请求。

　　因此现在您归纳出结论：Web 不再是静止不动的。但是这和数据库有什么关系吗？

　　选择合适的数据库不但取决于目前的需求，而且取决于将来的需求。如果您选择一个开源的、基于 ISAM 的引擎，而以后需要实现一个与您的物理仓库交互的在线商店，那么应该怎么办呢？

　　在这方面，我比较欣赏 IBM 关于 DB2 Express-C 的策略。DB2 Express-C 可以免费使用；随着 Web 站点或其它需求的发展，客户可以逐步采购各种许可选项。

　　经验 4：设计 Web 应用程序时深谋远虑并不是一种奢侈的行为。我当前的项目之一与手机生产商 eLPi (elpitronic.com) 有关。为了激活电话的保修期，客户需要在线注册。公司想要一个专注于用户体验的和谐界面。因此，当客户进入法语支持站点时，他们需要选择一个 eLPi 电话可用的法语国家，然后从 AJAX 风格的列表中选择一个城市。要验证注册，客户输入电话的唯一编号（IMEI）并基于客户位置选择出售该电话的经销商。

　　在传统的 Web 1.0 站点中，消费者必须填写冗长的表单。在更高级的 Web 1.0 站点中，消费者需要输入个人资料，从 210 个或更多选项的列表中选择一个国家，并单击 “提交” ，然后输入电话的 IMEI 编号并再次单击 “提交”，然后选择一个经销商（先选择国家并提交，然后选择城市并提交，最后在城市中选择经销商并提交）。 []

　　在这两种情况中，您可以想像进行错误检查和错误报告的次数。这个过程将成为一场恶梦，我的客户开始怀疑他的顾客为何不在支持站点上注册。

　　在 Web 2.0 中，通过执行后台请求为用户简化了这个过程。您可以在 www.elpisupport.com/elpitronic/Index.html#inscription-customer 上亲自试验。当然，要完成注册，您需要购买一台 eLPi 的电话（我因客户的成功而激动）。

　　让我们看一下幕后发生的情况。当消费者进入站点时，运行第一个查询来获得可能的国家。然后用户开始键入他所在的城市；键入三个字符后，每次键击都运行一个查询来选择城市，这涉及到另外两个或三个查询。消费者需要验证 IMEI 编号，这至少还需要一个查询。最后，用户需要选择他的经销商（通过先选择国家、城市，然后选择经销商）。整个过程需要三个查询。一个输入表单的总查询数是多少？大约 10 个。

　　我可以想像到这样的观点：“嘿，在 Web 1.0 中您需要较少的查询，因为您将跳过城市查询，并且数据库上的负载将降低。我可以使用开源 ISAM 引擎”。

　　您当然可以使用。但是，让我们来看一下事实。请记住，在 Web 1.0 中，您将需要许多 “回合”。每个回合中都需要进行处理。只有当响应时间超出四秒时用户才会觉得 Web 站点令人讨厌。那对于 Web 1.0 方法而言已经足够 —— 它不在乎数据访问、查询和处理消耗 100 毫秒或 983 毫秒，只要它们在四秒钟内完成。

　　在 Web 2.0 中，当您键入所在城市的名称时，开始筛选列表。系统不会需要 983 毫秒来筛选列表。但是需要一个响应更快的系统来完成这项工作。

　　当然，开发人员可以开发缓存机制来增强性能。开发人员喜欢实现缓存机制。但是管理人员不喜欢缓存机制：开发人员必须花时间进行开发，它们的可靠性可能比较差，并且需要维护。

　　经验 5：让您的数据库引擎完成给分配给它的工作：数据分发、数据处理等。现在您获得这些能力了，是吗？如果您的引擎执行查询缓存和提供极好的事务吞吐量，那么您的开发团队就没有必要重新重现这一切。

　　经验 6：不必开发复杂的缓存机制，而应该专注于用户体验（UX）、工效学或其它给客户带来更多价值的工作。我公司的下一个项目正在朝这个方向发展。通过让数据库来处理数据库引擎，开发人员可以专注于应用程序的其它部分，例如使应用程序更简单和更易于使用。那将满足客户的要求：“我不希望拥有一个 4 年寿命的用户界面；我想要一个 65 年寿命的用户界面”。采用数据库

　　对于 Web 2.0，还有更多的经验需要学习。用户想要更多功能和更易于使用的组件；他们想要进行交互并在站点上留下足迹。同时，可用的数据和要管理的数据越来越多。最终的经验是什么？数据库是我们的朋友。