【问题标题】:Looking for alternatives to the database project寻找数据库项目的替代品
【发布时间】:2010-05-27 13:33:20
【问题描述】:

我有一个相当大的数据库项目,其中包含九个数据库和一个具有相当大架构的数据库。

这个项目需要大量时间来构建,我正要拔掉头发。我们希望控制我们的数据库源代码,但很难让其他开发人员在签入之前使用该项目并构建数据库项目,因为构建需要很长时间。

这严重削弱了我们的工作,所以我正在寻找替代方案。也许可以用 Redgate 的 SQL 比较来做些什么?我认为这里唯一的缺点可能是它不验证语法?任何人的想法/建议将不胜感激。

【问题讨论】:

  • 为什么要控制您的数据库源?这听起来很愚蠢
  • 不幸的是,应用程序与数据库紧密耦合
  • 您能否进一步解释一下情况?它是否涉及保持不同的数据库同步?什么具体原因阻止数据库不包含在 SC 中?
  • 从开发 => 集成 => 预生产 => 生产时,我们需要一个可重复的提升过程。向上迁移更改依赖于签入源代码控制并合并到各自分支的更改。验证和部署过程需要很长时间才能完成。
  • 哦,我明白了,对,我现在就写下我的答案。

标签: visual-studio visual-studio-2008 database-project


【解决方案1】:

请考虑尝试使用 SQL 源代码控制,这是一款旨在与 SQL 比较一起作为数据库开发生命周期的一部分的产品。它目前处于 Beta 阶段,但功能齐全,并且非常接近完整版本。

http://www.red-gate.com/products/SQL_Source_Control/index.htm

我们很想知道与 Visual Studio 构建当前数据库项目所需的时间相比,它在提交时的表现如何。你真的需要在 VS 中如此频繁地构建项目以至于这是一个问题吗?您的架构有多大,平均构建需要多长时间?

【讨论】:

  • 构建需要 20 分钟,在配备 SSD 的计算机上更快。现在在 Visual Studio 2010 上测试了 10 分钟; Visual Studio 2010 中带有 SSD 的计算机现在只需不到 5 分钟。进入源代码控制的数据库项目是 16 兆。
  • 我很高兴尝试这个,但是我需要由我的团队来运行它。
  • 我们很高兴为您提供与您的团队一起进行试点所需的一切。您的数据库听起来肯定会按照它的步伐放置任何产品!请通过 Red-Gate dot com 的 David dot Atkinson 联系我。
  • 仅供参考 - SQL 源代码控制 1.0 现已发布! red-gate.com/products/SQL_Source_Control/index.htm
  • 这个产品似乎被误解了,为什么要将数据库直接与源代码控制相结合?为什么不简单地允许为文件系统生成脚本并让这些文件像任何其他源代码一样被检入源代码控制?我相信数据库工具应该简单地帮助管理对这些脚本的更改,并允许对数据库进行版本控制并允许生成脚本以在不同版本之间转换数据库。它不需要知道您的源代码控制存储库的详细信息
【解决方案2】:

保持开发/实时数据库同步:

可能有很多方法可以做到这一点,我相信其他用户会进一步扩展(包括软件解决方案)。

就我而言,我使用了两种方法:

(a) 运行脚本以获取 db(存储过程、表、字段等)之间的差异

(b) 严格记录数据库更改(不是数据更改)

就我而言,随着时间的推移,我已经建立了一个半结构化的日志:

Client_Details                  [Alter][Table][New Field]
{
    EnforcePasswordChange;
}

Users                       [Alter][Table][New Field]
{
    PasswordLastUpdated;
}

P_User_GetUserPasswordEnforcement           [New][Stored Procedure]
P_User_UpdateNewPassword                [New][Stored Procedure]
P_User_GetCurrentPassword               [New][Stored Procedure]
P_Doc_BulkDeArchive                     [New][Stored Procedure]

忽略tabing,markdown把它搞砸了。

但你明白了一般要点。

我发现 99% 的时间日志都是我所需要的。

【讨论】:

  • 没有手册,我已经提到了软件解决方案。但我是按照 KISS 的工程原理操作的。
  • 只是补充一点,日志总是以严格的方式命名为:[项目名称] - [构建/发布版本]。我正在同时处理 3 个以上的大型项目。如果没有这些日志,就很难跟踪所有更改。这只是一个习惯问题,我总是打开 mu 日志文件(我正在处理的项目),每次我进行更改时,我都会记录它。它不是那么难。当涉及到预生产时,只需遵循日志即可。搬家也是一样。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-06-21
  • 2015-05-21
  • 1970-01-01
  • 1970-01-01
  • 2019-05-23
  • 1970-01-01
相关资源
最近更新 更多