SQL 101: SQL vs. RPG: Different Names for the Same Things

SQL
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

Is it a table or a file? SQL and RPG use different names for the same things, but (mostly) they're the same. The inaugural article of this new series tells you about the similarities and differences from an RPG programmer's perspective.

 

It's an undeniable fact that the native I/O operations RPG provides act as a filter between the programmer and the database, which doesn't exist in any other language. In most languages, there's no native set of database-related instructions, which means that the data access is performed via database-native instructions, mostly SQL.

 

In RPG, it's possible to write code for years without ever using a single SQL command. However, any RPG programmerveteran or novicemost certainly has had some contact with SQL. Whether it was to perform a simple query or to "adjust" some physical file, you've certainly been there.

 

This series of articles discusses the main SQL features, starting with the different names that RPG and SQL have for the same "things." It'll go on with a review of the data manipulation instructions that you're probably familiar with. It'll also show you ways to embed those SQL instructions in your RPG programs and a few other interesting tricks you might not know. Then it'll move to the Data Definition Language (DDL)a topic of growing importance for the future of IBM iand explain how DDL can help you modernize your applications.

 

Let me just say that I'm not an SQL expert. I am (among other things) an RPG programmer who keeps asking "Isn't there a better way to do this?" on a daily basis, trying to learn new things and apply them to my everyday life. The same thing happened with SQL: I needed easier ways to solve some problems and discovered that SQL could really help. You'll see later in this series how SQL can dramatically improve your RPG programs. But first things first…

 

What Is SQL?

SQL (pronounced "ess-que-el") stands for Structured Query Language. SQL is used to communicate with a database. According to American National Standards Institute (ANSI), it's the standard language for relational database management systems. SQL statements are used to perform tasks such as update data on a database or retrieve data from a database. Some common relational database management systems that use SQL are Oracle, Microsoft SQL Server, and, of course, IBM's DB2. Although most database systems use SQL, most of them also have their own additional proprietary extensions that are usually only used on their system. This is particularly true in the IBM i's DB2, which has a deep integration with the high-level languages (RPG, COBOL, C, etc.) supported natively. However, the standard SQL commands such as Select, Insert, Update, Delete, Create, and Drop can be used to accomplish almost everything that you need to do with a database. But before discussing these commands and their DB2 implementation, let's start with the basics.

 

Different Names for the Same Things

RPG and SQL call the same things by different names, as shown in the table below:

 

Naming Names for RPG and SQL "Things"

System (or RPG) Name

Database (or SQL) Name

Library

Collection or Schema

Physical File

Table

Non-keyed Logical File

View

Keyed Logical File, Access Path, or Index

Index

Record

Row

Field

Column

Field Reference File

Catalog

 

You may want to bookmark this page, because you'll probably come back here at least once or twice to review these concepts throughout the series. Let's go over the list, one by one:

 

A collection or schema is indeed a library, but when you create a collection in SQL, you're not creating an empty library. The database engine creates a few objects it needs: a journal, a journal receiver attached to it, and, optionally, a catalog. A schema name is used as the qualifier of SQL object names such as tables, views, indexes, and triggers, grouping them logically. Note that a schema should not be confused with an XML schema, which is a standard that describes the structure and validates the content of XML documents. To avoid this very common confusion, I'll use the term collection instead of schema whenever possible.

 

Table is probably the easiest of the lot, because it's exactly like the physical file you've been working with for years. As you'll see later in the series, it can have longer names and allows things that a physical file doesn't, but it's basically the same thing.

 

Here's where things start to get a bit murky. When asked the SQL-equivalent of a logical file, you need additional information before you're able to answer: if the logical file is just a subset of fields of one or more physical files and doesn't have a key, then it's a view in SQL lingo. A view can be thought of as having rows and columns just like a table (read: records and fields like a physical file). Whether a view can be used in an Insert, Update, or Delete operation depends on its definition, as you'll see later when I discuss the Data Definition Language (DDL).

 

If the logical file has a key, regardless of the number of fields it contains, then it's an index. Note that an access path is also an SQL index, because it uses a certain key to access the data. Just like a view, an index is created over a table. You can't create an index over a view, but a view can take advantage of an existing index when you run a Select over that view. This may sound a bit confusing right now, but hopefully it will get clearer later.

 

The data inside the table is organized in rows. There's not much else to say here, because an RPG record and an SQL row are exactly the same thing. The same goes for columns; they're just a different name for fields, even though you can do things with an SQL column that you can't do with a physical file field.

 

Finally, a catalog is a set of tables and views, maintained by the database manager, that contain information, also referred to as metadata, about the objects in the database. The catalog tables contain information about objects such as tables, views, indexes, packages, and constraints. Tables and views in the catalog are similar to any other tables and views in the database. Any user who has the permissions necessary to run a Select statement over a catalog table or view can read the data in that catalog table or view. However, a user can't directly modify a catalog table or view. The database manager ensures that the catalog contains accurate descriptions of the objects in the database at all times. The most similar concept is RPG is a field reference file, even though it falls short of the catalog concept.

 

These are the naming equivalencies that you'll need to keep in mind, because I'll use this nomenclature from this point on.

 

This concludes the inaugural article of this new series. The next article will start discussing the Data Manipulation Language (DML), with a reasonably thorough discussion of the Select SQL instruction.

 

The flow of the series is roughly mapped out, but I'm counting on your feedback to make it even better and in particular more useful to all the RPG programmers out there, even those who know a thing or two about SQL. Feel free to use the Comments section below to share your ideas, doubts, and requests!

BLOG COMMENTS POWERED BY DISQUS