So many companies' projects add a prefix word to the table name when designing the table, but what is the use of this? Looking at the whole project, I didn't find this useful
Prefixing the table name was a popular way before. The current trend is to abandon adding prefixes because the benefits it brings are far less than the problems it brings. In many cases, cross-database design is more flexible and practical than table prefix design, and the confusion and problems caused by prefix design (especially in mixed situations) are the biggest trouble for many novices. So please be careful.
It’s just a design habit. It is usually created to distinguish different system tables in the same library. As shown in the picture, the table without prefix is the table of the background management system. The table with wms prefix is the table of wms system
prefix is very useful. For example, if I want to know all the tables about user, I can just show tables like '%user%', and use the mysqlcommand line to find out
Especially for projects with many plug-ins or modules, adding these prefixes is also helpful for batch processing of database tables and other operations
The prefix of the table name is just a naming convention and has no impact on function implementation.
In more complex systems, you can roughly understand the module and classification of the table through the table name prefix. This seems more convenient during daily development and operation and maintenance, and newcomers also have rules to follow when understanding the system data structure.
Personally I agree with this approach. The cost is very low, but it is convenient for later operation and maintenance. Why not do it?
When there are more than 100 tables in a project, you will understand why you need to use them.
Ideally, user_tabel1 can be written as user.table1 (to create multiple libraries) The problem is that many developers only know databases by simply adding, deleting, modifying, and checking, including many frameworks (which can only connect to one library)
For example, Oracle’s most classic scott instance. scott has a list of departments and department personnel, hr (another instance) has a list of departments. There is also a product instance that has a list of products. The hr instance has a list of scott. emp has select permission but no update permission
Personally, I feel that this design improves data security (when an instance is attacked and cracked, all data will not be exposed) and logical clarity is greatly improved, but it also requires developers to Have more understanding and mastery of the database. But what we often see is that all the tables of developers are placed in one library. The control of permissions is only controlled from the business logic.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Prefixing the table name was a popular way before. The current trend is to abandon adding prefixes because the benefits it brings are far less than the problems it brings. In many cases, cross-database design is more flexible and practical than table prefix design, and the confusion and problems caused by prefix design (especially in mixed situations) are the biggest trouble for many novices. So please be careful.
Easy to manage
It will be useful if you put multiple projects in the same database
Project 1 user table - p1_user
Project 2 user table - p2_user
You will understand once you say this
It’s just a design habit. It is usually created to distinguish different system tables in the same library.
As shown in the picture, the table without prefix is the table of the background management system. The table with wms prefix is the table of wms system
To be honest, it is more appropriate to divide different types of tables according to the database. The prefix thing is really cumbersome
The
prefix is very useful. For example, if I want to know all the tables about
user, I can justshow tables like '%user%', and use themysqlcommand line to find outEspecially for projects with many plug-ins or modules, adding these prefixes is also helpful for batch processing of database tables and other operations
Used to distinguish all projects using data tables of different projects in the same database
The prefix of the table name is just a naming convention and has no impact on function implementation.
In more complex systems, you can roughly understand the module and classification of the table through the table name prefix. This seems more convenient during daily development and operation and maintenance, and newcomers also have rules to follow when understanding the system data structure.
Personally I agree with this approach. The cost is very low, but it is convenient for later operation and maintenance. Why not do it?
When the data tables are in one database, and there are many data tables, the distinction is very straightforward
When there are more than 100 tables in a project, you will understand why you need to use them.
Ideally, user_tabel1 can be written as user.table1 (to create multiple libraries)
The problem is that many developers only know databases by simply adding, deleting, modifying, and checking, including many frameworks (which can only connect to one library)
For example, Oracle’s most classic scott instance.
scott has a list of departments and department personnel, hr (another instance) has a list of departments. There is also a product instance that has a list of products.
The hr instance has a list of scott. emp has select permission but no update permission
Personally, I feel that this design improves data security (when an instance is attacked and cracked, all data will not be exposed) and logical clarity is greatly improved, but it also requires developers to Have more understanding and mastery of the database.
But what we often see is that all the tables of developers are placed in one library. The control of permissions is only controlled from the business logic.
(The above is my personal understanding)