A data management method, system, device and storage medium

Abstract

The application discloses a data management method, system, device and storage medium, and applies to the technical field of storage. The method comprises the following steps: when detecting an operation for a target case, updating a master database based on the operation content of the operation, and recording the operation content in a log file; when a synchronization condition is met, synchronizing the data belonging to the target case in the master database to a case database corresponding to the target case; when detecting that the master database is damaged, judging whether each case database is intact by scanning each case database; if yes, reconstructing the master database based on each case database; if no, reconstructing each damaged case database based on the log file, and after the reconstruction is completed, reconstructing the master database based on all the current case databases. The scheme of the application can effectively guarantee the reliability of data.

Description

Technical Field

[0001] This invention relates to the field of storage technology, and in particular to a data management method, system, device and storage medium. Background Technology

[0002] Currently, patient information and examination records are generally stored in database files. These database files may become corrupted during forced shutdowns or other abnormal situations. To address database file corruption, a common approach is to back them up; see [link to relevant documentation]. Figure 1 Doctors use patient management software, and the relevant data is stored in the main database and backed up at fixed intervals. However, this approach can only recover data prior to the backup time. For example, if a backup is performed in the morning and the machine is used until the evening, and the main database becomes corrupted, the data from that time cannot be recovered from the backup database. This would necessitate contacting the database vendor to recover the corrupted database files, which is costly and time-consuming. Furthermore, real-time backups place high demands on the host machine's performance. In some cases, both the main and backup databases may become corrupted, making data recovery impossible.

[0003] In conclusion, ensuring data reliability is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0004] The purpose of this invention is to provide a data management method, system, device, and storage medium to effectively ensure data reliability.

[0005] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0006] In a first aspect, the present invention provides a data management method, comprising:

[0007] When an operation targeting a case is detected, the main database is updated based on the operation content, and the operation content is recorded in the log file;

[0008] When the synchronization conditions are met, the data belonging to the target case in the main database is synchronized to the case database corresponding to the target case;

[0009] When the main database is detected to be corrupted, each case database is scanned to determine whether each case database is intact.

[0010] If so, the master database is rebuilt based on each of the aforementioned case databases;

[0011] If not, the incomplete case databases are rebuilt based on the log files, and after the reconstruction is completed, the main database is rebuilt based on the current complete case database.

[0012] In one implementation, when synchronization conditions are met, data belonging to the target case in the master database is synchronized to the case database corresponding to the target case, including:

[0013] When the host's performance indicators meet the preset requirements and / or a shutdown command is detected, it is determined that the synchronization conditions are met, and the data belonging to the target case in the main database is synchronized to the case database corresponding to the target case.

[0014] In one implementation, synchronizing data belonging to the target case in the master database to the case database corresponding to the target case includes:

[0015] Before synchronization is complete, write operations to the main database are paused, and it is determined whether a case database corresponding to the target case exists.

[0016] If it does not exist, a new case database is created for the target case, and the data belonging to the target case in the main database is synchronized to the case database corresponding to the target case;

[0017] If it exists, determine whether the case database corresponding to the target case is corrupted;

[0018] If damaged, delete the damaged case database, create a new case database for the target case, and synchronize the data belonging to the target case in the main database to the case database corresponding to the target case;

[0019] If not damaged, the data belonging to the target case in the main database will be synchronized to the case database corresponding to the target case.

[0020] In one implementation, reconstructing the incomplete case databases based on the log files includes:

[0021] For any incomplete case database, identify the case corresponding to the case database;

[0022] Based on the master database identifier and the case identifier corresponding to the case, all operation records corresponding to the case are filtered out from the log file, and the case database is reconstructed by sequentially executing the operation records.

[0023] In one implementation, it further includes:

[0024] After powering on, determine if there is an incomplete case database;

[0025] If so, when the main database is not damaged, rebuild each incomplete case database based on the main database; when the main database is damaged, rebuild each incomplete case database based on the log file, and rebuild the main database based on all current case databases after the rebuild is completed.

[0026] In one implementation, it further includes:

[0027] After receiving the export instruction, determine whether there is an incomplete case database;

[0028] If so, the incomplete case databases are reconstructed based on the main database;

[0029] If not, then the main database and each of the case databases will be exported to the external device specified by the export command.

[0030] In one implementation, it further includes:

[0031] After receiving the import command, determine whether the external device pointed to by the import command stores an undamaged main database;

[0032] If so, then based on the main database in the external device, the main database in the host is updated;

[0033] If not, the main database in the external device is rebuilt based on each of the case databases in the external device, and after the reconstruction, the main database in the host is updated based on the main database in the external device.

[0034] Secondly, the present invention provides a data management system, comprising:

[0035] The main database update log recording module is used to update the main database based on the operation content when an operation targeting a target case is detected, and to record the operation content in the log file;

[0036] The case database synchronization module is used to synchronize the data belonging to the target case in the main database to the case database corresponding to the target case when the synchronization conditions are met.

[0037] The case database detection module is used to scan each case database to determine whether each case database is intact when the main database is detected to be damaged.

[0038] If so, the first reconstruction module is triggered, which is used to reconstruct the main database based on each of the case databases;

[0039] If not, the second reconstruction module is triggered. The second reconstruction module is used to rebuild the incomplete case databases based on the log files, and after the reconstruction is completed, to rebuild the main database based on the current full case database.

[0040] Thirdly, the present invention provides a data management device, comprising:

[0041] Memory, used to store computer programs;

[0042] A processor for executing the computer program to implement the steps of the data management method as described above.

[0043] Fourthly, the present invention provides a computer-readable storage medium on which a computer program is stored, wherein the computer program, when executed by a processor, implements the steps of the data management method as described above.

[0044] By applying the technical solution provided in this invention, when an operation targeting a target case is detected, the main database is updated based on the operation content. Furthermore, when synchronization conditions are met, data belonging to the target case in the main database is synchronized to the corresponding case database. In other words, data belonging to the target case is not only stored in the main database but also synchronized to the case database to ensure data reliability. This application also records the operation content in the log file to further ensure data reliability. When the main database is detected to be corrupted, scanning each case database can determine if all case databases are intact. If all are intact, the main database can be directly rebuilt based on each case database, thus achieving data recovery of the main database. If any case databases are corrupted, they can be rebuilt based on the log file, thus achieving case database recovery. After reconstruction is complete, the main database can be rebuilt based on the current total number of case databases. It can be seen that the architecture of the main database, case database, and log file effectively ensures data reliability. Furthermore, it should be noted that in this application's solution, different cases have their own corresponding case databases, meaning the case databases are distributed. This ensures that even if the main database and log files are damaged, or one or two anomalies in the case databases become unrecoverable, it does not affect the other case databases. In other words, the main database can still be rebuilt based on the remaining case databases, allowing for the recovery of as much data as possible from the main database. In summary, this application's solution effectively guarantees data reliability. Attached Figure Description

[0045] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0046] Figure 1 This is a schematic diagram of a current data management method;

[0047] Figure 2 A flowchart illustrating the implementation of a data management method according to a specific embodiment of the present invention;

[0048] Figure 3 This is a schematic diagram illustrating the principle of the database organization structure in a specific embodiment of the present invention;

[0049] Figure 4 This is a schematic diagram illustrating the principle of generating a case database based on a master database in a specific embodiment of the present invention;

[0050] Figure 5 This is a schematic diagram illustrating the principle of reconstructing a case database based on log files in a specific embodiment of the present invention;

[0051] Figure 6 This is a schematic diagram of the structure of a data management system provided in a specific embodiment of the present invention;

[0052] Figure 7 This is a schematic diagram of the structure of a data management device provided in a specific embodiment of the present invention. Detailed Implementation

[0053] The core of this invention is to provide a data management method, system, device, and storage medium that can effectively ensure data reliability.

[0054] To enable those skilled in the art to better understand the present invention, the invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0055] Please refer to Figure 2 , Figure 2 This is a flowchart illustrating an implementation of a data management method according to a specific embodiment of the present invention. The data management method may include the following steps:

[0056] Step S201: When an operation targeting a case is detected, the main database is updated based on the operation content, and the operation content is recorded in the log file.

[0057] When an operation targeting a case is detected, the operation details can be retrieved. These details typically include the operation type and case data. Operation types can be categorized as add, modify, and delete operations, and it's understood that for a new case, the first operation is a add operation. Case data can include patient information data and / or patient examination record data and / or image data. Patient information data refers to the patient's demographic information, such as name, gender, age, date of birth, height, and weight. Patient examination record data refers to information about the patient's examinations, such as the number of examinations performed, the specific areas examined, the date and time of the examination, the examining physician, the number of ultrasound images scanned, and the index data for these images. Image data consists of the patient's examination images, such as ultrasound images and endoscopic images.

[0058] In some implementations, since the host is allowed to connect to external devices such as USB flash drives, and both the host and the USB flash drive can store the main database and each case database, the operation content can also include the operation object, i.e., the database file identifier, to indicate whether the operation for the target case needs to be updated or the main database on the USB flash drive needs to be updated. By default, the main database on the host is updated.

[0059] The target case can be any case, an existing case, or a new case; different cases represent different patients.

[0060] Upon detecting an operation targeting a target case, this application's solution not only updates the main database based on the operation content but also records the operation content in the log file. Furthermore, as described above, the case data within the detected operation content can include patient information data and / or patient examination record data and / or image data. In some cases, considering the large volume of image data, the image data within the operation content can be stored in the main database and the corresponding case database, rather than being recorded in the log file. Of course, if the host's storage resources are sufficient, it is also possible to choose to record the image data in the log file; the configuration can be adjusted according to actual needs.

[0061] Step S202: When the synchronization conditions are met, synchronize the data belonging to the target case in the main database to the case database corresponding to the target case.

[0062] In this application, different cases have their own corresponding case databases, meaning the case databases are distributed. This ensures that if one or two case databases become unrecoverable, it will not affect the other case databases. Under normal circumstances, the main database contains the data content of each case database. Therefore, when the synchronization conditions are met, the data belonging to the target case in the main database needs to be synchronized to the corresponding case database, which means that a data backup for the target case is implemented in the case database.

[0063] The specific content of the synchronization conditions can be set and adjusted according to actual needs. For example, a simple approach is periodic synchronization, where the synchronization conditions are met periodically. In one specific embodiment of the invention, when the host's performance indicators meet preset requirements and / or a shutdown command is detected, it is determined that the synchronization conditions are met, and the data belonging to the target case in the main database is synchronized to the corresponding case database. This embodiment takes into account that host performance may fluctuate dynamically. When the host's performance is poor, synchronization can be temporarily suspended until the host's performance is higher. Therefore, in this embodiment, when the host's performance indicators meet preset requirements, it can be determined that the host's current performance is high, thus confirming that the synchronization conditions are met, and the data belonging to the target case in the main database can be synchronized to the corresponding case database. Furthermore, this embodiment considers that synchronization should be performed before shutdown. Therefore, if a shutdown command is detected, it can be directly determined that the synchronization conditions are met, allowing the data belonging to the target case in the main database to be synchronized to the corresponding case database before shutdown. In addition, it should be noted that in some cases, if the data belonging to the target case in the main database is not synchronized to the corresponding case database in a timely manner and the host is forcibly shut down, the synchronization conditions can be directly determined to be met upon the next power-on, and the data belonging to the target case in the main database can be synchronized to the corresponding case database.

[0064] By synchronizing the data belonging to the target case from the main database to the corresponding case database, all the data belonging to the target case is stored in both the main database and the case database of the target case, thus achieving data backup.

[0065] Furthermore, it should be noted that in this application's scheme, different cases have corresponding case databases, meaning the case databases are distributed. See also... Figure 3The diagram below illustrates the principle of the database organization structure in a specific embodiment of the present invention. Under the directory of Case 1, there is Case Database 1; under the directory of Case 2, there is Case Database 2; under the directory of Case 3, there is Case Database 3; under the directory of Case 4, there is Case Database 4; and under the directory of Case 5, there is Case Database 5. Figure 3 Taking five cases as an example, in practical applications there can be many more cases. Case database 1 stores all the data belonging to case 1, including patient information, examination records, and image data. Similarly, other case databases store the data for their respective cases. It can be seen that each case has its own case database to store or back up all its data. This structural design ensures that even if the main database and log files are damaged, or if one or two anomalies in the case database become unrecoverable, it will not affect the other case databases. In other words, when rebuilding the main database, as much data as possible can be recovered.

[0066] In one specific embodiment of the present invention, step S202, which describes synchronizing data belonging to the target case in the master database to the case database corresponding to the target case, may specifically include:

[0067] Before synchronization is complete, pause write operations to the main database and determine if a case database corresponding to the target case exists.

[0068] If it does not exist, a new case database will be created for the target case, and the data belonging to the target case in the main database will be synchronized to the case database corresponding to the target case.

[0069] If it exists, then determine whether the case database corresponding to the target case is corrupted;

[0070] If damaged, delete the damaged case database, create a new case database for the target case, and synchronize the data belonging to the target case in the main database to the case database corresponding to the target case;

[0071] If not damaged, the data belonging to the target case in the main database will be synchronized to the case database corresponding to the target case.

[0072] This implementation takes into account the possibility that other programs might read or write to the main database while synchronizing data belonging to the target case from the main database to the corresponding case database. Therefore, to avoid errors, write operations to the main database are paused before synchronization is complete, and resumed normally after synchronization is finished. During synchronization, it is necessary to first determine whether a case database corresponding to the target case exists. A simple way to determine this is to locate the target case's folder and check if the target case's case database exists in that folder. If it does not exist, it may be because this is the first time synchronizing data belonging to the target case from the main database to the target case's case database, or it may not be the first operation, but the case database in the target case's folder has been lost due to program errors or other reasons. Once it is determined that a case database corresponding to the target case does not exist, a new case database needs to be created for the target case, and the data belonging to the target case from the main database needs to be synchronized to the corresponding case database to complete the synchronization.

[0073] If a case database corresponding to the target case exists, it is also necessary to determine whether the case database is corrupted. There are several ways to achieve this; for example, CRC checksums can be used to determine if the case database is corrupted. Another implementation method can determine whether the case database can be read and written normally. If it can be read and written normally, it can be considered that the case database is not corrupted, which is convenient for implementation.

[0074] If the case database is corrupted, it needs to be deleted, a new case database for the target case needs to be created, and the data belonging to the target case in the main database needs to be synchronized to the corresponding case database. Conversely, if the case database is not corrupted, the data belonging to the target case in the main database can be directly synchronized to the corresponding case database, so that after synchronization, both the case database and the main database contain all the data belonging to the target case.

[0075] Step S203: When the main database is detected to be corrupted, scan each case database to determine if each case database is intact. If yes, proceed to step S204; otherwise, proceed to step S205.

[0076] There are several ways to detect whether the main database is corrupted. For example, it can be detected by verification. Similarly, as mentioned above, it can be detected by checking whether the case database is corrupted. In practical applications, it can be determined whether the main database can be read and written normally. If it can be read and written normally, it can be considered that the main database is not corrupted, which is convenient for implementation.

[0077] If the master database is corrupted, it needs to be rebuilt based on the individual case databases. This requires scanning each case database to determine if they are all intact. Understandably, an intact case database means it exists and is undamaged; conversely, if a case database is damaged or completely lost, it is considered incomplete. In practice, to quickly determine if all case databases are intact, the folders for each case can be traversed. If a case's folder does not contain a case database, or if a case database exists but cannot be read or written normally, then that case database is considered incomplete. Of course, in other implementations, more detailed and accurate methods can be used to determine if all case databases are intact.

[0078] Step S204: Rebuild the master database based on each case database.

[0079] If all case databases are intact, the main database can be rebuilt directly from each case database without data loss. In this case, the damaged main database can be deleted and a new main database can be created. Then, the data from each case database can be written into the main database in sequence to complete the reconstruction of the main database, which means the data recovery of the main database is achieved.

[0080] Step S205: Rebuild the incomplete case databases based on the log files, and after the reconstruction is completed, rebuild the main database based on the current complete case database.

[0081] If one or more case databases are corrupted, these corrupt case databases must be rebuilt first, and then the main database must be rebuilt based on all the case databases. For example, if there are 10,000 case databases and 10 of them are corrupted, these 10 corrupt case databases need to be rebuilt, and then the main database is rebuilt based on these 10 rebuilt case databases and the 9,990 uncorrupted case databases. As described above, when an operation targeting a case is detected, not only is the main database updated based on the operation content, but the operation content is also recorded in the log file. Therefore, when rebuilding corrupt case databases, the reconstruction can be achieved based on the log file.

[0082] Furthermore, it should be noted that, for example, if the reconstruction of a certain case database fails due to reasons such as partial loss of log files during step S205, meaning that one or two anomalies in the case database cannot be recovered, the main database can still be rebuilt based on the remaining intact case databases, as mentioned above. Figure 3As described in the application, the structural design of this solution ensures that the various case databases are independent of each other. If one or two case databases are abnormal and cannot be reconstructed through log files, it will not affect other case databases. Therefore, it is possible to recover as much data as possible from the main database.

[0083] In one specific embodiment of the present invention, step S205, which describes rebuilding the incomplete case databases based on log files and, after the reconstruction is completed, rebuilding the main database based on the current complete case database, may specifically include:

[0084] For any incomplete case database, identify the case that corresponds to the case database.

[0085] Based on the master database identifier and the case identifier corresponding to the case, all operation records corresponding to the case are filtered out from the log file, and the case database is rebuilt by executing the operation records in sequence. After the reconstruction is completed, the master database is rebuilt based on the current full case database.

[0086] Taking Case 1 as an example, if Case Database 1 in the folder containing Case 1 is missing, it can be determined that Case Database 1 is an incomplete case database. When rebuilding Case Database 1, it can be confirmed that the case corresponding to Case Database 1 is Case 1. Next, it is necessary to filter out all operation records corresponding to Case 1 from the log files. This can be determined based on the master database identifier and the case identifier. The master database identifier is usually the ID of the master database; however, in other specific situations, it can be other types of identifiers, as long as they can be used to uniquely distinguish whether a log entry belongs to an operation record in the master database. Using the master database identifier, all operation records related to the master database can be filtered out from the log files. Similarly, the case identifier corresponding to a case is usually the ID of the case; however, in other specific situations, it can be other types of identifiers, as long as they can be used to uniquely distinguish whether a log entry belongs to an operation record of a specific case. In this example, using the case identifier corresponding to Case 1, all operation records related to Case 1 can be further filtered out from all operation records related to the master database. After obtaining all operation records for Case 1, these operation records need to be executed in chronological order to complete the reconstruction of the case database for Case 1. After the individual incomplete case databases have been rebuilt, the main database can be rebuilt based on the current complete case database.

[0087] See also Figure 4 This is a schematic diagram illustrating the principle of generating a case database based on a master database in a specific embodiment of the present invention. After updating the master database based on the operation content, when the synchronization conditions are met, the data belonging to the target case in the master database can be synchronized to the case database corresponding to the target case. Figure 5This is a schematic diagram illustrating the principle of reconstructing a case database based on log files in a specific embodiment of the present invention. When the case database is lost or damaged, it can be reconstructed based on log files.

[0088] In one specific embodiment of the present invention, it may further include:

[0089] After powering on, determine if there is an incomplete case database;

[0090] If so, when the main database is intact, rebuild each incomplete case database based on the main database; when the main database is damaged, rebuild each incomplete case database based on the log files, and rebuild the main database based on all current case databases after the rebuild is complete.

[0091] This implementation takes into account that the main database is frequently read and written, so damage to the main database is relatively easy to detect. However, some case databases may not need to be read or written for a long time. Therefore, in order to detect the loss or damage of the case database in a timely manner, this implementation automatically determines whether there is an incomplete case database every time the system is turned on, so as to ensure that the incomplete case database can be detected in time and rebuilt, which effectively improves the data reliability of the solution in this application.

[0092] If there are incomplete case databases, and the main database is not damaged, the incomplete case databases can be rebuilt directly based on the main database. If the main database is also damaged, the incomplete case databases need to be rebuilt based on the log files first, and then the main database needs to be rebuilt based on the current complete case database after the reconstruction is completed.

[0093] In one specific embodiment of the present invention, it may further include:

[0094] After receiving the export instruction, determine whether there is an incomplete case database;

[0095] If so, the incomplete case databases will be reconstructed based on the master database;

[0096] If not, export the main database and each case database to the external device specified by the export command.

[0097] In this implementation, the master database and individual case databases can be exported to external devices, such as USB flash drives or hard disks, to achieve offline backup and storage of data. Upon receiving the export command, it is necessary to determine if any incomplete case databases exist on the host machine. If not, the export can begin, meaning both the master database and each case database on the host machine can be exported to the external device. If incomplete case databases exist, the data corresponding to that case database needs to be read from the master database on the host machine and written to that case database, thus completing the reconstruction of that case database. After the reconstruction of each incomplete case database is completed, the export can begin, meaning both the master database on the host machine and each case database can be exported to the external device.

[0098] Furthermore, it should be noted that since corruption of the master database is easily triggered and will immediately rebuild the master database, in practical applications, master database corruption is usually not an issue during export. Of course, in specific situations, after receiving an export command, to avoid errors, it can be determined whether the master database is corrupted. If it is corrupted, the master database can be rebuilt according to the procedures in steps S203 to S205 above, and then the master database and each case database can be exported to the external device.

[0099] In one specific embodiment of the present invention, it may further include:

[0100] After receiving the import command, determine whether the external device pointed to by the import command stores an undamaged main database;

[0101] If so, the data in the host machine's main database is updated based on the main database in the external device;

[0102] If not, the main database in the external device is rebuilt based on the case databases in the external device, and after the reconstruction, the main database in the host is updated based on the main database in the external device.

[0103] In this implementation, the data content in the host computer can be updated based on the data content in the external device. For example, if the data content in the external device is the latest, while the relevant data content in the host computer is older, this implementation method can be used to update the host computer data. Similarly, if all the data in the host computer is lost, this implementation method can be used to recover the data in the host computer.

[0104] Specifically, in this implementation, after receiving the import command, it needs to determine whether an intact master database is stored in the external device pointed to by the import command. If it exists, it means that the data in the host needs to be updated based on the data in the external device. Therefore, the master database in the host can be updated based on the master database in the external device, that is, the master database in the external device overwrites the master database in the host. If the master database in the external device is lost or damaged, it may be due to reasons such as accidental deletion by the user. In this case, the master database in the external device can be rebuilt based on the individual case databases in the external device. In addition, in some implementations, a selection function can be set to prompt the user whether to perform the reconstruction of the master database. If the user clicks to perform the reconstruction of the master database, the master database in the external device will be rebuilt based on the individual case databases in the external device. After the master database in the external device is rebuilt, the master database in the host can be updated based on the master database in the external device.

[0105] By applying the technical solution provided in this invention, when an operation targeting a target case is detected, the main database is updated based on the operation content. Furthermore, when synchronization conditions are met, data belonging to the target case in the main database is synchronized to the corresponding case database. In other words, data belonging to the target case is not only stored in the main database but also synchronized to the case database to ensure data reliability. This application also records the operation content in the log file to further ensure data reliability. When the main database is detected to be corrupted, scanning each case database can determine if all case databases are intact. If all are intact, the main database can be directly rebuilt based on each case database, thus achieving data recovery of the main database. If any case databases are corrupted, they can be rebuilt based on the log file, thus achieving case database recovery. After reconstruction is complete, the main database can be rebuilt based on the current total number of case databases. It can be seen that the architecture of the main database, case database, and log file effectively ensures data reliability. Furthermore, it should be noted that in this application's solution, different cases have their own corresponding case databases, meaning the case databases are distributed. This ensures that even if the main database and log files are damaged, or one or two anomalies in the case databases become unrecoverable, it does not affect the other case databases. In other words, the main database can still be rebuilt based on the remaining case databases, allowing for the recovery of as much data as possible from the main database. In summary, this application's solution effectively guarantees data reliability.

[0106] Corresponding to the above method embodiments, this invention also provides a data management system, which can be referred to in conjunction with the above.

[0107] See Figure 6 The diagram shown is a structural schematic of a data management system according to the present invention, comprising:

[0108] The main database update log recording module 601 is used to update the main database based on the operation content when an operation targeting a target case is detected, and to record the operation content in the log file.

[0109] The case database synchronization module 602 is used to synchronize data belonging to the target case in the main database to the case database corresponding to the target case when the synchronization conditions are met.

[0110] The case database detection module 603 is used to scan each case database to determine whether each case database is intact when the main database is detected to be damaged.

[0111] If so, the first reconstruction module 604 is triggered. The first reconstruction module 604 is used to reconstruct the main database based on each case database.

[0112] If not, the second reconstruction module 605 is triggered. The second reconstruction module 605 is used to rebuild the incomplete case databases based on the log files, and after the reconstruction is completed, rebuild the main database based on the current complete case database.

[0113] In one specific embodiment of the present invention, the case database synchronization module 602 is specifically used for:

[0114] When the host's performance metrics meet the preset requirements and / or a shutdown command is detected, the synchronization conditions are determined to be met, and the data belonging to the target case in the main database is synchronized to the case database corresponding to the target case.

[0115] In one specific embodiment of the present invention, the case database synchronization module 602 is specifically used for:

[0116] When the synchronization conditions are met, pause write operations to the main database before synchronization is completed, and determine whether there is a case database corresponding to the target case.

[0117] If it does not exist, a new case database will be created for the target case, and the data belonging to the target case in the main database will be synchronized to the case database corresponding to the target case.

[0118] If it exists, then determine whether the case database corresponding to the target case is corrupted;

[0119] If damaged, delete the damaged case database, create a new case database for the target case, and synchronize the data belonging to the target case in the main database to the case database corresponding to the target case;

[0120] If not damaged, the data belonging to the target case in the main database will be synchronized to the case database corresponding to the target case.

[0121] In one specific embodiment of the present invention, the second reconstruction module 605 is specifically used for:

[0122] For any incomplete case database, identify the case that corresponds to the case database.

[0123] Based on the master database identifier and the case identifier corresponding to the case, all operation records corresponding to the case are filtered out from the log file, and the case database is rebuilt by executing the operation records in sequence. After the reconstruction is completed, the master database is rebuilt based on the current full case database.

[0124] In one specific embodiment of the present invention, a power-on verification module is further included, used for:

[0125] After powering on, determine if there is an incomplete case database;

[0126] If so, if the main database is not damaged, rebuild each incomplete case database based on the main database; if the main database is damaged, rebuild each incomplete case database based on the log files, and rebuild the main database based on the current full case database after the rebuild is completed.

[0127] In one specific embodiment of the present invention, an export module is further included, used for:

[0128] After receiving the export instruction, determine whether there is an incomplete case database;

[0129] If so, the incomplete case databases will be reconstructed based on the main database;

[0130] If not, export the main database and each case database to the external device specified by the export command.

[0131] In one specific embodiment of the present invention, an import module is further included, used for:

[0132] After receiving the import command, determine whether the external device pointed to by the import command stores an undamaged main database;

[0133] If so, the data in the host machine's main database is updated based on the main database in the external device;

[0134] If not, the main database in the external device is rebuilt based on the individual case databases in the external device, and after the reconstruction, the main database in the host is updated based on the main database in the external device.

[0135] Corresponding to the above methods and system embodiments, this invention also provides a data management device and a computer-readable storage medium, which can be referred to in conjunction with the above description.

[0136] See Figure 7 As shown, the device may include:

[0137] Memory 701 is used to store computer programs;

[0138] Processor 702 is configured to execute a computer program to implement the steps of the data management method as described in any of the above embodiments.

[0139] The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the data management method as described in any of the above embodiments. The computer-readable storage medium referred to herein includes random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0140] It should also be noted that, in this application, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0141] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this application can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this invention. Specific examples have been used in this application to illustrate the principles and implementation methods of the invention. The description of the above embodiments is only for the purpose of helping to understand the technical solution and core ideas of the invention. It should be noted that those skilled in the art can make several improvements and modifications to the invention without departing from the principles of the invention, and these improvements and modifications also fall within the protection scope of the invention.

Claims

1. A data management method, characterized in that, include: When an operation targeting a case is detected, the main database is updated based on the operation content, and the operation content is recorded in the log file; When the synchronization conditions are met, the data belonging to the target case in the main database is synchronized to the case database corresponding to the target case; When the main database is detected to be corrupted, each case database is scanned to determine whether each case database is intact. If so, the master database is rebuilt based on each of the aforementioned case databases; If not, the incomplete case databases are rebuilt based on the log files, and after the reconstruction is completed, the main database is rebuilt based on the current complete case database.

2. The data management method according to claim 1, characterized in that, When the synchronization conditions are met, the data belonging to the target case in the main database is synchronized to the case database corresponding to the target case, including: When the host's performance indicators meet the preset requirements and / or a shutdown command is detected, the synchronization condition is determined to be met, and the data belonging to the target case in the main database is synchronized to the case database corresponding to the target case.

3. The data management method according to claim 1, characterized in that, Synchronizing the data belonging to the target case in the master database to the case database corresponding to the target case includes: Before synchronization is complete, write operations to the main database are paused, and it is determined whether a case database corresponding to the target case exists. If it does not exist, a new case database is created for the target case, and the data belonging to the target case in the main database is synchronized to the case database corresponding to the target case; If it exists, determine whether the case database corresponding to the target case is corrupted; If damaged, delete the damaged case database, create a new case database for the target case, and synchronize the data belonging to the target case in the main database to the case database corresponding to the target case; If not damaged, the data belonging to the target case in the main database will be synchronized to the case database corresponding to the target case.

4. The data management method according to claim 1, characterized in that, Reconstructing the incomplete case databases based on the log files includes: For any incomplete case database, identify the case corresponding to the case database; Based on the master database identifier and the case identifier corresponding to the case, all operation records corresponding to the case are filtered out from the log file, and the case database is reconstructed by sequentially executing the operation records.

5. The data management method according to claim 1, characterized in that, Also includes: After powering on, determine if there is an incomplete case database; If so, when the main database is not damaged, rebuild each incomplete case database based on the main database; when the main database is damaged, rebuild each incomplete case database based on the log file, and rebuild the main database based on all current case databases after the rebuild is completed.

6. The data management method according to any one of claims 1 to 5, characterized in that, Also includes: After receiving the export instruction, determine whether there is an incomplete case database; If so, the incomplete case databases are reconstructed based on the main database; If not, then the main database and each of the case databases will be exported to the external device specified by the export command.

7. The data management method according to claim 6, characterized in that, Also includes: After receiving the import command, determine whether the external device pointed to by the import command stores an undamaged main database; If so, then based on the main database in the external device, the main database in the host is updated; If not, the main database in the external device is rebuilt based on each of the case databases in the external device, and after the reconstruction, the main database in the host is updated based on the main database in the external device.

8. A data management system, characterized in that, include: The main database update log recording module is used to update the main database based on the operation content when an operation targeting a target case is detected, and to record the operation content in the log file; The case database synchronization module is used to synchronize the data belonging to the target case in the main database to the case database corresponding to the target case when the synchronization conditions are met. The case database detection module is used to scan each case database to determine whether each case database is intact when the main database is detected to be damaged. If so, the first reconstruction module is triggered, which is used to reconstruct the main database based on each of the case databases; If not, the second reconstruction module is triggered. The second reconstruction module is used to rebuild the incomplete case databases based on the log files, and after the reconstruction is completed, to rebuild the main database based on the current full case database.

9. A data management device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the data management method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the data management method as described in any one of claims 1 to 7.

Images