权限越高,责任也越大。没有正式环境的数据库恰恰是保护了自己,防止自己不小心犯错给公司或者客户造成不必要的损失。 还记得之前有个运维就是用了自己写的一个小工具,连上了客户正式环境数据库,执行了锁表操作,导致医院系统无法正常使用,造成重大损失,自己也因此承担相应的法律责任。 作为程序员来说不见得非要保存正式环境的相关信息,虽然说方便,但是很容易测试正式不分,导致误操作。到时候别为了解决一个bug,丢了一个大西瓜,得不偿失。职场上你做了多少贡献,加了多少班,领导不一定会认可,但是造成了重大损失,你的责任跑不了。 所以即使解决某个问题,使用了正式的账户,用完之后也要清理掉正式信息,不要给自己留下隐患。 996的同时也要记得保护好自己,不要面向监狱编程 一般开发人员是不允许拥有数据库操作权限的。因为软件是你开发的,一旦给了你数据库权限,增加了系统数据的泄露篡改的风险。正规的公司一般会有专门的DBA团队来负责维护数据库环境。如果生产开发需要,程序员要获取线上的数据,需要提交工单到DBA团队获取临时权限。 这样的好处:保证了职责单一、各司其职。保证了隔离了权限,避免潜在的安全风险。规范了数据的工作流程。 数据作为当今互联网、IT行业的核心资产,必须得到重视。不合规的管理流程必然导致各种安全风险,很多小公司开发兼任DBA的职责,我就遇到一个开发离职后使用原公司的数据库连接篡改数据牟利,造成了重大的损失。也遇到不专业的数据库管理造成数据库被拖库、被黑客锁表勒索。所以一定要重视数据库的管理,权限尽量保证合规性。 我一个做客户端的,要什么数据库权限,别想甩锅给我,你求我我都不要。你这糟老头子坏得很[抠鼻] 数据库分环境的,1生产库,2测试库,3开发库,4本地库。 1生产库的管理权只在运维,全体开发无任何权限(版本升级提供脚本升级数据库),原则是动技术的不碰生产数据,碰数据的不懂业务和技术; 2测试库管理权限在运维和测试人员,开发无权限,提供升级版本给测试(或者运维); 3开发库权限在运维和项目经理,开发人员提供脚本升级; 4本地库是开发人员本机数据库,自己随便玩。 综上,如果是生产测试库,开发无权限很正常,说明管理到位 权限和责任是相对应的。权限越高,责任越大。现在因为数据库之类问题而被起诉的越来越多,而我们在面对企业起诉的过程中又属于弱势群体,日常工作保护好自己,是非常有必要的。 一个企业也必须在建立健全的权限管理体系,人总有误操作的时候,用体系和流程管理可以避免非正常操作而带来的损失。 荣幸回答我将知无不尽,尽无不言。 同学请坐下,听我言! 程序员在公司居然没有数据权限足于说明程序员在公司的技术得不到公司的肯定,信任度和可靠性不高,不能保证数据库的安全使用。 有这样的一个故事(个人亲身经历) 大学刚刚毕业,一家第三方支付公司K,网上发布了两个技术岗位,A大学和B大学生成功的进入了K公司的技术管理部,A和B毕业后第一份工作,两位同学激情高涨,工作中就像打了鸡血一样,不断的在老员工的带领下熟悉工作的服务器管理和网络设施设备。但是一个月过去了,他们部门成功接下来一个电商平台项目需要使用Python进行开发,从后端到前端页面,A和B积极的参与了项目,但是两人却表现出来了不同的表现,A不断的和公司的老开发人员学习Python,慢慢的掌握许多的项目开发的知识点和技巧,很快A在完成项目分配的任务外还主动开发后续项目的功能,而B却存在了原地,一个星期都写不出来一个功能,却每天去忙着去为其他部门提供技术支持,比如维修电脑,重装系统,会议厅调设备等着零碎的小事情,项目开发并和他走的很远,最后B还是完成了他的任务,却是在项目上线前的一周。 一个项目开发的周期过后,A在部门的技术水平以及能够独立自主的搭建项目框架和开发,完成需求,不断的参与项目,B则每天为公司提供设备上的技术支持,顺便参与项目的数据搭建和sql的编写。最终在6个月后转正的工作和薪资彻底发生了改变,A参与了公司的线上的核心系统开发和数据库性能优化,B从程序开发岗转变为了运维岗。 故事很普遍,也是我的真实经历,企业对于员工的信任就是从最基本的技术和能力两个方面来选择,两者都是正比上升。 只要技术水平和项目开发的能力得到公司的任何,公司已经不会做这样的程序员保留任何的秘密和公司信息资源的安全问题,因为他是一名值得依赖的程序开发的员工。 当然对于公司数据库的操作权限其实也是处于对公司的安全考虑,一个技术不过关,得到不任何,项目参与感低的程序员,公司是不可能信任把公司风险系数最大的数据库操作权限交给他。 总之,处于安全的考虑,公司不会随便开发数据库的操作权限,程序员的待遇和薪资是靠能力最争取的,当然也包括信任度。 有喜欢的同学记得关注我哟,点赞。我是你们的老学长@同学请坐下。 作为一个已经工作多年的程序员,我来回答一下你这个问题。 数据库,一般软件开发中都会用到,关于它的权限问题是这样的: 一个公司的一个软件产品,其实在不同的研发上线的不同阶段,数据库是独立的。这个很好理解,开发环境程序员可以随便改。线上环境可不是谁都有权限的。 也就是说开发阶段,测试阶段,上线之前,上线之后,这些数据库都是独立的。作为程序员,你不会有所有这些数据库的权限,因为一旦上线产品的数据库,改错了的话,这是很有很大风险的,会为客户带来非常大的损失。 但比如测试环境的数据库,作为一个开发开发人员正常来说,你有权限去改动,但是你也不能够不通知测试人员的情况下,你自己擅自去改动它。那么测试环境有问题需要你来解决的时候,要和测试同事协商好,你要改什么东西。因为测试的同事呢,他有他的测试任务,你不能阻碍他的工作。 那么产品上线后的环境呢?只能看不能动!重要事情说三遍,你只能提供解决办法。除非非常非常特殊的情况,但是我在过的公司流程管理很严格,这一步除非大大领导要求,而且要非常谨慎。 说白了就是谁的地盘谁做主。 你是程序员做开发的,那么你就在开发的数据环境上,去做你的开发和测试。数据库如果是你搭的你随便改。 有的公司呢,还会有专门的数据组,那么DBA的这个组呢,他们有更高的一些数据库管理的权限。所以一般来说,那么这种情况下,你的权限就是在你应用程序所控制的那些表的所有操作上了。比如下图,不同用户名有不同操作权限的: 不同的公司,这个数据库管理的方式也是不一样的,仅从我的经历上来回答这个问题。如果更多疑问可以继续探讨。 我是工作多年的大数据攻城狮一枚,相关问题可以在评论区留言,或者私信我! 我觉得一个程序员在公司没有数据库权限意味着安全,规范,合理。 所谓安全,可以说保护数据安全,公司安全,员工安全。 数据被篡改了,公司的客户可能要炸毛,轻则一顿投诉,重则按照合同问责,追究责任。 数据泄露了,公司是第一责任体,轻则被问责,重则无穷大,好巧不巧公司还在做着要命的工作,什么政府系,银行系,公共服务系,我觉得公司多半会凉凉。 程序员本员,即使不是故意的,不小心搞坏了部分数据,或者拷贝了部分数据,也是直接问责,要知道数据虽然由公司制作的软件生产,但是所有权归属于客户,所谓数字资产这就是其中一类,公司作为管家肯定是不能同意把数据随意开放给你的。 所谓规范,即从项目合同,法律法规,行业规范出发对数据保存访问的要求。 每个项目对数据的保密要求是不同的,或者需要专门的保密员,比如军工系,政府系,只有他们才能解除传数据用的介质,或者需要DBA或者保密委员会之类的专门数据交换处理部门,最不济也得按照权限分配和读写账号,一般只让用只读得账号查看数据,反正我是没有见过可以数据裸奔的项目。 所谓合理,从程序员本身的工作出发,职业习惯应该具有的数据权限范围。 我们猜想直接拥有数据库权限,你可能会做的事儿: 有功能改动,数据需要更新,写个脚本刷一下。 看看线上数据库数据,确定功能正常不正常。 有个bug造成了错误数据,写个sql改过来 运营想找什么样数据,让我帮忙导出来 其实,一切的直接操作数据库都可以用功能上线来解决,只不过麻烦一些,流程会多一些。一些需求可能写个脚本提交为工单,让DBA进行审查,把问题修复的时间线拉长,影响范围扩大,我认为这种代价付出也是必要的。 我要保证我的所有操作都留下了我操作的痕迹,留足了证据,万一在这段时间有什么异常出现,有人指认是由于我动了数据库造成,我能拿出什么证据来自证清白呢。 从我自己的日常工作来说,我是非常抵触要数据库权限的,基于以上我的考虑,离生产数据有多远就离多远,我不想做贩卖数据的生意,也不想担数据泄露的责任,如果我的bug导致数据出错,我光明正大的修复认责,做一个专业的程序员。 一个程序员在公司没有生产数据库权限再正常不过了。 但是,作为开发工程师,你有开发环境数据库权限,这就够了。 省得生产出问题找你背锅。 省得你有机会删库跑路。 都省心,何乐而不为? 讲一个真实的事: 十多年前,我还在一个编程,当项目经理,有一天,客户打电话给我,说你们是不是在哪一天,某个时间点,在某台机器上,操作了什么表,查询了什么内容,我当时也不确定,去问了一下我们项目组成员,发现是G同事,G同事也承认了是他操作。 但是根据工作的分工,他是不需要去查询到那些表的,细问之下,才之后G的同学指使,他也帮那个单位做系统,他们做的是另外的系统,G受到他同学所托,去查询那些数据,G同学又是受到外面其他人所托,我那个同事G,人很简单的,他以为是他们做接口要用什么,根本没有多想,,,,反正这个事情说下去就有点严重啦,,,我感觉这个事情有点复杂,就赶紧上报部门领导,然后部门领导开会教育了G,又赶紧过去跟客户解释道歉,,,后来这个事情就终于过去了。 所以一个程序员在公司拥有数据库权限,就意味着!责!任!