看看是什麼職務撒 web前端，ios，安卓，這些開發要資料庫許可權做什麼？ 只有後端開發或者dba需要 但是 看公司怎麼管理模式 一般有很多套環境 生產環境確實一般人都最好別知道

榮幸回答

同學請坐下，聽我言！

程式設計師在公司居然沒有資料許可權足於說明程式設計師在公司的技術得不到公司的肯定，信任度和可靠性不高，不能保證資料庫的安全使用。

大學剛剛畢業，一家第三方支付公司K，網上釋出了兩個技術崗位，A大學和B大學生成功的進入了K公司的技術管理部，A和B畢業後第一份工作，兩位同學激情高漲，工作中就像打了雞血一樣，不斷的在老員工的帶領下熟悉工作的伺服器管理和網路設施裝置。但是一個月過去了，他們部門成功接下來一個電商平臺專案需要使用Python進行開發，從後端到前端頁面，A和B積極的參與了專案，但是兩人卻表現出來了不同的表現，A不斷的和公司的老開發人員學習Python，慢慢的掌握許多的專案開發的知識點和技巧，很快A在完成專案分配的任務外還主動開發後續專案的功能，而B卻存在了原地，一個星期都寫不出來一個功能，卻每天去忙著去為其他部門提供技術支援，比如維修電腦，重灌系統，會議廳調裝置等著零碎的小事情，專案開發並和他走的很遠，最後B還是完成了他的任務，卻是在專案上線前的一週。

一個專案開發的週期過後，A在部門的技術水平以及能夠獨立自主的搭建專案框架和開發，完成需求，不斷的參與專案，B則每天為公司提供裝置上的技術支援，順便參與專案的資料搭建和sql的編寫。最終在6個月後轉正的工作和薪資徹底發生了改變，A參與了公司的線上的核心繫統開發和資料庫效能最佳化，B從程式開發崗轉變為了運維崗。

故事很普遍，也是我的真實經歷，企業對於員工的信任就是從最基本的技術和能力兩個方面來選擇，兩者都是正比上升。

只要技術水平和專案開發的能力得到公司的任何，公司已經不會做這樣的程式設計師保留任何的秘密和公司資訊資源的安全問題，因為他是一名值得依賴的程式開發的員工。

當然對於公司資料庫的操作許可權其實也是處於對公司的安全考慮，一個技術不過關，得到不任何，專案參與感低的程式設計師，公司是不可能信任把公司風險係數最大的資料庫操作許可權交給他。

總之，處於安全的考慮，公司不會隨便開發資料庫的操作許可權，程式設計師的待遇和薪資是靠能力最爭取的，當然也包括信任度。

一個程式設計師在公司沒有生產資料庫許可權再正常不過了。

但是，作為開發工程師，你有開發環境資料庫許可權，這就夠了。

省得生產出問題找你背鍋。

省得你有機會刪庫跑路。

都省心，何樂而不為？

許可權越高，責任也越大。沒有正式環境的資料庫恰恰是保護了自己，防止自己不小心犯錯給公司或者客戶造成不必要的損失。

還記得之前有個運維就是用了自己寫的一個小工具，連上了客戶正式環境資料庫，執行了鎖表操作，導致醫院系統無法正常使用，造成重大損失，自己也因此承擔相應的法律責任。

作為程式設計師來說不見得非要儲存正式環境的相關資訊，雖然說方便，但是很容易測試正式不分，導致誤操作。到時候別為了解決一個bug，丟了一個大西瓜，得不償失。職場上你做了多少貢獻，加了多少班，領導不一定會認可，但是造成了重大損失，你的責任跑不了。

所以即使解決某個問題，使用了正式的賬戶，用完之後也要清理掉正式資訊，不要給自己留下隱患。

996的同時也要記得保護好自己，不要面向監獄程式設計

作為一個已經工作多年的程式設計師，我來回答一下你這個問題。

資料庫，一般軟體開發中都會用到，關於它的許可權問題是這樣的：

一個公司的一個軟體產品，其實在不同的研發上線的不同階段，資料庫是獨立的。這個很好理解，開發環境程式設計師可以隨便改。線上環境可不是誰都有許可權的。

也就是說開發階段，測試階段，上線之前，上線之後，這些資料庫都是獨立的。作為程式設計師，你不會有所有這些資料庫的許可權，因為一旦上線產品的資料庫，改錯了的話，這是很有很大風險的，會為客戶帶來非常大的損失。

但比如測試環境的資料庫，作為一個開發開發人員正常來說，你有許可權去改動，但是你也不能夠不通知測試人員的情況下，你自己擅自去改動它。那麼測試環境有問題需要你來解決的時候，要和測試同事協商好，你要改什麼東西。因為測試的同事呢，他有他的測試任務，你不能阻礙他的工作。

那麼產品上線後的環境呢？只能看不能動！重要事情說三遍，你只能提供解決辦法。除非非常非常特殊的情況，但是我在過的公司流程管理很嚴格，這一步除非大大領導要求，而且要非常謹慎。

說白了就是誰的地盤誰做主。

你是程式設計師做開發的，那麼你就在開發的資料環境上，去做你的開發和測試。資料庫如果是你搭的你隨便改。

有的公司呢，還會有專門的資料組，那麼DBA的這個組呢，他們有更高的一些資料庫管理的許可權。所以一般來說，那麼這種情況下，你的許可權就是在你應用程式所控制的那些表的所有操作上了。比如下圖，不同使用者名稱有不同操作許可權的：

不同的公司，這個資料庫管理的方式也是不一樣的，僅從我的經歷上來回答這個問題。如果更多疑問可以繼續探討。

一般開發人員是不允許擁有資料庫操作許可權的。因為軟體是你開發的，一旦給了你資料庫許可權，增加了系統資料的洩露篡改的風險。正規的公司一般會有專門的DBA團隊來負責維護資料庫環境。如果生產開發需要，程式設計師要獲取線上的資料，需要提交工單到DBA團隊獲取臨時許可權。

這樣的好處：

資料作為當今網際網路、IT行業的核心資產，必須得到重視。不合規的管理流程必然導致各種安全風險，很多小公司開發兼任DBA的職責，我就遇到一個開發離職後使用原公司的資料庫連線篡改資料牟利，造成了重大的損失。也遇到不專業的資料庫管理造成資料庫被拖庫、被駭客鎖表勒索。所以一定要重視資料庫的管理，權限盡量保證合規性。

資料庫分環境的，1生產庫，2測試庫，3開發庫，4本地庫。1生產庫的管理權只在運維，全體開發無任何許可權（版本升級提供指令碼升級資料庫），原則是動技術的不碰生產資料，碰資料的不懂業務和技術；2測試庫管理許可權在運維和測試人員，開發無許可權，提供升級版本給測試（或者運維）；3開發庫許可權在運維和專案經理，開發人員提供指令碼升級；4本地庫是開發人員本機資料庫，自己隨便玩。綜上，如果是生產測試庫，開發無許可權很正常，說明管理到位

我覺得一個程式設計師在公司沒有資料庫許可權意味著安全，規範，合理。

所謂安全，可以說保護資料安全，公司安全，員工安全。

資料被篡改了，公司的客戶可能要炸毛，輕則一頓投訴，重則按照合同問責，追究責任。

資料洩露了，公司是第一責任體，輕則被問責，重則無窮大，好巧不巧公司還在做著要命的工作，什麼政府系，銀行系，公共服務系，我覺得公司多半會涼涼。

程式設計師本員，即使不是故意的，不小心搞壞了部分資料，或者複製了部分資料，也是直接問責，要知道資料雖然由公司製作的軟體生產，但是所有權歸屬於客戶，所謂數字資產這就是其中一類，公司作為管家肯定是不能同意把資料隨意開放給你的。

所謂規範，即從專案合同，法律法規，行業規範出發對資料儲存訪問的要求。

每個專案對資料的保密要求是不同的，或者需要專門的保密員，比如軍工系，政府系，只有他們才能解除傳資料用的介質，或者需要DBA或者保密委員會之類的專門資料交換處理部門，最不濟也得按照許可權分配和讀寫賬號，一般只讓用只讀得賬號檢視資料，反正我是沒有見過可以資料裸奔的專案。

所謂合理，從程式設計師本身的工作出發，職業習慣應該具有的資料許可權範圍。

我們猜想直接擁有資料庫許可權，你可能會做的事兒：

有功能改動，資料需要更新，寫個指令碼刷一下。

看看線上資料庫資料，確定功能正常不正常。

有個bug造成了錯誤資料，寫個sql改過來

運營想找什麼樣資料，讓我幫忙匯出來

其實，一切的直接操作資料庫都可以用功能上線來解決，只不過麻煩一些，流程會多一些。一些需求可能寫個指令碼提交為工單，讓DBA進行審查，把問題修復的時間線拉長，影響範圍擴大，我認為這種代價付出也是必要的。

我要保證我的所有操作都留下了我操作的痕跡，留足了證據，萬一在這段時間有什麼異常出現，有人指認是由於我動了資料庫造成，我能拿出什麼證據來自證清白呢。

從我自己的日常工作來說，我是非常牴觸要資料庫許可權的，基於以上我的考慮，離生產資料有多遠就離多遠，我不想做販賣資料的生意，也不想擔資料洩露的責任，如果我的bug導致資料出錯，我光明正大的修復認責，做一個專業的程式設計師。

講一個真實的事：

十多年前，我還在一個程式設計，當專案經理，有一天，客戶打電話給我，說你們是不是在哪一天，某個時間點，在某臺機器上，操作了什麼表，查詢了什麼內容，我當時也不確定，去問了一下我們專案組成員，發現是G同事，G同事也承認了是他操作。

但是根據工作的分工，他是不需要去查詢到那些表的，細問之下，才之後G的同學指使，他也幫那個單位做系統，他們做的是另外的系統，G受到他同學所託，去查詢那些資料,G同學又是受到外面其他人所託，我那個同事G，人很簡單的，他以為是他們做介面要用什麼，根本沒有多想，，，，反正這個事情說下去就有點嚴重啦，，，我感覺這個事情有點複雜，就趕緊上報部門領導，然後部門領導開會教育了G，又趕緊過去跟客戶解釋道歉，，，後來這個事情就終於過去了。

所以一個程式設計師在公司擁有資料庫許可權，就意味著！責！任！

一般正式環境的資料庫許可權是嚴格管控的，正式環境的資料庫由專門的人員進行操作，比如DBA 、技術leader 。資料是一個企業的核心價值，資料的丟失和洩露對於一個企業來說都是致命的，所以一般人員不允許操作的，假如操作失誤也是要承擔責任的。資料庫需要經常備份，增量備份、全量備份都要做，目的是儘可能的規避風險。

沒有是好事情。有一段時間做維護，天天維護生產資料庫，壓力山大。半夜睡覺都睡不好。好在幹了半年有人接手了。沒有最好，不接觸更好。做做框架設計都舒服啊。