Database table import method and device, equipment and medium

Abstract

The invention relates to the field of data processing, and provides a database table import method and device, equipment and a medium. The method comprises the steps of obtaining a to-be-imported document and total project information; obtaining a first data row cell array and a first data column cell array through an Apache poi technology, and creating a database table at the same time; queryinga project basic table, and obtaining a member list from the project basic table; identifying first types through the table cell data type model, obtaining data rules matched with the first types, andobtaining first attribute table cells in the to-be-imported table; executing a data processing operation before importing through an Apache poi technology to obtain first to-be-imported data; and correspondingly importing each member identification code, each first data column cell and each first to-be-imported data into the database table according to a column type storage mode. According to themethod and the device, import of a fixed header is not needed, and a column type storage mode is adopted, so that the flexibility of data import is improved, and the workload of secondary developmentis reduced.

Description

technical field [0001] The invention relates to the technical field of data processing of big data, in particular to a method, device, equipment and medium for importing a database table. Background technique [0002] At present, the import of electronic forms is often a fixed header agreed with the demander or the user. The system develops according to the fixed header, and the user exports the template from the system, and then fills in or edits the data locally according to the template (the header cannot be changed). , when importing, the system reads the data corresponding to each column row by row by identifying each column header, and finally imports it into the database table first. However, in actual usage scenarios, users often give feedback on some special scenarios, such as table styles Cannot be unified, there are differences between the header and the agreed fixed header (even if the header is just a new column), and other scenarios, for example: in the salary ...

AI Technical Summary

Problems solved by technology

[0002] At present, the import of electronic forms is often a fixed header agreed with the demander or the user. The system develops according to the fixed header, and the user exports the template from the system, and then fills in or edits the data locally according to the template (the header cannot be changed). , when importing, the system reads the data corresponding to each column row by row by identifying each column header, and finally imports it into the database table first. However, in actual usage scenarios, users often give feedback on some special scenarios, such as table styles Cannot be unified, there are differences between the header and the agreed fixed header (even if the header is just a new column), and other scenarios, for example: in the salary distribution of the project, because a project includes many sub-projects, and each member in a project The roles in the sub-projects are different, so the salary distribution is also different, and in the project, sub-projects will be added and deleted, members will join and leave, and there will also be cases of joining or removing a class of roles Due to the situation, the table header cannot be fixed during the import process of the daily or monthly salary electronic form

At this time, because the system is not compatible with the import of different headers, it cannot meet the requirements of these special scenarios, which leads to the need to separately develop the headers corresponding to the spreadsheet for special scenarios, which increases the total amount of development work, and due to the fixed The inability to change the table header will lead to poor maintainability after the spreadsheet is generated

Images