Part III: pl/sql Program Data

Just about every program you write will manipulate data—and much of that data is "local" (i.e., defined in) your PL/SQL procedure or function. This part of the book concentrates exhaustively on the various types of program data you can define in PL/SQL, such as numbers, strings, records, and collections. You will learn about the new datatypes introduced in Oracle9i, such as INTERVAL, TIMESTAMP, XMLType, and others. Chapters 7 through 12 also cover the various built-in functions provided by Oracle that allow you to manipulate and modify data.

Chapter 7

Chapter 8

Chapter 9

Chapter 10

Chapter 11

Chapter 12

Chapter 7. Working with Program Data

Almost every PL/SQL block you write will define and manipulate program data. Program data consists of data structures that exist only within your PL/SQL session (physically, within the Program Global Area, or PGA, for your session); they are not stored in the database. Program data can be:

Variables or constants

The values of variables can change during a program's execution. The values of constants are static once they are set at the time of declaration.

Scalar or composite

Scalars are made up of a single value, such as a number or a string. Composite data consists of multiple values, such as a record, a collection, or an object type instance.

Containers

Containers may contain information obtained from the database, or data that was never in the database and might not ever end up there.

Before you can work with program data inside your PL/SQL code, you must declare those data structures, giving them names and datatypes.

This chapter describes how you declare program data. It covers the rules governing the format of the names you give them. It offers a quick reference to all the different types of data supported in PL/SQL and explores the concept of datatype conversion. The chapter finishes with some recommendations for working with program data. The remaining chapters in this part of the book describe specific types of program data.

7.1 Naming Your Program Data

To work with a variable or a constant you must first declare it, and when you declare it you give it a name. Here are the rules that PL/SQL insists you follow when naming your data structures (these are the same rules applied to names of database objects, such as tables and columns):

• Can be up to 30 characters in length

• Must start with a letter

• Can then be composed of any of the following: letters, numerals, $, #, and _

• All names are case-insensitive (unless those names are placed within double quotes).

Given these rules, the following names are valid:

l_total_count

first_12_years

total_#_of_trees

salary_in_$

These next three names are not only valid, but considered identical by PL/SQL because it is not a case-sensitive language:

diapers_changed_week1

DIAPERS_CHANGED_WEEK1

Diapers_Changed_Week1

The next three names are invalid, for the reasons indicated:

1st_account—Starts with a number instead of a letter

favorite_ice_cream_flavors_that_dont_contain_nuts—Too long

email_address@business_loc—Contains invalid character (@)

There are some exceptions to these rules (why are we not surprised?). If you embed a name within double quotes when you declare it, you can bypass all the above rules except the maximum length of 30 characters. For example, all of the following declarations are valid:

DECLARE

"truly_lower_case" INTEGER;

" " DATE; -- Yes, a name consisting of five spaces!

"123_go!" VARCHAR2(10);

BEGIN

"123_go!" := 'Steven';

END;

Note that when you reference these strange names in your execution section, you will need to do so within double quotes, as shown. Otherwise, your code will not compile.

Why would you use double quotes? There is little reason to do so in PL/SQL programs. It is a technique sometimes employed when creating database objects because it preserves case-sensitivity (in other words, if I CREATE TABLE "docs", then the name of the table is docs and not DOCS), but in general, you should avoid using double quotes in PL/SQL.

Another exception to these naming conventions has to do with the names of Java objects, which can be up to 4K in length. See Chapter 22 for more details about this variation and what it means for PL/SQL developers.

Here are two key recommendations for naming your variables, constants, and types:

Make sure the name accurately reflects its usage and is understandable "at a glance"

You might even take a moment to write down—in noncomputer terms—what the variable represents. You can then easily extract an appropriate name from this statement. For example, if a variable represents the "total number of calls made about lukewarm coffee," a good name for that variable might be total_calls_on_cold_coffee, or tot_cold_calls, if you are allergic to five-word variable names. A bad name for that variable would be totcoffee, or t_#_calls_lwcoff, both too cryptic to get the point across.

Establish consistent, sensible naming conventions

Such conventions usually involve the use of prefixes and/or suffixes to indicate type and usage. For example, all local variables should be prefixed with "l_" while global variables defined in packages have a "g_" prefix. All record types should have a suffix of "_rt", and so on. You can download a comprehensive set of naming conventions from O'Reilly's Oracle page at http://oracle.oreilly.com. Click on "Oracle PL/SQL Best Practices," then "Examples." The download contains a standards document for your use. (The direct URL is http://examples.oreilly.com/orbestprac/.)