什么样的架构能防止表结构变动后程序运行错误？

Question

今天被一个前端教育了,说后端变动一点表结构(比如删一个表或者变了一个字段)程序就运行不起来,那我就像了解一下到底怎么做才能防止上述问题出现的时候程序能正常运行? 需要对每个表做字段映射吗?还是说别的什么黑科技?

补充一下,我这里发生的故事就是我设计的库被另一个家伙给删了主表,而且一些需要做判断的字段含义给改了,类似判断颜色的 status 字段变成了判断形状,结果被一个前端嘲讽代码不够健壮,说他们的东西少了个东西什么的程序没影响(安卓),弄得我很是无语,不知道怎么给他解释,顺便想了解一下 dalao 们对于功能解耦需要做到什么程度

Answer 1

感觉你的想法很有问题。程序本身就是处理数据的，数据表变动相当于数据和数据结构本身都可能变动，这种情况下对原本的代码逻辑合理性肯定会有影响，必须对原有代码进行fix。别说删了一个表，变了一个字段程序有bug都是正常的，除非那些数据都只是些数据字典，对逻辑本身没有太大的影响。而且被前端教育又是什么鬼。前端和后端只要做好数据交互不就行，后端提供数据，前端负责展示，表结构变动跟前端有半毛钱关系，只要数据接口和接口提供的数据是正常的，前端就不会知道后端发生了什么。

Answer 2

数据库设计考虑数据库范式和三个模式，但是我所知道的架构都无法完全解耦，只能通过架构减少数据库和程序的耦合度。解决这个问题，一种有效的思路是在设计数据库时。尽量理解需求，多做思考，减少表的变动，然后是代码规范，采用一些设计模式，增加可扩展性。

Answer 3

我发现上面回复的都是“大神”！因为，在我有限的认识里，我认为：既然是数据表发生了变动，说明业务、代码肯定是需要调整的。如果，数据表发生了变动，而代码不需要修改就能毫不影响，那么请问：修改数据表的意义何在？（我们先不考虑楼主的数据表是否是由于别人的失误导致的）。不可否认，确实可以对程序加一大堆捕获异常。那么，捕获这样的异常的意义何在呢？仅仅为了不返回500错误？ 所以，数据库要调整，肯定得确认代码也要做相应的调整，确定没问题之后，二者再同时更新。再说说这个前端，他就是个满口跑火车、只知道瞎BB的傻B。你问他：假如接口定义要返回字段名是name，而哪天后端随便修改一下，变成title，那么在不通知他的情况下，他前端是不是能自动识别出来，不报错？总而言之，前端、后端、数据库，任何一个环节有变动的话，肯定是先联通测试，都没问题了，再一起上线的。像楼主这种情况，只能说是那个2B同事的人为导致的。

Answer 4

所以说现在前端的水平越来越低了...当然你那个删库的同事跟这个前端倒是半斤八两

Answer 5

什么公司啊？表是能随便删的吗？我也是服了，另外前段嘲讽后端代码不够健壮？你们公司的人才真是搞颠倒了。

Answer 6

数据库都被删了，还希望怎么正常运行呢 ？ 我是觉得，你需要做好异常处理，数据库 PDO 有异常了，页面的话可以直接显示 【服务器挂啦】之类的，接口的话，直接返回 status = 500 之类的，只要不把真正的错误信息暴露出来，就可以了。 至于跟你说的那个前端 或者 安卓 ，难道写的 app 就从来没崩溃过 ？总要一步一步慢慢来，不可能一口吃成胖子。

Answer 7

我覺得增加和刪除一個字段就讓程序運行不了,這根本個人的問題.程序沒有上線之前,由於需求不明確和修改出現表結構修改問題是很正常的事情.但修改完,model層肯定是需要對查詢作修改.出現問題只能說你要么程序寫太亂.要么就是自己跟住沒有對api進行測試.至於被前端刁,只是前端立馬把個鍋甩給你而已,具體問題還是要具體分析 沒辦法去完全解耦，但可以減低這種坑爹的事情發生。1.一定要做好版本控制，這個是必須，其實你說另外一個傢伙刪掉主表表的改動，這些數據改動需要通過需求通過時候，起下一版本中開發實現，假如可以由人隨便改動數據表結構，那麼肯定是你們的項目經理的腦子有問題。所以使用git、svn等做版本控制是必須的.2.做好權限控制，避免從倉庫deploy到線上的過程中出現問題，做好權限控制系必須。尤其涉及到數據庫改動，版本增刪改查，只要記住一點，權限分配給的人越少，系統就越安全。

Answer 8

完善程序逻辑，增加异常处理，完善api接口消息状态码，设置错误处理机制，保证任何可能出错或异常的地方依旧能给前端一个错误数据的输出，这样才足够健壮，至于数据库层完全没必要。

Answer 9

不应该这么想。你应该考虑为API cover一个冒烟测试，在上线前跑起来，来避免这种错误。