数据库源代码控制相关讨论

[發糞塗牆]

最近公司服务器有很多代码莫名变更，但是由于技术支持均用一个sql 身份验证登录，所以基本上看不出个啥，为了避免非预期修改带来的影响，搜了一下网上的源代码管控工具，并且也咨询了一些圈内的专家（包括下面文章的作者），其中有这个工具，有人用过没？http://www.cnblogs.com/CareySon/p/3700601.html，或者还有没有其他软件、工具、策略推荐？

补充说明：
公司参加了PCI认证，基于PCI要求，不能使用Windows 身份验证，这个比较扯淡，理由是登录Windows和sqlserver的帐号密码不能用同一个，如果抛开这个要求，强制技术支持使用Windows身份验证的话，找问题比较好。
另外由于初期搭建平台的人没有考虑任何事情（听说是个兼职的人），结果Windows很多不足之处，比如没有加域等。

顺便找个话题5-1散分

[CareySonOnSQL]

引用 29 楼 SQL_Beginner 的回复:

我们以前无论是程序代码还是SQL代码，统一用TFS，跟VS集成的比较好 .NET http://msdn.microsoft.com/en-us/library/fda2bad5(v=vs.100).aspx SQL的源码还是TFS， http://msdn.microsoft.com/en-us/library/aa833246(v=vs.100).aspx

你不会指望每一个DBA或运维人员都使用VS吧?此外SQL代码是如何用TFS管理呢?一个存储过程被修改,如何找到上一个版本的存储过程?

[CareySonOnSQL]

引用 36 楼 sz_haitao 的回复:

[quote=引用 32 楼 DBA_Huangzj 的回复:] [quote=引用 31 楼 sz_haitao 的回复:] [quote=引用 28 楼 DBA_Huangzj 的回复:] [quote=引用 27 楼 sz_haitao 的回复:] 生产环境，只能控制： 专人 才能修改脚本。。。。 版本管理工具帮不上

很多环境毕竟不能理想化，就我一个DBA，我不可能24*7待命。而且公司也设了support应对紧急事情，这种情况下如果有个代码管控，不仅可以找到谁改了，必要时候还能恢复[/quote] 你给他们写一个 维护工具，谁什么时候执行过什么sql，都自动记录下来 你回来再审查 严格规定 他们不能执行登录到服务器操作[/quote]这工作量太大了吧。。。[/quote] 也不难吧，就是 相当于 查询分析器 的执行部分：sql代码编辑框+提交按钮[/quote] 这还不难?都可以成为一个项目来做了.这种事就应该用专门的工具来做

[guguda2008]

这东西怎么说呢。。。我也头疼数据库版本控制问题。 微软官方的解决方案应该是VS管理数据库项目+TFS管理项目版本，但VS这东西对于新人来说培训起来不方便，自己用着也别扭，开一次要半天，还占好多内存。 SVN其实是不错的解决方案，但要配合相应的策略，比如规定更改数据库必须备案，否则有惩罚，不然还是会乱改。 其实版本控制对于数据库层面无非就是脚本管理+历史修改查询，想在脚本执行层面管理可能只能通过你说的那个第三方一样的软件执行，但如果没有相应的制度配合，一样是空的。 总的来说还是提升团队里版本控制概念，加强人员素质最靠谱，想靠上软件倒逼开发模式优化倒逼人员素质不是不可能成功，但我真没见过成功的。。。。

[發糞塗牆]

工具是为了减少工作量，人员的素质当然是很重要，不过即使跨国企业，人员的素质也参差不齐，很难通过“培训”得手段来管控，不然的话安全性也不用那么严格，目前的确是因为没有找到比较有针对性的解决方案，所以才发来看看有没有人有比较好的方法

引用 42 楼 guguda2008 的回复:

这东西怎么说呢。。。我也头疼数据库版本控制问题。 微软官方的解决方案应该是VS管理数据库项目+TFS管理项目版本，但VS这东西对于新人来说培训起来不方便，自己用着也别扭，开一次要半天，还占好多内存。 SVN其实是不错的解决方案，但要配合相应的策略，比如规定更改数据库必须备案，否则有惩罚，不然还是会乱改。 其实版本控制对于数据库层面无非就是脚本管理+历史修改查询，想在脚本执行层面管理可能只能通过你说的那个第三方一样的软件执行，但如果没有相应的制度配合，一样是空的。 总的来说还是提升团队里版本控制概念，加强人员素质最靠谱，想靠上软件倒逼开发模式优化倒逼人员素质不是不可能成功，但我真没见过成功的。。。。

[xusir98]

[魔者侠心之明星级程序员]

引用 40 楼 CareySonOnSQL 的回复:

[quote=引用 29 楼 SQL_Beginner 的回复:] 我们以前无论是程序代码还是SQL代码，统一用TFS，跟VS集成的比较好 .NET http://msdn.microsoft.com/en-us/library/fda2bad5(v=vs.100).aspx SQL的源码还是TFS， http://msdn.microsoft.com/en-us/library/aa833246(v=vs.100).aspx

你不会指望每一个DBA或运维人员都使用VS吧?此外SQL代码是如何用TFS管理呢?一个存储过程被修改,如何找到上一个版本的存储过程?[/quote] 可以建个database project,这个SQL代码跟.NET代码一样可以check in,并且保留历史版本。

[魔者侠心之明星级程序员]

不过TFS应该算比较重量级的，更加适合于.NET项目的生命周期的管理，包括项目管理，团队合作，版本管理，TEST，built,发布等一系列活动，版本管理只是其中的一环而已。

[發糞塗牆]

顶一下。。。。

[haitao]

引用 55 楼 DBA_Huangzj 的回复:

顶一下。。。。

如果 只是要求 1、限制用户直接登录数据库， 2、每次操作的sql都自动有记录 我真的可以在几天内做一个这样的工具： client----------htts----------IIS6--isapi--mssql 用户可以在局域网，也可以在互联网（这时最好用https，IIS6需要对互联网） isapi是通用的，所以也就是现成的，重新编译都不用，只要配置一下IIS和isapi的数据库连接设置（ip、账号、密码） 用户在client里粘贴自己的测试数据库验证过的sql，即可提交给isapi在mssql里执行 事后核查各人提交过的sql，就是查数据库里的几个表而已了 提交记录表：tbSQLlog fid fuser fwhen fsql 可能还需要一个用户表：tbSQLuser fid fuser fpasswordhash

[發糞塗牆]

自己开发当然可以，不过我是不想把问题复杂化而已。

引用 56 楼 sz_haitao 的回复:

[quote=引用 55 楼 DBA_Huangzj 的回复:] 顶一下。。。。

如果 只是要求 1、限制用户直接登录数据库， 2、每次操作的sql都自动有记录 我真的可以在几天内做一个这样的工具： client----------htts----------IIS6--isapi--mssql 用户可以在局域网，也可以在互联网（这时最好用https，IIS6需要对互联网） isapi是通用的，所以也就是现成的，重新编译都不用，只要配置一下IIS和isapi的数据库连接设置（ip、账号、密码） 用户在client里粘贴自己的测试数据库验证过的sql，即可提交给isapi在mssql里执行 事后核查各人提交过的sql，就是查数据库里的几个表而已了 提交记录表：tbSQLlog fid fuser fwhen fsql 可能还需要一个用户表：tbSQLuser fid fuser fpasswordhash[/quote]

[haitao]

也算不上复杂化，只要 用户不要求企业管理器这样的层次对象选择、表设计器。。。。 比我上次做的 数据字典工具，都简单多了 复杂的isapi，因为是通用的，就省掉了开发量的大头 关键是这种模式杜绝了 用久了，惰性回头 的可能：因为用户物理上无法连接数据库了 只有用户的应用和这个isapi可以直连 只是需要一个win2003（内含IIS6），虚拟机也行 事后的核查，就是sql查询了，你是专家，想怎么写就怎么写 我也可以提供一个查询界面，配置常用的查询sql。。。。 如果以后再能多推广几套，再一起分成都好啊。。。。

[發糞塗牆]

主要是我编程能力没你好。推广就算了，我现在没客户

引用 58 楼 sz_haitao 的回复:

也算不上复杂化，只要 用户不要求企业管理器这样的层次对象选择、表设计器。。。。 比我上次做的 数据字典工具，都简单多了 复杂的isapi，因为是通用的，就省掉了开发量的大头 关键是这种模式杜绝了 用久了，惰性回头 的可能：因为用户物理上无法连接数据库了 只有用户的应用和这个isapi可以直连 只是需要一个win2003（内含IIS6），虚拟机也行 事后的核查，就是sql查询了，你是专家，想怎么写就怎么写 我也可以提供一个查询界面，配置常用的查询sql。。。。 如果以后再能多推广几套，再一起分成都好啊。。。。

[haitao]

引用 59 楼 DBA_Huangzj 的回复:

主要是我编程能力没你好。推广就算了，我现在没客户 [quote=引用 58 楼 sz_haitao 的回复:] 也算不上复杂化，只要 用户不要求企业管理器这样的层次对象选择、表设计器。。。。 比我上次做的 数据字典工具，都简单多了 复杂的isapi，因为是通用的，就省掉了开发量的大头 关键是这种模式杜绝了 用久了，惰性回头 的可能：因为用户物理上无法连接数据库了 只有用户的应用和这个isapi可以直连 只是需要一个win2003（内含IIS6），虚拟机也行 事后的核查，就是sql查询了，你是专家，想怎么写就怎么写 我也可以提供一个查询界面，配置常用的查询sql。。。。 如果以后再能多推广几套，再一起分成都好啊。。。。

[/quote] 关键是： 0、需要一个win2003（内含IIS6），虚拟机也行 1、限制用户直接登录数据库（不限制：也可以，而且0也不需要了，但是用户可能会不用这个工具，自己用企业管理器登录） 2、每次操作的sql都自动有记录（没有企业管理器的选择、设计、编辑功能） 编程我来，你只是需要配置一下IIS

[朝露昙花]

支持一下 支持一下。。。

[树影重重]

[YGYMM]

如果你想记录 ，可以为不同的用户分配用户名，在数据库触发器上记录下来 日志 ，就可以读出来。

[發糞塗牆]

引用 63 楼 YGYMM 的回复:

如果你想记录 ，可以为不同的用户分配用户名，在数据库触发器上记录下来 日志 ，就可以读出来。

要是有10个support，也搞10个用户？

[haitao]

引用 60 楼 sz_haitao 的回复:

[quote=引用 59 楼 DBA_Huangzj 的回复:] 主要是我编程能力没你好。推广就算了，我现在没客户 [quote=引用 58 楼 sz_haitao 的回复:] 也算不上复杂化，只要 用户不要求企业管理器这样的层次对象选择、表设计器。。。。 比我上次做的 数据字典工具，都简单多了 复杂的isapi，因为是通用的，就省掉了开发量的大头 关键是这种模式杜绝了 用久了，惰性回头 的可能：因为用户物理上无法连接数据库了 只有用户的应用和这个isapi可以直连 只是需要一个win2003（内含IIS6），虚拟机也行 事后的核查，就是sql查询了，你是专家，想怎么写就怎么写 我也可以提供一个查询界面，配置常用的查询sql。。。。 如果以后再能多推广几套，再一起分成都好啊。。。。

[/quote] 关键是： 0、需要一个win2003（内含IIS6），虚拟机也行 1、限制用户直接登录数据库（不限制：也可以，而且0也不需要了，但是用户可能会不用这个工具，自己用企业管理器登录） 2、每次操作的sql都自动有记录（没有企业管理器的选择、设计、编辑功能） 编程我来，你只是需要配置一下IIS[/quote] 不用iis，用apache（windows下）也行

[starseeker7]

学习一下 目前我们公司采取的策略是划分环境 开发环境用户随便搞 开发环境用户测试好了以后若需要进行下一步 比如测试环境/生产环境需要由邮件提交给 DBA审核+操作 DBA操作的时候使用工具运行用户提交的脚本，工具运行同时会在对应环境获取改动前的对象结构进行脚本备份到本地，并且把具体步骤保存到DBA专用的数据库中（包含运行脚本，备份脚本，DBA操作步骤等信息） 再配合数据库备份，基本不会遇到版本变化想回滚找到不原始版本的情况 因为用户寄送邮件，一个备份 DBA运行一个备份 定期的数据库全备 一个备份 所有的数据库改动都可以通过邮件+DBA本地 得到 这个模式应用了5-6年没有出过大问题，上面说的DBA工具也不难开发，随便参考一下吧 只是DBA人力需要适当增加就是了

[Neo_whl]

跟着学习