我们是一个使用Visual Studio 2008进行开发并在生产服务器中使用SQL Server 2008 Standard的小团队。我们正在建立一个新的开发实验室，我想知道SQL Server版本/版本和配置。
Visual Studio 2008附带了SQL Server 2005的开发许可证，但由于我们只针对SQL Server 2008进行生产，我认为我们不应该在开发工作站上安装SQL Server 2005，对吧？您是否建议跳过捆绑的SQL Server 2005，或者转向SQL Server 2008 Developer？或者可能是SQL Server 2008 Express？
或者您是否建议不在开发工作站上安装SQL Server，并针对开发服务器进行所有开发？
您的意见表示赞赏。谢谢！
答案 0 :(得分：5)
我将像许多其他答案一样推荐SQL Server 2008 Express。不过，我会另外提出两项建议：
将数据库架构保持在版本控制中。开发人员将能够轻松地将其他开发人员的架构更新应用于其计算机上运行的开发数据库。只要您检查源代码以确保运行最新的数据库架构，就可以完成此操作。
在中间添加一个与您的生产环境完全相同的临时服务器。
答案 1 :(得分：3)
服务器上的SQL Server 2008（服务器版本之一）
我发现它在SQL Server安全性等中强制执行某些规则，因为您没有在本地“上帝”模式下运行。但是，我是开发人员DBA，所以我对更多以客户为中心的开发人员的数据库开发有不同的看法。
我也肯定会在端到端使用相同的版本和服务包。坦白说，这不是疯了。
编辑：
SQL Express在某些方面受到限制，例如CPU，内存，数据库大小等。 如果您正在编写查询，则需要确保它将在生产中运行1000万行，而您无法在本地支持
非prod服务器端SQL Server安装可能很便宜，取决于您的许可模式。开发人员版的优势在于它可以在客户端操作系统上运行：我已经改变了第一行。
答案 2 :(得分：2)
由于您的生产服务器正在运行Standard Edition，我会在本地计算机上选择Sql Server Express。我更喜欢开发人员版本的原因是开发人员版本具有与企业版相同的功能，因此很容易在开发实验室中构建一些您突然发现自己无法部署的东西，因为该功能已从标准版中删除。
然后，我还将使用Sql Server Standard的临时服务器，它将尽可能地匹配您的生产服务器。
答案 3 :(得分：1)
我还没有发现使用SQL Express 2008进行开发的任何问题，并会完全推荐。绝对坚持使用与您的实时系统相同的版本，或者您可能会要求在实时中出现无法在测试时复制的错误。 ：）
个人工作站安装是我的首选。如果您有一个中央服务器作为数据库，这意味着当作为团队的一部分工作时，对数据库的重大更改变得更加棘手。如果这不是问题 - 那么中央服务器仍然可以。
答案 4 :(得分：1)
如果您可以选择让开发服务器为每个开发人员提供单独的架构，那么这可能是最佳选择。始终保持您的开发环境尽可能贴近您的生产环境，以尽可能简化错误再现。
答案 5 :(得分：0)
您的生产运行情况如何？表达，企业，标准？
如果生产是Express，则开发服务器应为Express，如果生产是非Express，则应为Developer。我们的想法是，在某些功能的可用性方面，版本之间存在差异。例如。您可以在开发中打开PAGE压缩并得出结论没有数据存储空间问题，但是生产运行的标准版不支持页面压缩。或者您的查询受益于索引视图，但生产版本再次运行标准版，但不支持它。或者相反，您的开发花费时间和精力来优化开发Express服务器上的查询，但是生产正在运行Enterprise，并且可以使用简单的索引视图来解决问题。
Express与其他版本之间存在最大差异。您最终需要的是，主要取决于您开发的产品类型以及您将在产品中利用的功能类型。
此外，您应该考虑在测试/开发中为生产报告的问题设置repro方案。
答案 6 :(得分：0)
每个开发者一个。如果没有其他原因，请确保您的架构管理有效（我们这样做是我的团队每个开发人员不会成为问题的原因之一）。
好的，如果架构从不更改，或者开发人员从不负责更改架构，那么中央服务器可能会起作用。提供它们然后不会破坏内容，因为它们没有完全正确地改变...不是因为他们想要回滚数据库并再试一次它是什么？
是的，您仍然需要一个开发服务器上的开发数据库（理想情况下与您的实时系统相匹配）以进行测试和其他qa，并且很可能是一个演示实例来配合实时实例但我的经验，因为它的价值很小，是因为他们自己的数据库让每个人的生活更轻松。
答案 7 :(得分：0)
我认为开发服务器是可行的，其中一个设置与生产服务器完全相同。使用本地数据库往往会产生不必要的问题首先，它们通常只有一小部分数据，因此程序员可能会编写错误的代码，这些代码由于超时而永远不会在prod上运行。其次，我认为保持所有本地数据库完全相同是很困难的，因此你可能会遇到右手不知道左手在做什么的问题。第三，有时环境本身会产生问题，但是在本地盒子上编写代码，当你移动到prod服务器时，你只会遇到这些问题，这是一个非常糟糕的时间来找到它们。