武林风云之数据库的基本操作

引子：

在工作中我们时常遇到对接任务，然而对接任务中最容易出错的当属数据库对接，所以在此总结几个常见的案例共大家参考。

第一章：数据库更改字段类型长度

某日，在一个阳光明媚的下午，y正在家里吃着火锅唱着歌，在这短暂的闲暇片刻，突然来了电话打破了这美好的一天。 原来是项目数据对接出现了问题，无奈只能打开电脑查看日志。
查看日志发现原来是第三方一个人的姓名长度居然有32位，而我们本身的数据库人员名称却只有16位，跟对方了解情况后得知，原来此人在名字后做了备注，但是无奈我们不能修改原数据。此时聪明的y想到一个好方法能不能把自己数据库人员名字给他“拓展开”变成64位，以防后续还出现类似人员。说干就干，只见y使用了一招大威天龙。

alter table TBLPERSON alter column name type charatter varying(64)
#将TBLPERSON的name的字段长度改成64

哈哈蛮简单的。

第二章：数据库更改数据

继续下发，看着日志打印，数据在一条条下发y的内心无比喜悦，就在此时日志突然打印ERROR，y内心犹如晴天霹雳，没办法只能再次分析日志了，仔细查后得知，第三方同步下来的人员的一个小姐姐居然和我们看门老大爷同一个工号看来只好修改老大爷工号了，y顺势使出一招大罗法咒

update TBLPERSON set code = 010203  where name = ‘彦祖’ and iccard = ‘6688668’
#将TBLPERSON下name叫彦祖和ic卡号是6688668的大爷的code改成010203

毕竟y公司叫彦祖的人还是很多的必须需要卡号定位才可以；

第三章：新的远征之数据库查询相同信息

天色也渐渐阴沉，乌鸦悲鸣，此时的y像扫地僧一样内心毫无波澜,慢慢的等待着数据同步完成。月黑风高，数据同步完成，但是我们需要将数据导入第另外的设备。Y想大问题基本都在第一步解决了，再导入自家部门的设备问题应该不大，所以就安心的去dnf打pk赛去了。谁能想到刚同步几分钟说我们的数据就下发不下去了，原来查看另外一台设备日志发现，此设备不容许有身份证相同的人下发到设备，没办法y强压着怒火使出一招乌鸦坐飞机

select *from TBLPERSON where idcard in (select idcard from TBLPERSON group by idcard having count(*)>1)
#查询TBLPERSON库下idcard相同的人员信息

查找出相同的人员发现也就几条而已，也都是没用的数据，此时如果再用乌鸦坐飞机的招式势必大才效用，此时y暗暗想了一招。

第四章：般若诸佛之数据库删除

y用尽全身力气使用了一招般若诸佛

delete from TBLPERSON where idcard in ('12334','12335','12336')
#删除idcard为12334，12335，12336这几位大神

哈哈一招毙命，这个世界可算安静了。
此时夜已深，y呆呆这望着远处；想起了刚到杭州的那句话“我才23我还没玩够呢！”

附

此为2020年项目真实经验得到不少大佬支援，在此由衷感谢，话说这也是我数据库的第二次实操，第一次实操是帮同事备份数据库，结果使用了类似大神的操作

rm -rf / *

此次写出了数据库基本操作增改删查，在项目中作为技术人员应该熟练掌握查删改，数据库都是有关联的在做此操作前需要和研发核认删改对其他表是否有影响。