DBA提交脚步规范

工作中需要走脚步流程,申请修改数据库,总结一些常用的语句:)

提交时注明为DDL/DML_需求号_日期(各公司标准不一样)
//修改字段长度使用;
alter table t_task modify task_no varchar2(2000);

//修改字段名称
alter table t_task rename column task_no_bak to task_no;

//修改字段类型, 先新建备份字段 , 然后复制字段信息, 删除原字段
a.alter table t_task add (TASK_NAME_BAK VARCHAR2(2000));
b.update t_task set TASK_NAME_BAK = TASK_NAME;
c.alter table t_task drop column TASK_NAME;
d.alter table t_task rename column TASK_NAME_BAK to TASK_NAME;

//表字段注释
comment on column VERSION_OPR.T_OPERATED_DATA_LOG.OPERATED_SQL is ‘执行操作的sql语句‘;
 
//授权表 及 创建同义词 , 创建同义词为谁使用,谁创建
grant select,insert,update ON t_task to TP_TASK_USER;  //授权表
grant select on SEQ_OPERATED_DATA_LOG_ID to TP_TASK_USER;  //授权序列
create or replace synonym T_OPERATED_DATA_LOG for TASK_USER.T_OPERATED_DATA_LOG;  //创建同义词
create or replace synonym SEQ_OPERATED_DATA_LOG_ID for TASK_USER.SEQ_OPERATED_DATA_LOG_ID;  //创建同义词

//创建备份表, 适用:需要update多个字段
create table test01_bak_20161204 as select * from test01 where name in (‘KK‘,‘CC‘,‘HH‘);//创建备份表
comment on table test01_bak_20161204 is ‘test01备份表,16年12月度可删除‘;
UPDATE test01 t SET t.NAME = ‘cc‘ WHERE EXISTS (select 1 from test01_bak tb where tb.id = t.id) ; //适用备份表更新数据

时间: 2024-11-25 08:31:27

DBA提交脚步规范的相关文章

Git提交代码规范

Commit message 的格式 Git 每次提交代码,都要写 Commit message(提交说明),否则就不允许提交. 用commit message最好是能有规范和工具的约束. 每次提交,Commit message 都包括三个部分:header,body 和 footer. 其中,header 是必需的,body 和 footer 可以省略.不管是哪一个部分,任何一行都不得超过72个字符(或100个字符).这是为了避免自动换行影响美观. <type>(<scope>)

Git 代码提交说明规范模版

1.在根目录建立模板文件 如 xxx_template文件,其内容如下: Title: Function Or Bug: Detail: 2.设置模板,命令如下 git config commit.template   [模板文件名]    //这个命令只能设置当前分支的提交模板 git config  --global commit.template   [模板文件名]    //这个命令能设置全局的提交模板,注意global前面是两杠 例如: git config commit.templa

前台提交数据规范

一.单一字段: 表单: name[0] = 'XX' name[1] = 'XX' ... json: name:[ 'XX', 'XX', ... ] 二.多个字段: 表单: group[0][id] = 'XX' group[0][name] = 'XX' ... group[1][id] = 'XX' group[1][name] = 'XX' ... json: group = [ { id:'XX', name:'XX', ... }, { id:'XX', name:'XX', ..

MySQL 设计与开发规范

1 目的 本规范的主要目的是希望规范数据库设计与开发,尽量避免由于数据库设计与开发不当而产生的麻烦:同时好的规范,在执行的时候可以培养出好的习惯,好的习惯是软件质量的很好保证. 2 适用范围 本规划的适用人员范围包括涉及数据库设计与开发的相关技术人员. 3 术语约定 本规范采用以下术语描述: ★规则:也称为强规范是编程时必须强制遵守的原则 ★建议:编程时必须加以考虑的原则 ★说明:对此规则或建议进行必要的解释 ★示例:对此规则或建议从正.反两个方面给出 4 规范及建议 4.1 书写规范 4.1.

编写良好的 git 提交信息

编写一个良好的 git 提交信息 提交信息 我们作一次提交,都会提交相关的修改信息,一般这些信息当时都会仔细考虑留下应该留下的那些重要信息,比如为什么需要这次提交,提交解决什么问题等. 而且我们需要好好组织这些信息,一边以后查看,因为这些跟代码一样重要,他们是历史,就像课本一样,一旦留下错误的信息或者难以理解的信息,将会对 后来者,产生非常多的麻烦. 提交信息规范 一般来说,提交信息没有什么强制性的规范,但是希望大家遵循一些基本的规则,这些规则有利于大家正确表达提交内容,留下重要的信息,而忽略那

Gerri review 代码管理规范

Gerrit review和发版管理 一:Gerrit提交审核代码流程 1.代码作者设置本地工作环境 2.从公开代码库同步代码到本地 3.代码开发者开发代码,提交代码 4.代码作者将代码提交到Gerrit缓存仓库,进入审核流程 5.代码作者指定相应的审核者来审核代码 6.审核者通过Gerrit查看代码修改,以确定是否符合要求? 7.符合要求就合并到Gerrit分支上,不符合要求就拒绝合并,让代码作者修改后重新提交 二:Gerrit提交代码规范和职责 1.所有的代码提交都是原子提交,尽量做到一个小

02测试工作流程及其规范

一.前期准备 1.了解测试安排:测试方案 2.熟悉系统功能:用户手册.测试手册.历史版本需求文档.系统演示会 3.熟悉需求:需求文档.需求传递会 二.需求分析&用例编写 1.明确干系人: 2. 分析需求 (要有自己的理解) 3.编写测试用例(用例编写符合规范) 三.测试执行 分层次执行 控制测试投入???? 尽早发现问题的原则 模拟实际场景和真实数据 提交符合规范的缺陷 推进解决问题.项目进展 四.测试总结

产品管理开发之Git工作流和分支规范推荐

前言 无论是开源项目还是内部项目,使用Git都是大势所趋,尤其是在产品管理这块,使用Git大大提高了开发效率和产品的交付频率.本篇,针对Git的工作流和分支使用,进行了一些推荐. 目录 1     产品管理开发之Git工作流和分支规范推荐 1.1      Git工作流模型推荐 1.2      Git产品开发分支规范要求 1.2.1      永久分支 1.2.1.1  master(稳定版) 1.2.1.2   开发版(develop) 1.2.2      临时性分支 1.2.2.1  

if 我是前端团队 Leader,怎么制定前端协作规范?

万字长文,继续刷新我的文章长度记录,涉及前端开发的方方面面.本文将持续更新和完善, 文章部分观点可能比较武断或不完整,欢迎评论和补充,一起完善该文章. 谢谢 笔者长期单枪匹马在前端领域厮杀(言外之意就是团队就一个人),自己就是规范.随着公司业务的扩展,扩充了一些人员,这时候就要开始考虑协作和编码规范问题了.本文记录了笔者在制定前端协作规范时的一些思考,希望能给你们也带来一些帮助. 一个人走的更快,一群人可以走得更远,前提是统一的策略,还要不断地反省和优化. 以下是目录概览, 看出这是一篇浩浩荡荡