Last month, I promised to show another way to generate automatic unique keys for your records. Here it is, using DB2’s ROWID data type. Keep reading to find out how it works.
The Identity column and the Sequence object, covered in the previous TechTip, are not the only ways to generate unique keys. ROWID can also be used, and, as you’ll see in a moment, it’s easy to use, but it has its caveats.
The ROWID data type is a value that uniquely identifies a row in a table. A column or host variable can have a ROWID data type. A ROWID column enables queries to be written that navigate directly to a row in the table. Each value in a ROWID column must be unique. The database manager maintains the values permanently, even across table reorganizations. When a row is inserted into the table, the database manager generates a value for the ROWID column, unless you specify one. If a value is specified, it must be a valid row ID value that was previously generated by the DB2 database engine. The internal representation of a ROWID value is transparent to the user. The value is never subject to CCSID conversion because it is considered to contain BIT data. ROWID columns contain values of the ROWID data type, which returns a 40-byte VARCHAR value that is not regularly ascending or descending.
Each table can have only one ROWID, and a row ID value can only be assigned to a column, parameter, or host variable with the same data type. For the value of the ROWID column, the column must be defined with the GENERATED BY DEFAULT or OVERRIDING SYSTEM VALUE option. A unique constraint is implicitly added to every table that has a ROWID column, which guarantees that every ROWID value is unique. In other words, a ROWID is similar to a “regular” column defined with the UNIQUE constraint or one of the code-based IDs you’re currently using in your programs. The difference is that this one, like the previous two I presented, is managed automatically by the database engine.
There’s another important difference: a ROWID operand cannot be directly compared to any data type. To compare the bit representation of a ROWID in SQL, you must first cast the ROWID to a character string. In RPG, there is no data type that directly matches with the ROWID data type. It’s possible to circumvent this issue by using the keyword SQLTYPE in the Definition specifications. This allows you to define host variables capable of holding the ROWID value. Here’s how you need to define these variables:
DCL-S MyRowID SQLTYPE(ROWID)
These are just a few of the interesting and fairly advanced SQL features you can take advantage of. I encourage you to explore DB2’s treasure trove and figure out which of its gems can help you improve your database even further.
This subseries provided an overview of the database modernization process, starting with some database theory, which included a discussion of the following topics:
- Conceptual, logical, and physical models
- Database normalization
- Entity Relationship Diagrams
Then I moved on to some of the tools that might help during the Modernization process:
- IBM Data Studio
- IBM InfoSphere Data Architect
- Adsero Optima Foundation
These two topics set the stage for the real subject of this subseries: the database modernization process. I presented an overview of the three database modernization steps process that will allow you to improve database performance, reduce the number of database-related lines of code in your programs, and increase security:
- Convert DDS files to DDL data objects
- Move business rules to the database
- Take advantage of advanced DB2 functionalities
The database modernization process is complex. This subseries provided an overview; it’s not a complete guide on how to proceed. Whole books have been written about it. Here’s a list of those I consider most useful:
- Database Fundamentals, a “DB2 on Campus” book
- Getting Started with IBM Data Studio for DB2, a “DB2 on Campus” book
- Getting Started with InfoSphere Data Architect, a “DB2 on Campus” book
- Modernizing IBM i Applications from the Database Up to the User Interface and Everything in Between, IBM Redbook SG24-8185
- Modernizing IBM eServer iSeries Application Data Access—A Roadmap Cornerstone, IBM Redbook SG24-6393
- Advanced Functions and Administration of DB2 Universal Database for iSeries, IBM Redbook SG24-4249
- Database Design and SQL for DB2, an MC Press book
- SQL for eServer i5 and iSeries, an MC Press book
- Database Db2 for i SQL Reference, Version 7.4, IBM i Manual
- Database Embedded SQL programming, Version 7.4, IBM i Manual
- DB2 Database Programming, Version 7.4, IBM i Manual
The RPG Academy Series will continue, discussing UI modernization, and it’ll use some information from these books. You don’t need to read them from top to bottom, but I can tell you from experience that the Redbooks, in particular, make quite an interesting read!