针对视图的增删改操作。

木易随风 2012-12-11 09:28:56
一个软件使用两个数据库A和B,软件直接连接到B库,然后在B库里创建与A库里的表格同名的视图,软件连接B库后对这些视图的数据进行增删改,软件中的脚本不直接连接A库,这样操作有没有什么缺点不?

只有这点分了。
...全文
295 13 打赏 收藏 转发到动态 举报
写回复
用AI写文章
13 条回复
切换为时间正序
请发表友善的回复…
发表回复
木易随风 2012-12-21
  • 打赏
  • 举报
回复
引用 12 楼 DBA_Huangzj 的回复:
需要手工在各个库执行,不过我们公司开发了一个批量工具,所以没有问题,但是由于是内部的,我也不方便给你,你看看有没有第三方软件
嗯,谢谢啦,我暂时先写了一个存储过程来组织这些语句,然后去调用其他数据库中的存储过程去执行。 结贴啦。
發糞塗牆 2012-12-18
  • 打赏
  • 举报
回复
需要手工在各个库执行,不过我们公司开发了一个批量工具,所以没有问题,但是由于是内部的,我也不方便给你,你看看有没有第三方软件
木易随风 2012-12-18
  • 打赏
  • 举报
回复
引用 10 楼 DBA_Huangzj 的回复:
这部分最好借用源代码管理工具,如tfs、sourcesafe等来产生差异变更脚本,然后向需要执行的数据库执行即可。
产生差异变更脚本后,是需要手工在各个库中执行,还是源代码管理工具就可以直接自动执行了呢?
IEEE_China 2012-12-11
  • 打赏
  • 举报
回复
引用 5 楼 shuchong1983 的回复:
这些视图都是单表的,不会有条件和表连接。
视图都是单表的话,应该是可以的。 修改视图有很多限制,比如只能引用基表的列,不可以是聚合函数生成的列,不能是计算列等,详细的资料查msdn吧。
木易随风 2012-12-11
  • 打赏
  • 举报
回复
引用 4 楼 rfq 的回复:
为什么要这么做,为了安全和权限,应当可以但是 对试图的修改,有好多的限制。
这些视图都是单表的,不会有条件和表连接。
rfq 2012-12-11
  • 打赏
  • 举报
回复
为什么要这么做,为了安全和权限,应当可以但是 对试图的修改,有好多的限制。
木易随风 2012-12-11
  • 打赏
  • 举报
回复
因为我这A库的结构在多个项目中使用,不同的项目会有不同的B库,如果都把A库的表在B库再建立一遍,不方便日后的A库升级。
IEEE_China 2012-12-11
  • 打赏
  • 举报
回复
这样多麻烦。。。, 表多了,后期维护挺麻烦的。。。 你还不如c/s,客户端提要求,服务端去操作。
zjl8008 2012-12-11
  • 打赏
  • 举报
回复
创意不错,没用过,可能需要启用服务器的分布事务功能吧?如ms dtc服务必须要启动
發糞塗牆 2012-12-11
  • 打赏
  • 举报
回复
这部分最好借用源代码管理工具,如tfs、sourcesafe等来产生差异变更脚本,然后向需要执行的数据库执行即可。
木易随风 2012-12-11
  • 打赏
  • 举报
回复
引用 8 楼 DBA_Huangzj 的回复:
有点大材小用了,数据库不是用来做视图用的。感觉B库都像一个源代码管理工具一样了。是挺有创意的,但是我找不到理由来支持你的观点。我反而觉得你应该多从程序、数据库权限、t-sql编写逻辑上去着手,控制好业务流程及处理逻辑。这才是保证的关键。
因为所有的软件项目都是用一个框架,框架使用的数据结构放到A库,其他的软件项目都是单独的数据库,如果把框架的结构放到其他项目数据库里,那框架发生改变时,得更新所有的项目数据库,这样更新不太方便。所以想到了,将框架数据库中的表在项目数据库中建立对应的视图。
發糞塗牆 2012-12-11
  • 打赏
  • 举报
回复
有点大材小用了,数据库不是用来做视图用的。感觉B库都像一个源代码管理工具一样了。是挺有创意的,但是我找不到理由来支持你的观点。我反而觉得你应该多从程序、数据库权限、t-sql编写逻辑上去着手,控制好业务流程及处理逻辑。这才是保证的关键。
gogodiy 2012-12-11
  • 打赏
  • 举报
回复
你这样做,安全性很高,但是牺牲了系统的灵活性及可扩展性,后期维护更麻烦。这个要根据实际情况来取舍了。

34,594

社区成员

发帖
与我相关
我的任务
社区描述
MS-SQL Server相关内容讨论专区
社区管理员
  • 基础类社区
  • 二月十六
  • 卖水果的net
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧