Database primary keys should not have any business Significance

One of the most important theories in relational database science is: do not give any amateur meanings to keywords. If a keyword has a business significance, when the user decides the business meaning, maybe they want to add a few digits for the keyword or change the number to a letter, then the related keywords must be modified. The primary keywords in a table may be used as foreign keys by other tables. Even a simple change may cause significant maintenance overhead.
To make the table's primary key do not have any business significance, one solution is to use the proxy primary key, for example, you can define an ID field (or another name) that does not have any business meaning for a table and use it as the primary key of the table.
I will review many of the databases I designed previously, but I have not considered them carefully in some places. Even if most of the primary keys have no business significance, some tables may still have primary keys associated with the business. I always think that the primary key is used to maintain uniqueness. The reason why a proxy primary key is required is that some records cannot maintain uniqueness. For example, if you design a user table, the user name may be repeated. The user name may be blue, and the user name may also be blue. This requires an ID to distinguish.
Some database design errors are caused by my previous ideas. For example, I used an ID in a database design to be the primary key of a table. This table records some reports. Each report has an ID, which is of business significance and can be input or automatically generated by the customer. However, the customer indicates that the ID is unique and digital. Therefore, due to its uniqueness, I designed this ID in the database as a numerical type. However, when the customer later requested to use the text type, for example, the original "111111", he required that it be written as "11111a" and "11111b ". At this time, because this ID has made many table foreign keys, it will cause a lot of trouble to maintain the above. Even if cascade update and cascade deletion are performed between database tables, it is still very troublesome to modify the data type.
In this RFID Project database design, I originally wanted to use the ID of the RFID tag as the primary key of the product. Because the ID of the RFID tag is unique, using it as the primary key should speed up searching. However, the problem was not that simple. If the RFID tag ID is used as the primary key, it has business significance. When the product table is associated with other tables and the primary key of the product table is used as the foreign key of other tables, if some business conditions such as the RFID tag is broken, you need to change it, the primary key content will be changed.
Looking back, I still find that my foundation is not solid. I don't go to class when I study databases. The young man does not work hard, and the boss is sad.