Oracle与SQL Server在企业应用中的比较

核心提示： 请记住，我不是维护街上花店的系统，Oracle与SQL Server在企业应用中的比较(2)，微软正在尽自己最大的力量进入企业中，进入Oracle的领地，另一方面，我在思考的时候你正好站在我后面，因此我要讨论的是：企业级系统管理员所关心的问题， 由于公司需要使用管理企业级系统(我们公司是S

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

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

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

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