什么是仍然使用SQL Server 2000的原因？

商业头脑通常和你的很不一样。 为什么要使用新的东西，如果它不会产生更多的收入，但只有开支（移民，再培训等）？

我能想到的最好的原因是“不会中断”的变化，如下所示：您有一个与SQL 2000一起工作的业务应用程序，但是会使用SQL 2005生成错误。它可能不是您组织的正确业务优先级在这个时候打开该应用程序（这是不是打破）的引擎盖，并使其与一个较新的数据库工作。

传统支持

SQL Server 2005与SQL Server 2000不完全向后兼容。Analysis Services具有严重的不兼容性。 迁移到SQL Server 2005具有回归testing和移植的非零成本。 许多组织没有要求移动，所以他们不会移动，直到必须移动。

大多数DBMS供应商（包括MS）将支持DBMS版本10年左右 – 这比大多数其他types的软件更长。 如果你用白银（足够数量）交叉手掌，他们也会input特定的合同，以延长对特定版本的支持。

其他原因坚持使用旧版本是真正的驱动的具体情况，如避免已知的僵化版本（如MySQL 5.1或SP3以前的SQL2000）或authentication或兼容性问题。

维护一个SQL Server 2000生产数据库

对于运行良好且运行正常的系统而言，如果没有很多重大变化，那么在数据库pipe理系统退出主stream支持之前，可能没有任何令人信服的理由进行升级。 但是，您应该为这种可能性计划有序的升级途径。 甲骨文在维护古代版本生产系统方面颇有名气。

SQL Server 2000已经接近尾声，所以你不想在这方面做新的开发工作。 但是，生产应用程序应该保持一个计划，当你需要的时候离开。 如果你的应用程序是用VB6或者传统的ASP编写的，你可能会重写你的手 – 但这是一个不同的问题; – }。

反案件

如果我有一个绿地项目，我通常会推荐最新版本的DBMS平台，因为它给了你最长的供应商支持窗口。 没有人应该将SQL Server 2000作为新项目的企业标准 – EOL太靠近了。 对于一个新项目来说，这是迄今为止转向新版本的最强有力的论据。 有关省钱的论点不成立， 如果现在开始使用SQL2000，应用程序将在几年内招致不必要的移植成本。

绿地工作的关键在于过分保守的select会在需要升级之前缩短应用的使用寿命。 人们通常会想要一个特定的原因不去当前版本的DBMS平台。

我们没有升级，因为我们有依赖于它的财务软件，供应商只是在考虑支持最近他们听到疯狂的孩子博客的这个新的“SQL 2005”。

坦率地说， 让我感到困惑的是有一些东西需要支持，但并不是那样会伤害到公司里的所有人 ，使得财务系统出现问题，然后让财务软件供应商指向我们，当我们请求帮助的时候，我们大笑，并且提到自从我们升级到SQL 2005之后，问题就开始了。

如果他们没有被破坏，还有很多事情可以被说明。 我确实想把我所有的SQL服务器升级到2008年的某个时候…我真的这样做。 但是我可以做的事情还有很多，实际上以我的经理和用户可以理解和量化的方式改善了业务的底线……而且这总是会先到的。

你提到开发人员不喜欢在SQL 2000中回应Mastermind的答案。 如果我决定“不喜欢”支持SQL 2000，那么我怀疑有一种处理这个问题的方法就是我的老板们会使用这个方法：“谢谢你在这里工作的时间，门在你的左边”。 在一天结束的时候，无论我们喜不喜欢，我们都会为了赚钱而努力工作。

在我们的案例中，“为什么要继续使用2000”的情况不如“升级成本如此之高”的情况。 我们的大多数应用程序不使用任何需要2005特定function的任何东西，因此没有任何令人信服的理由，并且可能直到微软停止对它的支持。

成本。

较新的软件仍然是额外的软件，这需要额外的钱。

由于使用过时系统的许多不利方面，这可能是并且往往是虚假的经济，但这是唯一有道理的理由。

SQL Server 2008（标准）的新许可证对于具有5个CAL的1台服务器而言，花费略低于2,000美元，对于1个CPU许可证则花费$ 6,000。 我可以听到我的老板说：“这不是坏了，但是升级这两台服务器要花多less钱？” （当时是2个需要CPU许可证的双CPU）。

在使用SQL2000七年之后，我在2005年的第一次经历是在VMWare ESX环境中。 性能很糟糕（ISP提供了VMWare的专业知识，当我们开始加载testing时，我们发现他们不仅在我们的服务器上，而且在影响我们的经验方面遇到了重大问题），并且结合所有移动/重命名的东西（旧的企业pipe理者是sooo快得多） – 我们更乐意推迟升级。 然后我们等待2008年的发布，所以我们现在只升级到2008年（或者将一些数据迁移到MySQL / PostgresSQL）。

微软在去年的某个时候仍然给予2000年的主stream支持，所以直到最近我们才有了更有说服力的升级理由。

小公司也有一个资源问题 – 学习，计划，testing升级需要时间和影响其他业务。 如果您必须同时升级某个位于SQL Server上的其他应用程序，则可能会变得非常昂贵。

一段时间以来，我们一直致力于开源，而这也是一种冻结升级的可能性。

为什么不升级到SQL Server 2008，那么你实际上可以降低你的成本，由于数据压缩，更容易维护和改善性能（过滤索引）？ 最近我们升级了sql server 2000安装，节省了75％的磁盘空间，性能大幅提升。

另一个改进是由于在sql server 2005中引入了新的locking机制而导致的并发性。

/HåkanWinther

大型组织的风险是不利的和无知的，这导致了一些非常愚蠢的决定。 当我在2003/2004年左右开始使用Unix时，我们遇到了一个Solaris 2.5.1环境，因为它是“成熟”的技术，而且升级“太昂贵”，所以我在十年级时就已经发布了。

过于昂贵的PHB往往是这样说的：“我在1000万美元的项目中花费了1000美元的预算，真是愚蠢至极”。

在微软堆栈软件的情况下，人们经常会升级，因为他们不想处理公司内部的许可证问题，并且从戴尔/ IBM /等处购买了OEM许可证，并且不想处理参与升级的官僚环节。

我不会购买（双语意图的）“前期成本”的说法，但不幸的是，前期的成本是许多PHB所迷恋的，所以让它站得住脚是有道理的。

对我来说，唯一令人信服的理由是使用它的应用程序。 例如，如果你是一个SharePoint 2003家庭，那么你就没有办法升级到SQL 2005或者2008，而不进行SharePoint升级，这不是一件小事。

在我们的组织中，所有新的开发都应该在SQL 2005/2008上，但是我们有这么多传统的2000应用程序，只是不值得花费时间/精力/金钱来转换它们。

除了兼容性问题（DTS到SSIS是我们最大的问题）之外，我们还对SQL 2005实施了一套我们没有针对SQL 2000强制执行的指导方针/安全限制。（没有dbo用户，只有模式权限，等等。）

在我们的组织中，有几个原因。 其中一些与我们的案例相当具体，另外一些则更为通用。

1）不兼容。 在SQL2005上安装SQL2005的内部软件时遇到了一些问题。 我最近看到的情况最终是由于显式声明的参数在2000年不存在，而且系统索引表的名称不同。 （sys.indexes vs sysindexes）

2）培训。 我们的开发人员当然知道2005年，并且宁愿开发它，或者2008年。 然而，保持一切运作的工作属于国家奥委会，而不是开发商。 我们的NOC中没有任何人接受过任何正式的SQL培训，仅仅从pipe理工具的angular度来看，两者之间的差异就足以使其成为一个考虑因素。

3）升级现有产品的成本。 对我们来说，这是一个很大的问题。 我不是在说微软的许可证费用。 在我们的业务中，任何现有产品的升级（即使我们没有追溯升级现有的所有产品），都需要通过几个不同的监pipe和authenticationtesting实验室进行昂贵而又冗长的重新authentication过程。 我们正在SQL2005上构build新产品，但由于这个原因，不能升级旧产品。

authentication过程也意味着我们最终会在新的版本上混合使用，在某些辖区将获得SQL2000和其他将获得SQL2005的基础上，如果批准还没有收到。 出于理由2，我们宁愿保持我们的生产环境尽可能一致。

4）一般差异。 这真的是＃1的延伸。 有很多小的事情发生了变化，其中一些让我们头疼。 例如，Server2003上的SQL2005将在sql帐户上执行Windows密码策略。 这本身并不是一件坏事，但是由于我们与数据库交互的方式，它几乎打破了我们所有（甚至是第三方）的软件。

总之，惯性。

一个很好的博客文章 ，已经提出了同样的问题。

我知道有些人必须使用.NET 1.1，因为他们必须支持Windows 2000系统。

遵循这个逻辑，那么运行MSSQL 2000的一个实际原因是因为你可以支持Windows NT 4系统！

相信与否，但SQL Server 2005实际上运行在Windows Server 2000上。