代码之家  ›  专栏  ›  技术社区  ›  CesarGon

开发环境的最佳SQL Server设置是什么?

  •  2
  • CesarGon  · 技术社区  · 14 年前

    VisualStudio2008附带了SQLServer2005的开发许可证,但由于我们只针对SQLServer2008进行生产,我认为我们不应该在开发工作站上安装SQLServer2005,对吗?您是否建议跳过捆绑的SQLServer2005,选择SQLServer2008Developer?或者SQL Server 2008 Express?

    非常感谢你的意见。谢谢

    8 回复  |  直到 13 年前
        1
  •  5
  •   Brad Gignac    14 年前

    我将像其他许多答案一样推荐SQLServer2008Express。不过,我会提出另外两项建议:

    • 将数据库模式保持在版本控制中。开发人员将能够轻松地将其他开发人员的模式更新应用到他们机器上运行的开发数据库。每当您签出源代码以确保运行的是最新的DB模式时,都会执行此操作。

    • 在中间添加一个阶段服务器,这正好反映了您的生产环境。

        2
  •  3
  •   gbn    14 年前

    服务器上的SQL Server 2008(服务器版本之一)

    我发现它在SQL Server安全性等方面加强了一些规则,因为您没有在本地“god”模式下运行。然而,我是一名开发人员DBA,因此我对DB开发的看法与更多以客户为中心的开发人员不同。

    我也肯定会端到端使用相同的版本和服务包。坦白说,不这样做是疯狂的。

    • SQL Express在某些方面受到限制,例如CPU、内存、数据库大小等。 如果您正在编写一个查询,您需要确保它将在生产环境中运行在本地无法支持的1000万行上

        3
  •  2
  •   Joel Coehoorn    10 年前

    由于您的生产服务器运行的是Standard Edition,因此我会在本地计算机上选择Sql server Express。我之所以喜欢开发人员版本,是因为开发人员版本具有与企业版相同的功能,因此在开发实验室中很容易构建一些您突然发现自己无法部署的功能,因为该功能是从标准中删除的。

    然后,我还将使用Sql Server标准的暂存服务器,这将尽可能与生产服务器匹配。

        4
  •  1
  •   Amadiere    14 年前

    我还没有发现使用SQLExpress2008进行开发时存在的任何问题,我建议您充分使用它。不过,一定要坚持使用与您的实时系统相同的版本,否则您可能会要求在实时系统上出现无法在测试中复制的小错误。:)

    个人工作站安装是我的首选。如果您有一个作为DB的中央服务器,这意味着作为团队的一部分工作时,对DB进行破坏性更改更为棘手。如果这不是问题,那么中央服务器仍然可以。

        5
  •  1
  •   tloach    14 年前

    如果您可以选择让开发服务器为每个开发人员提供一个单独的模式,那么这可能是最好的选择。始终使您的开发环境尽可能接近您的生产环境,以使bug复制尽可能简单。

        6
  •  0
  •   Remus Rusanu    14 年前

    你们的产品在运行什么?快递、企业、标准?

    如果产品为Express,则开发服务器应为Express;如果产品为非Express,则开发服务器应为Developer。其想法是,在某些功能的可用性方面,版本之间存在差异。您可以在开发中打开页面压缩,并得出结论认为没有数据存储空间问题,但产品运行的是标准版 支持页面压缩。或者您的查询受益于索引视图,但生产运行的是不支持它的标准版。或者相反,您的开发会花费时间和精力来优化development Express服务器上的查询,但produciton正在运行Enterprise,可以使用简单的索引视图来解决此问题。

    此外,您应该考虑在测试/开发中为生产所报告的问题建立RePro方案的必要性。

        7
  •  0
  •   Murph    14 年前

    好的,如果模式 从未

    是的,您仍然需要一个dev服务器上的dev数据库(理想情况下与您的实时系统相匹配)来进行测试和其他qa,很可能还需要一个演示实例来与实时实例配合使用,但我的经验是,每个人都可以更轻松地使用自己的数据库。

        8
  •  0
  •   HLGEM    14 年前

    我认为开发服务器是最好的选择,它的设置与生产服务器完全相同。使用本地数据库往往会产生不必要的问题。首先,它们通常只有一小部分数据,因此程序员可能会编写糟糕的代码,由于超时,这些代码永远不会在prod上运行。其次,我认为很难保持所有本地数据库完全相同,因此可能会出现右手不知道左手在做什么的问题。第三,有时环境本身会产生问题,但在本地框中编写代码时,只有在移动到prod服务器时才会遇到这些问题,而此时发现这些问题的时机非常糟糕。