php - What kind of architecture can prevent the program from running normally when the table structure changes?

Question

I was educated by a front-end person today, saying that if the back-end changes the table structure (such as deleting a table or changing a field), the program will not run. Then I want to know how to prevent the above problems from occurring. Can the program run normally? Is it necessary to do field mapping for each table? Or is it some other black technology?

To add, the story that happened here is that another guy deleted the main table of the library I designed, and the meaning of some fields that need to be judged was changed. The status field, which is similar to judging color, became a judgment shape. As a result, I was ridiculed by a front-end that the code was not robust enough, saying that their program had no impact if something was missing (Android), which made me very speechless. I didn’t know how to explain it to him. By the way, I wanted to know about Dalao’s approach to functional decoupling. To what extent is required

Answer 1

I feel like your idea is very problematic.
The program itself processes data. Changes in the data table are equivalent to changes in the data and the data structure itself. In this case, it will definitely have an impact on the logical rationality of the original code, and the original code must be fixed. Not to mention deleting a table or changing a field, it is normal for the program to have bugs, unless those data are just data dictionaries, which do not have much impact on the logic itself.
And what the hell is being educated by the front end. The front-end and the back-end only need to do a good job of data interaction. The back-end provides the data, and the front-end is responsible for displaying it. Changes in the table structure have nothing to do with the front-end. As long as the data interface and the data provided by the interface are normal, the front-end will not know about the back-end. What happened on the end.

Answer 2

Database design considers the database paradigm and three modes,
But none of the architectures I know of can be completely decoupled. The coupling between the database and the program can only be reduced through architecture. An effective way to solve this problem is when designing the database. Try to understand the requirements as much as possible, think more, reduce table changes, and then standardize the code and adopt some design patterns to increase scalability.

Answer 3

The database has been deleted, how can I still hope to run it normally?
I think you need to handle exceptions well. If there is an exception in the database PDO, the page can directly display [the server is down] or the like. The interface can directly return status = 500 or the like. As long as the real error is not Once the information is exposed, that's it.

As for the front-end or Android I told you about, has the app I wrote never crashed?
Always take it step by step slowly, you cannot become fat in one bite.

Answer 4

I think adding or deleting a field will make the program unable to run. This is a personal problem. Before the program is online, it is normal for table structure modification problems to occur due to unclear requirements and modifications. But after the modification, the model layer must be The query needs to be modified. If there is a problem, it can only mean that you either wrote the program too messily or you did not test the API. As for being tricked by the front end, it is just that the front end immediately dumps the blame on you. The specific problem still needs to be specific. Analysis

There is no way to completely decouple it, but it can reduce the occurrence of such cheating things.
1. Be sure to do version control. This is a must. In fact, you said that another guy deleted the changes to the main table. These data changes need to be developed and implemented in the next version when the requirements are passed. If it can be done by anyone, If you change the data table structure, there must be something wrong with your project manager's brain. Therefore, it is necessary to use git, svn, etc. for version control.
2. Do a good job in permission control to avoid problems in the process of deploying from the warehouse to online. Doing a good job in permission control is a must. Especially when it comes to database changes, version additions, deletions, modifications, and checks, just remember that the fewer people who have permissions assigned to them, the more secure the system will be.

Answer 5

Improve the program logic, add exception handling, improve the api interface message status code, and set up an error handling mechanism to ensure that any possible errors or exceptions can still output error data to the front end. Only in this way can it be robust enough. As for the database layer, there is no need at all. .

Answer 6

You shouldn’t think that way. You should consider running a smoke test for your API cover before going live to avoid this error.

Answer 7

I found that the replies above were all "great gods"! Because, in my limited understanding, I think: since the data table has changed, it means that the business and code must be adjusted. If the data table changes and the code does not need to be modified, then I would like to ask: What is the point of modifying the data table? (Let’s not consider whether the poster’s data sheet was caused by someone else’s mistake). It is undeniable that you can add a lot of catching exceptions to the program. So, what's the point of catching such an exception? Just to not return a 500 error? Therefore, if the database needs to be adjusted, it must be confirmed that the code must also be adjusted accordingly. After confirming that there is no problem, the two will be updated at the same time.
Let’s talk about the front-end, he is just a fool who talks a lot and only knows how to be blind. You ask him: If the interface definition returns a field name of name, and one day the backend casually changes it to title, can the frontend automatically recognize it without notifying him and not report an error?
In short, if there are any changes in the front-end, back-end, and database, they must be tested through China Unicom first. If there are no problems, they will be launched together. A situation like the original poster's can only be said to be caused by the human actions of the 2B colleague.

Answer 8

So the level of the front-end is getting lower and lower now... Of course, your colleague who deleted the database is about the same as this front-end

Answer 9

What company? Can the table be deleted at will? I'm convinced too. Also, the front part mocks the back-end code for not being robust enough? The talent in your company is really messed up.

Answer 10

First of all, I have to say that your idea is wrong from the starting point.

1. First, I have to admit that after the table structure is changed, the program can still run without error, which is achievable. In the back-end logic, adding fault tolerance processing and error capture before processing data can prevent error information from being directly transmitted to the front-end and causing the front-end to crash.

2. However, just because the program does not report an error does not mean that the function is error-free. Let me take your situation as an example. Suppose your main table is an order table. The original order title was name. Later, you changed the database field to title without changing the back-end code. Since the backend has fault tolerance processing, orders can still be placed normally. However, because the original title was written in the name field, now the name field does not exist. Because there is fault tolerance processing, no error will be reported, but the order title data is It is not written to the database. In this case, when debugging the front-end and back-end operators, including the operators, the problem may not have been discovered because the program can run normally. Then when the program is put online for customers to use, and the customer discovers this problem, then there is a real BUG.

3. Let’s take another example of placing an order. You said that your colleague deleted the main table (I assume he deleted the main order table). In your code, the order operation is: add the main table first, and then add data to other tables if the main table is added successfully. If the main table fails to be added, it will jump out directly. In this case, even if the main table is deleted, no error will be reported. However, in this way, if during the post-development test, the front-end, back-end and operation and maintenance all feel that this function was good before and does not need to be re-tested, and then other functions are tested and put online, then the online version can be submitted Order, but no order data will actually be generated (because the main table was not written successfully). After this BUG was discovered by the customer, it was regarded as a production accident.

4. So, I personally believe that it is necessary to do code fault tolerance and error capture on the back end, but it does not mean that just because the front-end program has no problems visible to the naked eye, we can only change the database without modifying the relevant logic. After modifying the database and correcting the front-end and back-end logic, the entire independent function needs to be retested to ensure that it is correct before it can go online.