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

从StackOverflow和其他地方的问题中，我注意到仍然有人在使用SQL Server2000。老实说，对我来说最大的影响是我必须记住我们过去是如何在没有通用表表达式的情况下进行操作的。

尽管如此，我还是想知道是否还有实际的原因（除了“还不错”）仍可以使用SQL Server2000。例如，我知道有些人必须使用.NET 1.1，因为他们必须支持Windows 2000系统。是否有任何类似的实际原因不将SQL Server 2000系统升级到SQL Server 2008或2005？

商业头脑通常与您截然不同。如果它不会产生更多的收入，而只会产生费用（迁移，再培训等），为什么还要使用更新的东西？

我能想到的最好原因是“它没有坏”的变体，如下所示：您有一个使用SQL 2000的业务应用程序，但是使用SQL 2005却产生了错误。对于您的组织而言，它可能不是正确的业务优先级此时，打开该应用程序的引擎盖（不会损坏）并使其与更新的数据库一起使用。

旧版支持

SQL Server 2005并非与SQL Server 2000完全向后兼容。AnalysisServices具有严重的不兼容性。迁移到SQL Server 2005的回归测试和移植成本为非零。许多组织没有搬迁的要求，因此除非有必要，否则他们不会搬迁。

大多数DBMS供应商（包括MS）将支持DBMS版本长达10年左右-比大多数其他类型的软件更长。如果您用足够数量的白银横穿手掌，他们还将签订特定合约，以延长对特定版本的支持。

坚持使用较旧版本的其他原因实际上是由特定情况驱动的，例如避免使用已知的拙劣版本（例如MySQL 5.1或SP3之前的SQL2000）或认证或兼容性问题。

维护SQL Server 2000生产数据库

对于一个运行良好且处于生命周期成熟阶段并且没有进行大量重大更改的操作系统，在DBMS脱离主流支持之前，可能没有迫切的理由进行升级。但是，您应该为此计划有序的升级途径。Oracle以维护旧版本的生产系统而著称。

SQL Server 2000的使用寿命即将结束，因此您不希望对其进行新的开发工作。但是，应该维护生产应用程序并计划在需要时将其移出。如果您的应用是用VB6或经典ASP编写的，那么您可能会手头上有一个重写-但这是另一个问题;-}。

反案

如果我有一个未开发的项目，我通常会推荐最新版本的DBMS平台，因为它为您提供了最长的供应商支持窗口。没有人应该将SQL Server 2000作为新项目的公司标准-EOL太接近了。对于一个新项目，这是迄今为止升级到较新版本的最有力的依据。关于省钱的争论不成立。如果您现在开始使用SQL2000，则该应用程序将在几年内招致不必要的移植费用。

绿地工作的关键点在于，过于保守的选择会在需要升级之前缩短应用程序的使用寿命。通常，人们会出于某种特定原因而拒绝使用当前版本的DBMS平台。

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

坦白说，混合使用各种东西对我来说是很痛苦的，但要使公司中的每个人都出现财务系统问题，然后让财务软件供应商指点我们和当我们寻求帮助时笑着说，问题始于我们在批准SQL 2005之前升级到SQL 2005。

还有很多要说的是，如果它们实际上没有损坏，就不要修复它们。我确实想将我的所有SQL Server都升级到2008年……我确实这样做。但是我还有很多事情要做，实际上可以通过我的经理和用户可以理解和量化的方式改善业务的底线...永远都是第一位的。

您在对Mastermind的答复中提到开发人员不喜欢使用SQL 2000。我怀疑一种处理方法是，如果我决定我“不喜欢”支持SQL 2000，那么老板将对我使用该方法：“谢谢您在这里工作的时间，就在您的左边”。归根结底，不管我们喜不喜欢，我们都会得到报酬以使工作正常。

在我们的案例中，“为什么要继续使用2000”比“升级成本要多少？”少。我们的大多数应用程序都不使用任何需要2005年特定功能的东西，因此没有任何令人信服的理由，而且除非微软停止支持它，否则我们不会这么做。

成本。

较新的软件仍然是附加软件，需要花费额外的钱。

由于使用过时的系统的诸多弊端，这可能是（通常是）虚假的节约，但这是唯一有意义的真正原因。

对于具有5个CAL的一台服务器，SQL Server 2008（标准）的新许可证成本不到2,000美元，而对于1个CPU许可证，新许可证的成本仅为6,000美元。我能听到我的老老板说：“它还没有坏，但是升级那两台服务器要花多少钱？” （当时需要2个双CPU才能获得CPU许可）。

使用SQL2000已经七年了，我在2005年的第一次经验是在VMWare ESX环境中。性能下降（ISP正在提供VMWare专业知识，当我们开始进行负载测试时，我们发现它们不仅存在服务器方面的主要问题，而且影响了我们的体验），并且所有内容都四处移动/更名（旧的企业经理很糟糕）更快）-我们更乐意推迟升级。然后我们在等待2008年的发布，因此我们现在才升级到2008年（或将一些数据迁移到MySQL / PostgresSQL）。

直到去年的某个时候，Microsoft仍在为2000提供主流支持，因此直到最近，我们才有了更具说服力的升级理由。

小型公司也存在资源问题-学习，计划，测试升级需要时间，并且会影响其他运营。如果必须同时升级SQL Server上的其他应用程序，那么这也将变得非常昂贵。

一段时间以来，我们一直在调情转向开源，尽管这有可能也会冻结任何升级。

为什么不升级到sql server 2008，那么由于数据压缩，更容易维护和提高了性能（筛选索引），您实际上可以降低成本吗？最近，我们升级了sql server 2000安装并节省了75％的磁盘空间，并且性能急剧提高。

另一个改进是并发性，这是由于sql server 2005中引入了新的锁定机制。

/霍坎·温瑟（HåkanWinther）

大型组织的风险不利且无知，这导致一些非常愚蠢的决策。当我在2003/2004左右从事Unix工作时，我们陷入了Solaris 2.5.1环境，该环境是在我10年级左右发布的，因为它是“经过验证的”技术，并且升级“过于昂贵”。

PHB经常说得太贵了，因为“我在1000万美元的项目中花了1000美元升级了预算，真是愚蠢”。

就Microsoft Stack软件而言，人们通常是不利于升级的，因为他们不想与公司内部的许可巨魔打交道，而不想从Dell / IBM / etc购买OEM许可，也不想与之打交道。参与升级的官僚圈。

我不赞成（双关语意）“前期成本”的说法，但是不幸的是，许多PHB都对前期成本感到困扰，因此可以接受。

对我来说，唯一令人信服的原因是使用它的应用程序。例如，如果您是SharePoint 2003公司，则无法在不进行SharePoint升级的情况下升级到SQL 2005或2008，这不是一件容易的事。

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

除了兼容性问题（SSIS的DTS对我们来说是最大的问题）之外，我们还对SQL 2005实施了一系列准则/安全性限制，而SQL 2000并没有执行这些准则/限制。（没有dbo用户，仅模式许可，等等。）

在我们的组织中，有几个原因。有些是针对我们的案例的，而有些则更为通用。

1）不兼容。在少数情况下，为SQL2005内部编写的软件在SQL2000上安装时出现问题。我最近看到的这种情况最终是由于在2000年显式声明了不存在的参数，以及系统索引表的名称有所不同。（sys.indexes与sysindexes）

2）培训。我们的开发人员当然知道2005年，并希望在此之前或2008年进行开发。但是，保持一切正常运转的工作落在了NOC上，而不是开发商。在我们的NOC中，没有人接受过任何正式的SQL培训，并且从管理工具的角度来看，两者之间的差异足以将其考虑在内。

3）升级现有产品的成本。对我们来说，这是一个很大的挑战。我不是在这里谈论Microsoft的许可费用。在我们的业务中，对任何现有产品的升级（即使我们没有对现场已有的所有产品进行追溯升级）也将需要通过多个不同的监管和认证测试实验室进行的昂贵且漫长的重新认证过程。我们正在SQL2005上构建新产品，但是由于这个原因而不是升级较旧的产品。

认证过程还意味着我们最终将在新版本中混合使用，根据是否收到批准，某些辖区将使用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上运行。