相关疑难解决方法(0)

关于数据库对象是否应该受版本控制的SO社区wiki已经有一些讨论.但是,我没有看到很多关于为数据库对象创建构建自动化过程的最佳实践的讨论.

这对我的团队来说是一个有争议的讨论点 - 特别是在评估数据库部署自动化方法的优势和风险时,开发人员和DBA通常有不同的目标,方法和关注点.

我想听听SO社区关于哪些实践在现实世界中有效的一些想法.

我意识到这有点主观,哪些实践真的是最好的,但我认为一个关于哪些工作可能对许多人有帮助的良好对话.

以下是我在此主题中关注领域的一些预告片问题.这些并不是一个明确的清单 - 而是人们帮助理解我正在寻找的东西的起点.

1. 测试和生产环境都应该从源代码控制构建吗？
   
   • 是应该使用自动化构建 - 还是应该通过从稳定的,最终的测试环境中复制对象来构建生产？
   • 您如何处理部署脚本中测试和生产环境之间的潜在差异？
   • 您如何测试部署脚本是否可以像测试一样有效地对抗生产？
2. 哪些类型的对象应该受版本控制？
   • 只是代码(程序,包,触发器,java等)？
   • 指标？
   • 约束？
   • 表定义？
   • 表更改脚本？(例如,ALTER脚本)
   • 一切？
3. 哪些类型的对象不应该受版本控制？
   • 序列？
   • 资助？
   • 用户帐户？
4. 如何在SCM存储库中组织数据库对象？
   • 你如何处理转换脚本或ALTER脚本之类的一次性事务？
   • 你如何处理退出数据库中的对象？
   • 谁应该负责将对象从开发推广到测试级别？
   • 如何协调来自多个开发人员的更改？
   • 您如何处理多个系统使用的数据库对象的分支？
5. 如果有的话,可以合理地对这个过程做出哪些例外？
   • 安全问题？
   • 具有去识别问题的数据？
   • 脚本无法完全自动化？
6. 如何使流程具有弹性和可执行性？
   • 开发者错误？
   • 出乎意料的环境问题？
   • 用于灾难恢复？
7. 您如何让决策者相信DB-SCM的好处真正证明了成本的合理性？
   • 传闻？
   • 行业研究？
   • 行业最佳实践建议？
   • 向公认的当局上诉？
   • 成本效益分析？
8. 谁应该在这个模型中"拥有"数据库对象？
   • 开发商？
   • 数据库管理员？
   • 数据分析师？
   • 超过一个？

我正在尝试使用SQL Server数据库项目来保留我们所有的表,存储过程,视图等脚本.我现在想要能够保留所有参考(或静态)数据.当工具或项目运行时,它将安装所有数据库对象并插入所有参考数据.

我在vs 2010中找到了类似的文章,但他们使用的是Team Edition for Database专业人员.

• 让我们的数据库受源代码控制.
• 将本地开发DB与源代码管理中的最新版本同步.
• 使用Visual Studio 2012和SQL Server 2012
• 尽可能使用.Net工具,而不是像Redgate那样(Redgate很棒,但是如果我可以在VS 2012中使用工具的话我还不想要它)

我一直在使用SQL Server项目来管理数据库的结构.

首先我创建了项目,然后导入了一个数据库.

然后,当我需要进行模式更改时,请更改字段名称,我在SQL Server项目中执行,然后使用模式比较选项将其发布到实际数据库.

我想更进一步,以保存数据库所需的基本数据.例如,一个OrderType包含2条记录"PHONE","WEB" 的表格

数据库的所有新实例都需要此数据.有没有办法将这些保留在SQL Server项目中,以便它们不会丢失？

现在看来,唯一的方法是保留master数据库的实际副本及其中的元数据,然后使用数据比较.但是,如果数据可以与模式同时发布,那么结果数据库就完成了,那就太棒了.