今天被一個前端教育了,說後端變動一點表結構(比如刪一個表或者變了一個字段)程序就運行不起來,那我就像了解一下到底怎麼做才能防止上述問題出現的時候程式能正常運作?需要對每個表做字段映射嗎?還是說別的什麼黑科技?
補充一下,我這裡發生的故事就是我設計的庫被另一個傢伙給刪了主表,而且一些需要做判斷的字段含義給改了,類似判斷顏色的status 字段變成了判斷形狀,結果被一個前端嘲諷代碼不夠健壯,說他們的東西少了個東西什麼的程式沒影響(安卓),弄得我很是無語,不知道怎麼給他解釋,順便想了解一下dalao 們對於功能解耦需要做到什麼程度
阿神2017-06-21 10:12:45
感覺你的想法很有問題。
程式本身就是處理資料的，資料表變動相當於資料和資料結構本身都可能變動，這種情況下對原本的程式碼邏輯合理性肯定會有影響，必須對原有程式碼進行fix。別說刪了一個表，變了一個欄位程式有bug都是正常的，除非那些資料都只是些資料字典，對邏輯本身沒有太大的影響。
而且被前端教育又是什麼鬼。前端和後端只要做好數據互動不就行，後端提供數據，前端負責展示，表結構變動跟前端有半毛錢關係，只要數據接口和接口提供的數據是正常的，前端就不會知道後端發生了什麼事。
typecho2017-06-21 10:12:45
資料庫設計考慮資料庫範式和三個模式，
但是我所知道的架構都無法完全解耦，只能透過架構來減少資料庫和程式的耦合度。解決這個問題，一個有效的想法是在設計資料庫時。盡量理解需求，多做思考，減少表格的變動，然後是程式碼規範，採用一些設計模式，增加可擴展性。
欧阳克2017-06-21 10:12:45
資料庫都被刪了，還希望怎麼正常運作呢 ？
我是覺得，你需要做好異常處理，資料庫PDO 有異常了，頁面的話可以直接顯示【伺服器掛啦】之類的，介面的話，直接回傳status = 500 之類的，只要不把真正的錯誤資訊暴露出來，就可以了。
至於跟你說的那個前端 或 安卓 ，難道寫的 app 就從來沒崩潰過 ？
總要一步一步慢慢來，不可能一口吃成胖子。
ringa_lee2017-06-21 10:12:45
我覺得增加和刪除一個字段就讓程式運行不了,這根本個人的問題.程式沒有上線之前,由於需求不明確和修改出現表結構修改問題是很正常的事情.但修改完,model層肯定是需要對查詢作修改.出現問題只能說你要么程序寫太亂.要么就是自己跟住沒有對api進行測試.至於被前端刁,只是前端立馬把個鍋甩給你而已,具體問題還是要具體分析
沒辦法去完全解耦，但可以減低這種坑爹的事情發生。
1.一定要做好版本控制，這個是必須，其實你說另外一個傢伙刪掉主表表的改動，這些數據改動需要通過需求通過時候，起下一版本中開發實現，假如可以由人隨便改動資料表結構，那麼肯定是你們的專案經理的腦子有問題。所以使用git、svn等做版本控制是必須的.
2.做好權限控制，避免從倉庫deploy到線上的過程中出現問題，做好權限控制系必須。尤其牽涉到資料庫改動，版本增刪改查，只要記住一點，權限分配給的人越少，系統就越安全。
phpcn_u15822017-06-21 10:12:45
完善程式邏輯，增加異常處理，完善api介面訊息狀態碼，設定錯誤處理機制，保證任何可能出錯或異常的地方依舊能給前端一個錯誤資料的輸出，這樣才足夠健壯，至於資料庫層完全沒必要。
给我你的怀抱2017-06-21 10:12:45
我發現上面回覆的都是「大神」！因為，在我有限的認識裡，我認為：既然是資料表發生了變動，表示業務、程式碼肯定是需要調整的。如果，資料表發生了變動，而程式碼不需要修改就能毫不影響，那麼請問：修改資料表的意義何在？ （我們先不考慮樓主的資料表是否是因為別人的失誤導致的）。不可否認，確實可以對程式加一大堆捕獲異常。那麼，捕獲這樣的異常的意義何在呢？只是為了不回傳500錯誤？ 所以，資料庫要調整，一定要確認程式碼也要做對應的調整，確定沒問題之後，二者再同時更新。
再說說這個前端，他就是個滿口跑火車、只知道瞎BB的傻B。你問他：假如介面定義要回傳欄位名稱是name，而哪天後端隨便修改一下，變成title，那麼在不通知他的情況下，他前端是不是能自動辨識出來，不報錯？
總而言之，前端、後端、資料庫，任何一個環節有變動的話，肯定是先聯通測試，都沒問題了，再一起上線的。像樓主這種情況，只能說是那個2B同事的人為導致的。
習慣沉默2017-06-21 10:12:45
首先，我必須說，你的這個想法從出發點而言就是不對的。
第一，我得承認，表結構變動後，程式仍然可以運作不報錯，是可以實現的。在後端邏輯中，處理資料之前加入容錯處理和錯誤擷取就可以防止錯誤訊息直接傳到前端導致前端崩潰。
但是，程式不報錯，不代表功能沒有錯誤。我就以你這個情況為例，假設你的主表是一個訂單表，原本訂單標題是name，後來你把這個資料庫欄位改成了title，而沒有改變後端的程式碼。由於後端有容錯處理，所以下單還是可以正常下單的，但是由於原本標題寫入name字段，現在name字段不存在，因為有容錯處理所以不會報錯，但是訂單標題數據卻沒有寫到資料庫裡。在這種情況下，前後端包括操作人員在調試的時候，由於程式可以正常運行，可能並沒有發現這個問題。那麼程式上線給客戶使用時候，客戶發現了這個問題，這樣才是真的出了BUG。
再以下單為例舉個例子，你說你同事刪掉了主表（我假設刪了訂單主表）。你的程式碼裡，下單操作是：先加入主表，如果主表新增成功，再給其他表附加資料。如果主表新增失敗則直接跳出。這樣的話，就算刪掉了主表，也是不會報錯的。但是，這樣一來，如果在開發後期測試中，前端後端和運維都覺得這個功能之前是好的，不需要重新測試，然後測了其他功能就上線了，這樣線上的版本雖然可以提交訂單，但是實際上不會產生任何訂單資料（因為主表沒有寫入成功）。這個BUG被客戶發現之後，就算是生產事故了。
所以，我個人認為，在後端做程式碼的容錯和錯誤捕獲是必要的，但是並不能因為前端程式沒有肉眼可見的問題，就只改動資料庫而不對相關邏輯進行修改。在進行資料庫修改和前後端邏輯修正之後，需要重新測試整個獨立功能，確保無誤之後才可以上線。