Browse Prior Art Database

Storing QUERY Objects by Type in a Relational Database

IP.com Disclosure Number: IPCOM000036264D
Original Publication Date: 1989-Sep-01
Included in the Prior Art Database: 2005-Jan-28
Document File: 1 page(s) / 12K

Publishing Venue

IBM

Related People

Conner, HK: AUTHOR [+3]

Abstract

Disclosed is a methodology to store query objects in a relational database which allows duplicate object names for different object types and decreases response time for locating a specific object.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 83% of the total text.

Page 1 of 1

Storing QUERY Objects by Type in a Relational Database

Disclosed is a methodology to store query objects in a relational database which allows duplicate object names for different object types and decreases response time for locating a specific object.

Current mainframe IBM products do not allow any repetition of object names. This is because all Query objects are stored in a single data table and the object name is what makes each row unique. When each type of object is stored in a separate table for each type of object, the object name, combined with the object type (table name), can uniquely identify a row.

The user knows the object type that is required to perform the function. Therefore, the command needed to access a specific object needs to specify the object type in order to select from the proper table. This allows the user to group related objects using the same object name.

For example, a sales manager may need to see monthly sales results. A PROCEDURE named MONTHLY would be created to run a QUERY named MONTHLY and display or print a report using a FORM named MONTHLY. These three objects are all named MONTHLY, but are selected by specifying object type, object name (e.g., RUN PROC MONTHLY, RUN QUERY MONTHLY).

Performance gains can be achieved because of the separation by object type. Access times tend to become greater as the number of rows in a table increase. This is noticeable especially when the tables are not indexed and the number of rows grows....