Enterprise Database Server Large Object Management via Segmented Storage
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current Database Management Systems (DMSII) lack the capability to store and manage large objects, such as large text or binary data, which are beyond the maximum length of a single database field, forcing applications to manage these objects outside the database, leading to fragile application infrastructure and the need for a uniform, reliable method for accessing and managing external large object data.
Innovation Solution
A specialized Enterprise Database Server with a Master Control Program (MCP) is developed, incorporating a Host Language Interface for ALGOL and COBOL compilers to enable users to insert, find, and delete large objects, utilizing internal tanks for storage and employing commands like ASSIGN_LOB, FIND_LOB, and DELETE_LOB to manage large binary and character objects.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If applications store large objects outside the database, then the database structure remains simple and within field limits, but the application infrastructure becomes fragile and management becomes unreliable
Solution Approach 1:
The patent introduces a Database Management System intermediary layer between applications and large objects. This intermediary provides standardized interfaces (INSERT_LOB, FIND_LOB, DELETE_LOB) that manage large objects uniformly, eliminating the need for applications to directly handle complex external file management. The intermediary absorbs the complexity while maintaining simple application code.
Solution Approach 2:
The patent creates a universal large object management mechanism that handles various types of large data (binary, character, images, audio) through a single standardized interface. The Host Language Interface works with multiple compilers (COBOL, ALGOL) to provide consistent access methods, making the system multi-functional and adaptable to different data types and application needs.
2Ease of operation
If the database supports large objects within its structure, then uniform access and management become possible, but the database field length limits are exceeded
Solution Approach 1:
The patent segments large objects into two parts: a pointer/reference stored in the database field and the actual large object data stored externally or in a separate storage area. The database field contains only the pointer (within length limits), while the full data is accessed through the Host Language Interface. This segmentation allows uniform access to large objects without exceeding field length constraints.
Solution Approach 2:
The patent implements a nested structure where the database record contains a pointer to the large object, which in turn references the actual data storage location. This nested arrangement allows the database to maintain its structural integrity with standardized fields while accommodating large objects through hierarchical reference chains.
3Adaptability or versatility
If a Host Language Interface is created for ALGOL and COBOL compilers, then existing applications can access large objects, but the system complexity increases
Solution Approach 1:
The patent performs preliminary action by pre-compiling and integrating the Host Language Interface directly into the COBOL and ALGOL compilers. This preliminary integration ensures that the interface functions (INSERT_LOB, FIND_LOB, DELETE_LOB) are automatically available to applications without requiring additional coding or configuration. The complexity is absorbed in the compiler level, making the interface transparent to application programmers.
Data Source
AI summary
An Enterprise Server Data Management System provides for the handling of large data objects (LOB) according to the data size required for the large object. Methods are provided to find a particular object that is stored or to delete such an object. But particularly the method arranges for data storage of Large Objects in a structured database, depending on the number of kilobytes forming the Large Object (LOB).