Database Constraint Checks Using Versioned Related Records

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional constraint relationship checks in databases require locking related data records, which adversely affect database performance.

Innovation Solution

Implementing transaction version numbers for data records to enable constraint relationship checks without locking, allowing the latest related data records to be read based on current transaction version numbers, ensuring constraint validity without performance impact.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If a lock is added to a related data record during constraint relationship check, then the constraint validity is ensured, but the database performance is affected

Engineering Contradiction:
Improveconstraint validityVSAvoiddatabase performance
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent applies preliminary action by adding version numbers to data records before constraint checks are performed. This allows the system to pre-identify and read the latest version of related data records based on version comparison, eliminating the need for locking mechanisms during the constraint check process. The version number is maintained as a database field that is updated with each data modification, enabling subsequent reads to automatically obtain the correct version without blocking other operations.

Inventive Principle:
Principle #10Preliminary action

2Reliability

If the entire parent table is locked to prevent modification during constraint check, then the constraint relationship is ensured, but the database throughput is reduced

Engineering Contradiction:
Improveconstraint relationshipVSAvoiddatabase throughput
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent applies segmentation by dividing the constraint check process into independent version-comparison operations for each data record rather than locking the entire parent table. Each child record's constraint check independently reads the version number of its corresponding parent record, allowing parallel execution of multiple constraint checks without mutual interference. This segmented approach maintains constraint relationship validity while enabling high throughput through concurrent operations.

Inventive Principle:
Principle #1Segmentation

3Reliability

If a share lock is added to prevent table modification, then data integrity is maintained, but the concurrency of database operations is reduced

Engineering Contradiction:
Improvedata integrityVSAvoidoperation concurrency
Core Design Contradiction:
ReliabilityVSEase of operation

Solution Approach 1:

The patent replaces the mechanical locking system with a version-number-based identification system. Instead of using share locks that physically block other operations, the system uses version numbers to logically identify and read the latest data records. This substitution eliminates the need for lock acquisition and release operations, allowing multiple transactions to concurrently read and write data without interference, thereby maintaining data integrity through version comparison rather than mechanical blocking.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

Data Source

PatentUS12493592B2Constraint relationship check methods and apparatuses for database
Publication Date: 2025.12.09 BEIJING OCEANBASE TECHNOLOGY CO LTD
  • US12493592B2 patent drawing
  • US12493592B2 patent drawing
  • US12493592B2 patent drawing

AI summary

A computer-implemented method for a database constraint relationship check, includes performing a data manipulation language (DML) operation of a first transaction for a target data table in the database. A submission stage is entered. A corresponding current transaction version number is determined for a target data record obtained and each latest related data record visible to the first transaction is read from the target data table or an associated data table of the target data table. A mutual limitation relationship exists between field values corresponding to a target field in the target data record and each related data record. A constraint relationship check is performed on a target field value corresponding to the target field in the target data record based on each related data record. The first transaction is submitted if the constraint relationship check succeeds or the first transaction is rolled back otherwise.