你如何处理像SQL Server 2008这样的软件升级？

Question

我只是问这个因为我发现随着年龄的增长，我的工作变得更加令人沮丧。

您如何处理新版本的软件，特别是编码员和DBA定期使用的软件？看来，当我充实SQL2005时，SQL2008将会出现并且SQL2010将会在这里。我错过了整个迭代，这对编码员和DBA来说并不是特有的。

我只是为了升级而永远不会升级所以除非那里有强大的功能，否则我倾向于放手。但不知怎的，随着软件版本变得越来越频繁，我不禁觉得这是错误的做法。

编辑添加：
我想我所说的部分内容是新版本的发布几乎没有足够的时间成为以前版本的专家。

Answer 1

这些升级很少需要重新学习。实际上，我几乎会争辩说，重新学习的数量与发布之间的时间量成正比。所以SQL Server 2000到2005年是5年，并且发生了很大的变化。 2005年至2008年，变化不大。 2008年到2010年，我猜不会有太多需要学习的东西。我认为诀窍是要掌握最重要的事情。因为如果你退回几个版本，赶上事情可能是一场噩梦。即使您只是玩它并且不在实际项目中使用它，您可能比许多人更进一步。

Answer 2

对于需要稳定的基于服务器的软件，点击“每个版本”并不是一件好事。您从新版本中获得的唯一好处是新功能（如果您不需要它们，则不需要考虑）并找到现在的所有不兼容性发布（除了下一版本中包含的内容之外）。

出于这个原因，我们仍然在我们的主要产品上支持SQL 2000。我们已经在2005年和2008年对其进行了移植和测试......但我们不使用这些新功能。太多的客户仍在运行2000.我们终于打算在2010年推出时削减对2000的支持，因为10年似乎是一个合理的时期，所以我们最新的（不是一般发布，但与一些客户一起使用）版本使用了一些2005功能

就我们的开发环境而言，我们确实在每次发布后大约一年（当第一批服务包退出时）进入2005年和2008年。那是因为客户端不在那里的跑步机上，所以我们更积极。 2005年和2008年的功能也很引人注目（我不使用Linq to SQL，但我喜欢 Linq to Objects）。我们还在较新版本的软件上进行了大量的原型设计，并将我们的内部项目保留在更新的软件上，以跟上规划和学习的技术特性。

就成为专家而言，我认为在所涉及的技术范围内，没有人是整个产品的专家。如果您了解查询优化引擎以及如何从中获取最后一点性能，那么您就不太可能在复制引擎上花费大量时间。就个人而言，我认为你应该对所有事情进行抽样，但最终你必须开始工作：你的工作很少需要你成为一切的专家。只要知道这些功能就足以让你需要它们的那一天......你可以快速获得一项新技能并继续前进。