我们正在研究用新硬件和较新版本替换 Windows2003（32 位）上现有的 SQL2000 服务器。
我们正在研究一款至少需要 SQL2005 但也可以在 SQL2008 上运行的应用程序。我们的其他数据库也应该可以在其中任一版本上运行。
有人对这两个版本有过好的或坏的体验吗？
我们可能获得的硬件将是 64 位的，因此运行 SQL2008 64 位也是一个选择。
谢谢
答案1
它们都十分可靠。如果可以选择，请直接使用 SQL Server 2008 - 每个版本都有改进，即使您是那种喜欢等到服务包发布后再安装应用程序的人，SQL Server 2008 SP1 也已经发布一个多月了。
这里是 SQL Server 2008 中新功能的目录。每个版本中都固有（但更难发现）对存储引擎的改进，这些改进使 SQL Server 能够更优化、更可靠地运行。
答案2
你应该将数据库从 SQL2000 转移到 2005 或 2008 没有任何问题，但您需要在实时环境中执行此操作之前对应用程序进行适当的测试（以防万一）。
我还没有使用过 SQL2008，但我们已经将许多数据库从 2000 迁移到 2005，旧应用程序中的一些代码只出现了一个小问题。该问题是由于该项目中某些视图的定义/调用方式造成的。如果视图定义了类似“SELECT [somefield]=NULL, [and], [the], [rest] FROM [sometable]”的字段，则运行“SELECT * FROM [theview] WHERE [somefield]='value'”的应用程序有时会在 SQL2005 中（但并非在所有情况下）导致 varchar 到 int 的转换错误，而在 SQL2000 中从未出现过这种情况。简单的解决方案是将视图更改为 [somefield]=CAST(NULL AS NVARCHAR)。您可能不会遇到这个特定问题，我们也没有遇到其他问题，但它证明了这一点你需要做一个满的在转向实时服务之前，在开发/测试环境中进行应用程序测试。
我们已经将数据库从 32 位 SQL2005 移动到 64 位 SQL2005 服务器，没有任何问题，并且我期望从 64 位迁移回 32 位也同样有效。
请注意，一旦移动到 SQL2005，将数据库移回 SQL2000 会非常麻烦，因此我要强调的是确保在迁移自己的应用程序之前进行彻底测试. 还要确保从任何涉及的外部供应商处获得明确的书面说明，说明他们的数据库/代码已经针对您选择的 SQL Server 版本进行了测试。
编辑：另一个相关点：我们以这种方式移动的应用程序不使用额外的服务，如全文索引，报告服务等 - 仅使用主 SQL 数据库服务 - 因此我无法评论使用这些额外功能的应用程序是否可以顺利迁移。
答案3
与您的应用程序供应商沟通。如果他们不能告诉您，我会在 SQL Server 2008 上进行试点测试，看看它是否有效。很有可能它会成功。（并且对您的供应商说一些难听的话，因为他们不知道他们的应用程序可以在哪些平台上运行。）
答案4
您应该运行 sql 2008 64 位。如果应用程序支持 2008，您应该使用最新版本。请注意，您不能购买 2005，您可以购买 2008 并降级，或者购买 2008 并使用它。