第一种通常都是以你能教我使用Oracle吗？开始的，对此我比较礼貌的回答一般是当然可以，实际上我正准备办个Oracle学习班；准备好之后我就叫你。这是做好人的办法，我没有告诉询问者这可能花费我数周的精力。有时候我进一步告诉他们可以在哪儿去下载Oracle的完整版本，以供他们安装和熟悉。但是有时候这样做给我带来了麻烦，因为它可能招来过多的追随者。

第二种一般是这样开头的我们遇到了SQL Server的一些问题，我想看看Oracle是如何处理这个问题的。好的，我们终于有了一些进展了。我可以为他们提供帮助，但是这不会占用我数小时时间。它应该是对某个特定问题进行了慎重地考虑之后的叙述，Oracle对这个问题的答案将为询问者指出一条道路，可能引导它们解决SQL Server的问题。询问者接者问我们的SQL Server数据库变得太大了--Oracle如何处理这个问题呢？唉...看来我说错了。

我想提供帮助，但是...

我的方法也许一直都是错的。也许我应该写一个总结材料，归纳可能涉及到的一些问题。当其他人向我寻求帮助的时候，我就可以把这个问题列表给他了。如果那个人正在接受普通的Oracle启蒙教育，这个列表也许稍微广泛了一些。另一方面，如果询问者在搜索特定的和可以量化的问题的解决方案，这个手册也可以帮助他们沿着正确的方面前进，这样他们就可以在自己的桌面上找到答案。

但我没有这样做，因为这样做花的时间太多了。尽管我尽可能地帮助这些寄居者，但是我真的担心为他们花费了太多的时间，偏离了自己的航向。这样做将是个不好的先例。它会鼓励他们在某个时刻遇到某些苦恼的时候再次回来向我求助。作为代替，我仅仅花几分钟时间谈一下SQL Server中的设计瑕疵。体系结构所涉及到的内容是不能改变的。如果你钻研数据库平台对比判断的技术细节，一般都无法得到那些不言自明的原理。相反地，如果你决定使用微软的数据库平台，这些问题就一定存在。它的特性或缺陷可能被我们处理得较好，但是产品基本的机制不容易改变--当然也不容易被封闭源代码软件的最终用户所改变。当然，有些办法可以减轻痛苦，但是却无法克服这些问题。两个平台之间有很大的差异，更不用说很多问题的起源之间的差异了。

请记住，我不是维护街上花店的系统。微软正在尽自己最大的力量进入企业中，进入Oracle的领地。因此我要讨论的是：企业级系统管理员所关心的问题。 我所关心的是...

由于公司需要使用管理企业级系统（我们公司是SAP），我更喜欢使用多用户（multiuser）数据库。现在你可能认为我使用这个术语太轻率了。实际上有大量的用户在多用户环境中使用SQL Server，不是吗？但是他们处理大量的并发用户是受到平台的影响，还是不管并发用户的？例如，我们来看看锁（locking）的问题。开始，微软告诉你读取者－阻塞－写入者的机制很好，很安全。它会告诉你这个机制防止了用户执行错读（dirty read）。不要相信这种鬼话；它只是性能低下的一个借口。这使我想起了Sun长期坚持认为64位系统不必要的立场。不必要是指他们销售这种产品之前没有必要存在。接下来，某一天Scott McNealy在你面前高谈不断增长的物理内存寻址的优点。

那么什么是错读？微软会告诉你，如果某个人正在更新一个数据行，而你准备读取这个处于更新之中的数据行，就会出现错读。错读=坏数据--这是微软希望你相信的内容。但是如果某个更新操作很长时间没有提交会出现什么情况？数据实际上没有真的被改变。如果那个更新操作在事务的末尾回滚了又会出现什么情况呢？这些读取者的等待得到了什么东西？什么也没有。

这就好像我在一家超市里，站在果汁面前，试图决定买哪一种。我知道自己会选择一种，我知道我的小孩明天早餐需要喝果汁。我已经伸出了手，但是还没有决定拿哪一种。上周我买的是苹果汁，上上周买的是什么呢？白葡萄汁。我想现在是不是该买酸葡萄汁了。另一方面，我在思考的时候你正好站在我后面，你可能在想这个白痴什么时候才能拿一瓶，并且不要挡住我呢？我可知道自己想要什么！

你会发现，我们都站在微软的杂货店前面，在你能够看见有哪些东西可以使用之前，你不得不等待，直到我做出决定为止。你看到了诱人的酸葡萄汁正摆放在货架上，而我也许会买下它，这对于你来说根本是没有意义的。因为我可能只是看看，但是微软知道你希望购买水果汁，因此你必须等待我停止闲逛或者选中某样东西，而这个过程都发生在你得到任何东西之前。