Ich wurde heute von einer Front-End-Person darüber aufgeklärt, dass das Programm nicht ausgeführt werden kann, wenn das Back-End die Tabellenstruktur ein wenig ändert (z. B. das Löschen einer Tabelle oder das Ändern eines Felds). Um das Auftreten der oben genannten Probleme zu verhindern, muss ich für jede Tabelle eine Feldzuordnung durchführen
Zudem passierte hier die Geschichte, dass die Haupttabelle der von mir entworfenen Bibliothek von einem anderen Mann gelöscht wurde und die Bedeutung einiger Felder, die beurteilt werden mussten, geändert wurde. Das Statusfeld ähnelt der Beurteilung der Farbe , wurde in die Beurteilungsform geändert, und das Ergebnis war, dass ein Frontend den Code verspottete, weil er nicht robust genug war, und sagte, dass ihrem Programm etwas fehlte und es keine Auswirkungen hatte (Android), was mich sprachlos machte Ich weiß übrigens, was Dalao und andere in Bezug auf die funktionale Entkopplung tun müssen
感觉你的想法很有问题。
程序本身就是处理数据的，数据表变动相当于数据和数据结构本身都可能变动，这种情况下对原本的代码逻辑合理性肯定会有影响，必须对原有代码进行fix。别说删了一个表，变了一个字段程序有bug都是正常的，除非那些数据都只是些数据字典，对逻辑本身没有太大的影响。
而且被前端教育又是什么鬼。前端和后端只要做好数据交互不就行，后端提供数据，前端负责展示，表结构变动跟前端有半毛钱关系，只要数据接口和接口提供的数据是正常的，前端就不会知道后端发生了什么。
数据库设计考虑数据库范式和三个模式，
但是我所知道的架构都无法完全解耦，只能通过架构减少数据库和程序的耦合度。解决这个问题，一种有效的思路是在设计数据库时。尽量理解需求，多做思考，减少表的变动，然后是代码规范，采用一些设计模式，增加可扩展性。
数据库都被删了，还希望怎么正常运行呢 ？
我是觉得，你需要做好异常处理，数据库 PDO 有异常了，页面的话可以直接显示 【服务器挂啦】之类的，接口的话，直接返回 status = 500 之类的，只要不把真正的错误信息暴露出来，就可以了。
至于跟你说的那个前端 或者 安卓 ，难道写的 app 就从来没崩溃过 ？
总要一步一步慢慢来，不可能一口吃成胖子。
我覺得增加和刪除一個字段就讓程序運行不了,這根本個人的問題.程序沒有上線之前,由於需求不明確和修改出現表結構修改問題是很正常的事情.但修改完,model層肯定是需要對查詢作修改.出現問題只能說你要么程序寫太亂.要么就是自己跟住沒有對api進行測試.至於被前端刁,只是前端立馬把個鍋甩給你而已,具體問題還是要具體分析
沒辦法去完全解耦，但可以減低這種坑爹的事情發生。
1.一定要做好版本控制，這個是必須，其實你說另外一個傢伙刪掉主表表的改動，這些數據改動需要通過需求通過時候，起下一版本中開發實現，假如可以由人隨便改動數據表結構，那麼肯定是你們的項目經理的腦子有問題。所以使用git、svn等做版本控制是必須的.
2.做好權限控制，避免從倉庫deploy到線上的過程中出現問題，做好權限控制系必須。尤其涉及到數據庫改動，版本增刪改查，只要記住一點，權限分配給的人越少，系統就越安全。
完善程序逻辑，增加异常处理，完善api接口消息状态码，设置错误处理机制，保证任何可能出错或异常的地方依旧能给前端一个错误数据的输出，这样才足够健壮，至于数据库层完全没必要。
不应该这么想。你应该考虑为API cover一个冒烟测试，在上线前跑起来，来避免这种错误。
我发现上面回复的都是“大神”！因为，在我有限的认识里，我认为：既然是数据表发生了变动，说明业务、代码肯定是需要调整的。如果，数据表发生了变动，而代码不需要修改就能毫不影响，那么请问：修改数据表的意义何在？（我们先不考虑楼主的数据表是否是由于别人的失误导致的）。不可否认，确实可以对程序加一大堆捕获异常。那么，捕获这样的异常的意义何在呢？仅仅为了不返回500错误？ 所以，数据库要调整，肯定得确认代码也要做相应的调整，确定没问题之后，二者再同时更新。
再说说这个前端，他就是个满口跑火车、只知道瞎BB的傻B。你问他：假如接口定义要返回字段名是name，而哪天后端随便修改一下，变成title，那么在不通知他的情况下，他前端是不是能自动识别出来，不报错？
总而言之，前端、后端、数据库，任何一个环节有变动的话，肯定是先联通测试，都没问题了，再一起上线的。像楼主这种情况，只能说是那个2B同事的人为导致的。
所以说现在前端的水平越来越低了...当然你那个删库的同事跟这个前端倒是半斤八两
什么公司啊？表是能随便删的吗？我也是服了，另外前段嘲讽后端代码不够健壮？你们公司的人才真是搞颠倒了。
首先，我不得不说，你的这个想法从出发点而言就是不对的。
第一，我得承认，表结构变动后，程序仍然可以运行不报错，是可以实现的。在后端逻辑中，处理数据之前加入容错处理和错误捕获就可以防止错误信息被直接传到前端导致前端崩溃。
但是，程序不报错，并不代表功能没有错误。我就以你这个情况为例，假设你的主表是一个订单表，原本订单标题是
name，后来你把这个数据库字段改成了title，而没有改变后端的代码。由于后端有容错处理，所以下单还是可以正常下单的，但是由于原本标题写入name字段，现在name字段不存在，因为有容错处理所以不会报错，但是订单标题数据却没有写到数据库里。这种情况下，前后端包括运营人员在调试的时候，由于程序可以正常运行，可能并没有发现这个问题。那么程序上线给客户使用时候，客户发现了这个问题，这样才是真的出了BUG。再以下单为例举个例子，你说你同事删掉了主表（我假设删了订单主表）。你的代码里，下单操作是：先添加主表，如果主表添加成功，再给其他表附加数据。如果主表添加失败则直接跳出。这样的话，就算删掉了主表，也是不会报错的。但是，这样一来，如果在开发后期测试中，前端后端和运维都觉得这个功能之前是好的，不需要重新测试，然后测了其他功能就上线了，这样线上的版本虽然可以提交订单，但是实际不会产生任何订单数据（因为主表没写入成功）。这个BUG被客户发现之后，就算得上是生产事故了。
所以，我个人认为，在后端做代码的容错和错误捕获是必要的，但是并不能因为前端程序没有肉眼可见的问题，就只改动数据库而不对相关逻辑进行修改。在进行数据库修改和前后端逻辑修正之后，需要重新测试整个独立功能，确保无误之后才可以上线。