Database trigger

A database trigger is procedural code that is automatically executed in response to certain events
on a particular table or view in a database. The trigger is mostly used for keeping the
integrity of the information on the database. For example, when a new record (representing a
new worker) is added to the employees table, new records should be created also in the
tables of the taxes, vacations, and salaries

The need and the usage

Triggers are commonly used to:

• prevent changes (e.g. prevent an invoice from being changed after it's been mailed
out)
• log changes (e.g. keep a copy of the old data)
• audit changes (e.g. keep a log of the users and roles involved in changes)
• enhance changes (e.g. ensure that every change to a record is time-stamped by the
server's clock)
• enforce business rules (e.g. require that every invoice have at least one line item)
• execute business rules (e.g. notify a manager every time an employee's bank
account number changes)
• replicate data (e.g. store a record of every change, to be shipped to another
database later)
• enhance performance (e.g. update the account balance after every detail
transaction, for faster queries)

The examples above are called Data Manipulation Language (DML) triggers because the
triggers are defined as part of the Data Manipulation Language and are executed at the
time the data is manipulated. Some systems also support non-data triggers, which fire in
response to Data Definition Language (DDL) events such as creating tables, or runtime or
and events such as logon, commit, and rollback. Such DDL triggers can be used for
auditing purposes.

The following are major features of database triggers and their effects:

• triggers do not accept parameters or arguments (but may store affected-data in

temporary tables)
• triggers cannot perform commit or rollback operations because they are part of the
triggering SQL statement (only through autonomous transactions)

Triggers in Oracle
In addition to triggers that fire when data is modified, Oracle 9i supports triggers that fire when
schema objects (that is, tables) are modified and when user logon or logoff events occur.
These trigger types are referred to as "Schema-level triggers".
Schema-level triggers

• After Creation
• Before Alter
• After Alter
• Before Drop
• After Drop
• Before Logoff
• After Logon

The four main types of triggers are:

1. Row Level Trigger: This gets executed before or after any column value of a row changes
2. Column Level Trigger: This gets executed before or after the specified column changes
3. For Each Row Type: This trigger gets executed once for each row of the result set caused
by insert/update/delete
4. For Each Statement Type: This trigger gets executed only once for the entire result set,
but fires each time the statement is executed.

Index (database)
A database index is a data structure that improves the speed of data retrieval operations on a
database table at the cost of slower writes and increased storage space. Indexes can be created
using one or more columns of a database table, providing the basis for both rapid random lookups
and efficient access of ordered records. The disk space required to store the index is typically less
than that required by the table (since indices usually contain only the key-fields according to
which the table is to be arranged, and exclude all the other details in the table), yielding the
possibility to store indices in memory for a table whose data is too large to store in memory.

In a relational database, an index is a copy of one part of a table. Some databases extend the
power of indexing by allowing indices to be created on functions or expressions. For example, an
index could be created on upper(last_name), which would only store the upper case
versions of the last_name field in the index. Another option sometimes supported is the use of
"filtered" indices , where index entries are created only for those records that satisfy some
conditional expression. A further aspect of flexibility is to permit indexing on user-defined
functions, as well as expressions formed from an assortment of built-in functions.

Indices may be defined as unique or non-unique. A unique index acts as a constraint on the table
by preventing duplicate entries in the index and thus the backing table.

Stored procedure
A stored procedure is a subroutine available to applications accessing a relational database
system. Stored procedures (sometimes called a proc, sproc, StoPro, StoredProc, or SP) are
actually stored in the database data dictionary.

Typical uses for stored procedures include data validation (integrated into the database) or access
control mechanisms. Furthermore, stored procedures are used to consolidate and centralize logic
that was originally implemented in applications. Extensive or complex processing that requires
the execution of several SQL statements is moved into stored procedures, and all applications call
the procedures. One can use nested stored procedures, by executing one stored procedure from
within another.

Cursor (databases)
In computer science and technology, a database cursor is a control structure that enables traversal
over the records in a database. Cursors facilitate subsequent processing in conjunction with the
traversal, such as retrieval, addition and removal of database records. The database cursor
characteristic of traversal make cursors akin to the programming language concept of iterator (an
arguably, if not decidedly, poorly-chosen term).

Cursors are used by database programmers to process individual rows returned by database
system queries. Cursors enable manipulation of whole result-sets at once -- a capability that most
procedural programming languages lack. In this scenario, a cursor enables the rows in a result-set
to be processed sequentially.