Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Support of DBCS DATA and SQL Extensions in a Relational Database Kernel

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

Publishing Venue

IBM

Related People

Arnold, HH: AUTHOR [+4]

Abstract

Disclosed is a method of minimizing the performance and maintenance costs of supporting Double-Byte Character Set (DBCS) data and SQL extensions in a relational database's SQL processor. To maximize performance, a separate version of some key pieces of code are created to efficiently process DBCS data. To minimize maintenance, this dual- version approach is used with a very limited amount of code.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 55% of the total text.

Page 1 of 3

Support of DBCS DATA and SQL Extensions in a Relational Database Kernel

Disclosed is a method of minimizing the performance and maintenance costs of supporting Double-Byte Character Set (DBCS) data and SQL extensions in a relational database's SQL processor. To maximize performance, a separate version of some key pieces of code are created to efficiently process DBCS data. To minimize maintenance, this dual- version approach is used with a very limited amount of code.

An SQL-based relational database product which consists in part of a run- time SQL compiler and interpreter is required to run in two separate environments: 1) PC, supporting only Single-Byte Character Set (SBCS) data, and 2) 5550, supporting mixed SBCS and DBCS data. In the 5550/DBCS environment, there are also extensions to the SQL programming language related to DBCS data, which should be considered invalid in the PC/SBCS environment.

Because the algorithms necessary for handling 5550 mixed (DBCS/ SBCS) data are much more complex than those for PC SBCS data, performance degradation is expected when mixed data can be present.

If a product is required to run in these two environments, there is a trade-off between building a single product which handles mixed data, or building two products: an SBCS-only version, and a mixed (DBCS and SBCS) version. In the first case, the SBCS environment incurs performance degradation and object code expansion, but development and maintenance costs are low. In the second case, performance and code size are optimized, but there are tremendous increases in development and maintenance costs.

The optimum solution calls for conceptually partitioning the SQL processor into: 1) the pieces which can be the same in both

environments, and

2) the pieces which must differ in order to get

proper support for the SQL language extensions, as

well as optimized performance

while attempting to maximize the first

and minimize the

second (to keep development and maintenance

costs relatively low).

At the "top" level, the SQL compiler parser must scan SQL statements to parse them and to check their syntax. Because the SQL statement may contain DBCS characters, the small (but performance critical) macro which gets the next character in the SQL statement and classifies it as letter, digit, etc., should be replaced in the DBCS version of the product.

At the "bottom" level are common data service routines which manipulate character data. These are extremely performance critical in a database product, and should be replaced in the DBCS version of the product.

1

Page 2 of 3

Between these two extremes are the following components: SQL Semantic processor, Optimizer, Code generator, Interpreter. These components must support the two ver...