我觉得我的商店有一个漏洞,因为我们没有一个可靠的流程来版本化我们的数据库模式更改.我们做了很多备份,所以我们或多或少都被覆盖了,但以这种方式依赖你的最后一道防线是不好的做法.
令人惊讶的是,这似乎是一个共同点.我说过的很多商店都忽略了这个问题,因为他们的数据库并没有经常改变,而且他们基本上只是努力做到细致.
但是,我知道这个故事是怎么回事.事情排列错误只是一个时间问题而且缺少某些东西.
对此有什么最佳做法吗？有哪些策略对你有用？
版本控制数据库对象的最佳方法是什么？我正在使用Visual Studio 2005/2008和SQL server 2005.我更喜欢可以与SVN一起使用的解决方案.
svn sql-server version-control stored-procedures visual-studio
我正在寻找一种方法来进行日常部署并使数据库脚本与发布保持一致.
目前,我们有一个相当不错的部署源代码的方式,我们有单位代码覆盖,持续集成和回滚程序.
问题是使数据库脚本与发布保持一致.每个人似乎都尝试在测试数据库上运行脚本,然后在实时运行它们,当ORM映射更新(即更改生效)时,它会选择新列.
第一个问题是没有任何脚本可以写在任何地方,通常每个人都"尝试"将它们放入Subversion文件夹,但是一些懒惰的人只是在现场运行脚本,大多数时候没人知道谁做了什么到数据库.
第二个问题是我们有4个测试数据库,它们总是脱节,真正排列它们的唯一方法是从实时数据库进行恢复.
我非常相信,这样的流程需要简单,直接且易于使用,以帮助开发人员,而不是阻碍他们.
我正在寻找的技术/想法使开发人员想要记录他们的数据库脚本很容易,因此它们可以作为发布过程的一部分运行.开发人员希望遵循的流程.
任何故事,用例甚至链接都会有所帮助.
我想将我的MS SQL Server 2005存储过程自动保存到.sql文件(更喜欢我可以通过.bat调用的工具)所以我不必手动点击每个sproc并保存它.
我已经从devio IT中找到了SMOscript,但它收集了所有需要一些时间的表和sproc.有没有类似的工具,我可以定义哪些sproc(s)导出？此外,我错过了USE子句,其中SMOScript不会添加到导出文件,与手动导出为CREATE的脚本sproc相反.
最好的问候肖恩