Database Reference
In-Depth Information
Attribute
Name
Type of
Data
Comment
Ticket ID
Number
A unique way to identify the ticket
Subject
Text
A brief one-line statement of the problem
Descr
Text
A detailed description of the problem
The status of the ticket during processing (OPEN, PENDING,
CLOSED, and so on)
Status
Text
Created By
Text
The user who logged the ticket
Created On
Date
The date the user created the ticket
Closed On
Date
The date the ticket was closed
Assigned To
Text
The technician who is assigned to work on the ticket
Attribute Name
Type of Data
Comment
Ticket Details ID
Number
A unique way to identify this detail entry
Ticket ID
Number
Which ticket this detail is linked to
Details
Text
A text description of any details entered by the technician
Created By
Text
The user who logged the ticket
Created On
Date
The date the user created the ticket
Although it's good to try to be as detailed as possible as early as you can, you don't
have to be perfect here. You can always go back and alter or expand the data you wish
to capture as you identify other potential attributes.
System Design with APEX in Mind
Because APEX not only resides in but is built on the Oracle database, you would think
that designing database objects for APEX would be the same as designing for any other
system that uses Oracle as a data store—and in some aspects you would be right.
However, there are definitely some things you need to understand when designing for
an APEX system that will make your life much easier.
Most of what you do with APEX, at least initially, uses a series of wizards. If the
database objects are designed with APEX in mind, the wizards will do far more work
for you; therefore, you'll need to do far less fine tuning manually. The following sec-
tions discuss the most important design considerations and how they affect what the
wizards do for you.
Table Definition and User Interface Defaults
