Reference Partitioning Framework for Database Object Lifecycle Management
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current database systems face challenges in efficiently managing lifecycle states of database objects, particularly in complex hierarchies, due to limitations in reference partitioning support, leading to slow data access and maintenance issues.
Innovation Solution
A database-agnostic framework that uses metadata definitions and triggers to implement reference partitioning across object hierarchies, enabling online lifecycle management and efficient purging or archiving of deleted objects without row-level deletes, even in databases that do not support reference partitioning.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If inactive and deleted objects are kept in the same partition as active data, then historical persistence and operational reporting are maintained, but data access performance deteriorates due to inflated cardinality
Solution Approach 1:
The patent divides the database partition into multiple segments based on lifecycle state (active, inactive, deleted). Each segment contains only objects with the corresponding lifecycle state, allowing selective access to active data while maintaining inactive and deleted objects in separate segments. This segmentation resolves the contradiction by enabling fast access to active data segments while preserving historical data in isolated segments that do not interfere with query performance.
2Productivity
If row-level deletion is used to purge deleted objects, then deleted data can be removed from the database, but significant blocking occurs in highly transactional systems slowing down overall database access
Solution Approach 1:
The patent extracts deleted objects from the active data partition and places them in a separate deleted partition. Purge operations then remove entire partitions or large batches of deleted objects at once, rather than deleting rows individually. This extraction approach eliminates the blocking problems of row-level deletes while maintaining the ability to efficiently purge deleted data.
3Adaptability or versatility
If reference partitioning is implemented in databases that do not support it, then lifecycle management capability is improved, but system complexity increases due to framework overhead
Solution Approach 1:
The patent creates a universal framework that implements reference partitioning functionality across multiple database systems, including those that do not natively support it. The framework provides a common interface and abstraction layer that handles lifecycle management uniformly across different database platforms, reducing the complexity burden by consolidating the implementation in a single reusable layer rather than requiring custom solutions for each database system.
4Speed
If off-line purging is used to remove deleted objects, then database performance is maintained, but application requirements often make off-line cleanup undesirable or impermissible
Solution Approach 1:
The patent performs preliminary actions by continuously maintaining separate partitions for active, inactive, and deleted objects during normal database operations. When purging is needed, the deleted objects are already isolated in their own partition, allowing rapid removal without requiring off-line database downtime. This preliminary organization enables on-line purging operations that maintain both performance and operational availability.
Data Source
AI summary
In one general aspect, a computer-implemented system for reference partitioning database objects by a reference field includes at least one hardware processor, at least one database environment, the database environment supporting triggers and partitioning, at least one application program, and memory storing a reference field metadata framework. The reference field metadata framework identifies classes in a hierarchy of database objects, identifies at least one class as a root of the hierarchy, identifies, for each non-root class, a reference inheritance function for the class, and identifies, for each parent class-child class pair in the hierarchy, a relation-join query, the relation-join query being a join between tables in the database environment onto which the parent class and child class are persisted. The memory also stores triggers that use the framework to maintain values for the reference field for non-root database objects.