我们的项目有大约20名开发人员,但我们的应用程序对数据库的使用相对较少。我们有一个大约5个数据库的集合,所有这些数据库都非常小,每个数据库的数量少于20个,其中没有数百个行或任何大的数据库。
我们在表格中有两个选项可用于管理数据库随时间的演变:
第二个选项似乎被广泛使用,我在这里找到了一个深入的讨论:http://odetocode.com/blogs/scott/archive/2008/01/31/versioning-databases-the-baseline.aspx
我们目前遇到的问题是我们无权访问我们的生产数据库。这意味着要创建一个发布包,我们必须将Production的备份还原到另一个位置,针对该引用数据库生成差异并将脚本提供给生产数据库团队。因此,我们的生产版本与我们的其他环境不同。
这使得运行版本化脚本的想法很吸引人,因为我们在所有环境中使用相同的脚本,并且在部署中没有临时工作(例如,手动恢复prod到参考DB)。但鉴于我们有这么小规模的数据库情况,我觉得我们几乎不可能成为数据库工具的困难案例。我们想要的是尽可能简单易懂的东西。
RedGate套件等工具是否适用于这种情况,还是应该使用版本化脚本?成本并不是一个问题,它更多的是创建一个成功的坑,维护和部署数据库是尽可能基本和自动化。
答案 0 :(得分:3)
根据我的经验,它总是比模式更改更多。如果将列拆分为两个,或将列移动到单独的表或其他类似的东西,则需要同时迁移模式和数据。
任何工具或脚本都不允许您自动迁移实际数据。在最大程度上,您将获得架构的差异,您的开发人员可能会发现这些架构可用作数据库版本迁移脚本的提醒/检查列表(在单个事务中完成create / alter / drop和insert / update / delete序列) 。
答案 1 :(得分:3)
我是Red Gate for SQL Compare的产品经理,它在两个数据库之间生成差异脚本。我希望您看看我们的SQL源代码控制工具,它允许您在开发过程中跟踪架构更改。在部署时,如果您知道正在生产哪个架构版本,则可以从源控制版本生成部署脚本。当然,在运行生产之前,您应该始终在暂存环境中对其进行测试。
Scott的文章在迁移脚本方面提出了一个很好的观点,Denis提到了更复杂的更改,这些更改实际上无法通过比较工具进行二次猜测,因此需要对自定义迁移脚本进行适当的管理和使用。因此,下一版本的SQL Compare与SQL Source Control将管理您的模式版本和您的迁移脚本,从而使您可以充分利用这两个世界。如果你想看到这个的早期截图,请发送电子邮件给我在red-gate dot com的David dot Atkinson。我真的很想讨论你的要求,所以我们可以更好地设计这个工具。
答案 2 :(得分:0)
迁移时,您需要编写数据库,数据库对象,数据库权限,服务器登录,服务器权限,sql作业,sql邮件配置文件的脚本, 链接服务器。 下面的power shell脚本将帮助你获得它。在运行power shell脚本之前,请仔细阅读说明。
https://gallery.technet.microsoft.com/SCRIPTING-DB-DB-OBJECTS-DB-81bba072