table of Contents
1. Centralized table extension field scheme
2. Distributed table extension field scheme
0, background
When we design and complete a table, as business changes and new function requirements increase, we often need to add some fields to complete some new functions. At this time, if you don't think about it, you can directly add fields, of course.
But have we seriously considered whether all the data in the table has only a very small part of the data, this field is in the value, and in some other business scenarios, the field is empty, does each data in the table need this field? Please
ask yourself. Take a very common application case:
In an e-commerce system, you need to enter products. Some products, such as shoes, have sizes and sizes, and some products, such as food, have specifications, shelf life, and product table design. Only common fields can be included, and the data of each product is
subdivided, and the unique fields are not suitable to be placed in the product table. In this scenario, you need to consider the extended field of the table. General table extension fields can have the following two schemes: centralized and decentralized.
1. Centralized table extension field scheme
The table DDL script is as follows:
CREATE TABLE `sys_tab_ext_prop` (
`id` int(8) NOT NULL COMMENT '主键',
`table_name` varchar(255) DEFAULT NULL COMMENT '表名',
`data_id` varchar(255) DEFAULT NULL COMMENT '表中数据Id',
`property_name` varchar(255) DEFAULT NULL COMMENT '属性名',
`property_value` varchar(255) DEFAULT NULL COMMENT '属性值',
`property_remark` varchar(255) DEFAULT NULL COMMENT '属性备注',
`created_time` datetime NOT NULL COMMENT '创建时间',
`updated_time` datetime DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
PRIMARY KEY (`id`),
KEY `data_id` (`data_id`) USING BTREE COMMENT '外键索引'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='表扩展属性';The table structure is as follows:
advantage:
1. Each business table no longer pays attention to the extended field of each table. The table expansion component provides unified data storage, public API interface, and decoupling from the business table.
2. Supports the conditional search of the business table based on the extended field, but only one more connection Table query, the performance is not much different from a single table
Disadvantages:
1. Since all table extension fields are stored in this extension field table, the data volume growth rate is accelerated, which is likely to become a bottleneck
2. Distributed table extension field scheme
2.1 Multiple extension fields
The table structure is as follows:
Distributed table extension field scheme, put the extension field of the table together with the business table, and design a certain number of extension fields in advance, such as: pro1, pro2, pro3
advantage:
1. The extended fields and the basic business fields are on the same table, and the query performance is better. You can create indexes according to your needs
Disadvantages:
1. Business tables need to pay attention to the extended field of each table, and each business table needs to complete the corresponding code development work
2. The number of extension fields is not very easy to determine. Design a certain number of extension fields in advance, and you can dynamically increase the number of extension fields later
3. The business developer is required to record the content type stored in each extension field in detail, and the extension fields cannot be mixed
2.2 Json extension field
The table structure is as follows:
Distributed table extension field scheme (Json), the extension field of the table and the business table are put together, the entire ext field stores the contents of all the extension fields
advantage:
1. The extended fields are on the same table as the basic business fields, making it easier to read and write data
2. It is more convenient to add extended fields later, without modifying the database table structure
Disadvantages:
1. The extension field does not support retrieval according to a certain extension field. If you want to solve the retrieval problem, you can load the table data into ElasticSearch, and split the json format extension field into one field,
and set it as keyword in ElasticSearch Type, no word segmentation is required, so that retrieval requirements can be achieved. Do not have a fluke here ext like'%keyword%' (poor performance). If the table is large and needs
to be synchronized to ElasticSearch, please refer to another document: Synchronizing a large table technical implementation plan to avoid detours.