如何开发、测试、版本、同步SQL Server 2000、2005、2008、2008R2数据库?

发布于 2024-10-01 06:42:21 字数 1535 浏览 2 评论 0原文

开发车间拥有一系列使用 SQL Server 2000、2005、2008、2008 R2 数据库的 ASP.NET 项目。

您将如何设计、开发、维护、版本控制、填充测试数据、压力负载、测试、自动化、与生产保持同步等一系列数据库?
最近的 Visual Studio 2010 Ultimate 或 Database Eds 是否支持 SQL Server 2000 数据库?

更新:问题不限于 VS2010,甚至不限于仅 MS 的产品。
即使受限,那么如何组织发展的基础设施和环境。

此外,还应考虑削减某些功能的变体,以最小化/削减或优化时间和费用。

到目前为止我正在阅读它(带有子链接和相关链接):

A development shop has a range of ASP.NET projects using SQL Server 2000, 2005, 2008. 2008 R2 databases.

How would you design, develop, maintain, version control, fill with test data, stress load, test, automate, maintain in sync with production such range of databases?
Does recent Visual Studio 2010 Ultimate or Database Eds support SQL Server 2000 databases?

Update: The question is not confined to VS2010 or even to MS-only products.
Even if confined, then how to organize the development infrastucture and environment.

Also, variants of cutting some of the functionalities in order to minimize/cut or optimize time and expenses are to be considered.

I was reading so far on it (with sublinks and related links):

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

花落人断肠 2024-10-08 06:42:21

我建议您针对最低公分母(即 SQL 2000 数据库)进行开发。

然后,您可以将此数据库备份并还原到测试和临时环境中的其他版本的 SQL Server,从而为您提供所需的数据库服务器范围。

I suggest you develop against the lowest common denominator (i.e. the SQL 2000 database).

You can then backup and restore this database to the other version of SQL Server in your testing and staging environments to give you the range of database servers you need.

哎呦我呸! 2024-10-08 06:42:21

首先让您的开发人员在他们的计算机上加载所有三个版本的客户端工具。你必须从2000年开始锻炼才能正确工作。然后让它们在支持 2000 的项目的查询分析器中工作,并在支持 2005 或 2008 的项目的 SSMS 中工作。坚持它们始终仅针对客户端将使用的数据库的最低版本工作。大多数在 2000 年有效的功能在 2008 年也将有效(下一个版本则不然,因此应强烈鼓励 2000 年的客户升级。)

让他们在脚本中完成所有工作(甚至数据库更改和插入查找类型表),并且就像任何其他代码一样,将脚本检查到源代码管理中。

如果您有测试人员,请确保他们连接到正确版本的数据库,并且他们针对该版本而不是更高版本进行测试。

我还会为您的开发人员制作一份备忘单,说明哪些 T-SQL 代码适用于哪个版本。最好的方法是查看 2005 年和 2008 年的联机丛书,了解添加了哪些新功能。

但至关重要的是,它们只能在特定项目支持的数据库中工作,否则当它投入生产时,您将不得不重写大量代码。较新的开发人员不知道 2000,并且习惯于使用不受支持的 CTE 之类的东西。最好的是,当他们编写代码时,他们立即发现它在测试中无法工作,或者在生产环境中更糟。

First have your developers load client tools of all three versions on their machines. You have to start from 2000 and work out to work correctly. Then have them work in Query Analyzer for projects supporting 2000 and in SSMS for projects supporting 2005 or 2008. Insist that they always work only against the lowest version of the database the client will be using. Most things that work in 2000 will work in 2008 (not so true of the next version, so customers on 2000 should strongly be encouraged to upgrade.)

Have them do all work in scripts (even database changes and inserts to lookup type tables) and check the scripts into source control just like any other code.

If you have testers, make sure they are connected to the correct version of the database and that they do tests against that and not some higher version.

I also would have a cheat sheet made up for your developers concerning what T-SQL code will work on which version. Best way to do this is to look in Books Online for 2005 and 2008 to see what new features were added.

But it is critical that they only work in the database the particular project will support or you will have to rewrite large swaths of code when it goes to prod. Newer devs don't know 2000 and are used to using things like CTEs that are not supported. It is best they find out immediately when they write the code that it won't work not in test or worse on prod.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文