今天被一个前端教育了,说后端变动一点表结构(比如删一个表或者变了一个字段)程序就运行不起来,那我就像了解一下到底怎么做才能防止上述问题出现的时候程序能正常运行? 需要对每个表做字段映射吗?还是说别的什么黑科技?
补充一下,我这里发生的故事就是我设计的库被另一个家伙给删了主表,而且一些需要做判断的字段含义给改了,类似判断颜色的 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被客户发现之后，就算得上是生产事故了。
所以，我个人认为，在后端做代码的容错和错误捕获是必要的，但是并不能因为前端程序没有肉眼可见的问题，就只改动数据库而不对相关逻辑进行修改。在进行数据库修改和前后端逻辑修正之后，需要重新测试整个独立功能，确保无误之后才可以上线。