Inspiration from continuous maintenance of table design

I am not a qualified database user, but I have participated in a very important database design process. However, I have been maintaining the database in the later stage of development, resulting in system problems caused by database changes at the code level. Personally, I feel that the database maintenance I do later is necessary, because logically speaking, the previous table design is unreasonable; but I have ignored the risks that changes will bring, so I have been thinking about it. At a certain stage of development, should the table be easily changed? Can the table be easily changed? Is there a way to shield the impact of database changes at the code level and database design level?

Let’s talk about whether the table should be changed in the later stage of development?
From the perspective of refactoring ideas, if there is a mistake, it must be corrected, and the system database should be continuously refactored and optimized, so it is possible and necessary to change and maintain.

Since later changes will definitely exist, how to reduce the impact of database changes on the code level? How to reduce the risk of table changes to the system?
1. First of all, I feel that the main business table should not be easily changed, and the key business fields should not be easily changed;
2. The mapping between database and entity code must be easy to modify, and the configuration must be clear;
3. When modifying, it must be Be aware of the risks involved in the modification
4. Comprehensive and fast test case operation
5. Strengthen the investment in the design stage
6. If it is really necessary, do not easily change the database design even if it is unreasonable