Format Agnostic Database Migration via Staging Server

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Database administrators face time-consuming and error-prone manual conversions when using migration tools to update databases, as these tools often require changes to be coded in a specific programming language, differing from the local development environment's language.

Innovation Solution

A format agnostic method utilizing a staging server that receives requests from client devices, generates migration commands based on local changes, and transmits them to a migration engine for asynchronous updates, eliminating the need for manual language conversions.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If database changes are coded in a local programming language, then ease of operation is improved, but device complexity increases due to manual conversion requirements

Engineering Contradiction:
Improveease of coding changesVSAvoidcomplexity of migration process
Core Design Contradiction:
Ease of operationVSDevice complexity

Solution Approach 1:

A language adapter is introduced as an intermediary component between the local database management system and the migration tool. The adapter receives change definitions in the local programming language and automatically translates them into the migration tool's required format, eliminating manual conversion while maintaining language flexibility.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The migration system is designed to accept change definitions in multiple programming languages through the language adapter, making the system universal. The adapter handles various local programming languages and converts them to a standardized internal representation that the migration tool can process.

Inventive Principle:
Principle #6Universality (Multi-functionality)

2Device complexity

If manual conversion of programming languages is performed, then device complexity is reduced, but loss of time increases

Engineering Contradiction:
Improvesimplicity of migration processVSAvoidtime for language conversion
Core Design Contradiction:
Device complexityVSLoss of time

Solution Approach 1:

The language adapter performs the translation action in advance, before the migration process begins. By pre-converting the change definitions from the local programming language to the migration tool's format, the system eliminates time-consuming manual conversion during the migration workflow.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system performs self-service translation through the language adapter, which automatically handles the conversion between programming languages without requiring human intervention. The adapter serves itself by interpreting the local language and generating appropriate migration commands.

Inventive Principle:
Principle #25Self-service

3Manufacturing precision

If manual adaptation of files is performed, then manufacturing precision is improved, but loss of time increases

Engineering Contradiction:
Improveaccuracy of migrationVSAvoidtime for file conversion
Core Design Contradiction:
Manufacturing precisionVSLoss of time

Solution Approach 1:

The manual mechanical process of converting programming language files is replaced with an automated computer-based translation system. The language adapter uses computational algorithms to translate between programming languages, providing consistent and accurate conversion without human error while reducing time consumption.

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

Data Source

PatentUS11741045B2Format agnostic database migration
Publication Date: 2023.08.29 GUSTO INC
  • US11741045B2 patent drawing
  • US11741045B2 patent drawing
  • US11741045B2 patent drawing

AI summary

A staging engine of a staging server receives a request to change a production database from a client device. The staging engine of the staging server accesses one or more schemas corresponding to the production database and determines one or more migration commands based on the received request and the accessed one or more schemas. The one or more migration commands correspond to a difference between a current structure of the production database and a final structure of the production database after the production database is updated. The staging engine transmits the one or more migration commands to a migration engine, wherein the migration engine asynchronously applies changes to the production database according to the one or more migration commands.