1. Subqueries, Views, Stored Procedures, Triggers, Transactions
Subqueries
A subquery is a SELECT statement that is placed within parentheses inside another SQL
statement. (Generally, a subquery can be replicated with a JOIN, or vice versa.) However,
using subqueries can assist in understanding the SQL statement. For instance, when using
keywords like “IN” and “ANY” to assist in understanding.
A noncorrelated subquery is a subquery that is independent of the outer query and it can be
executed on its own without relying on main outer query.
Noncorrelated subquery: can run by itself. Here, the isolated subquery would yield a list
of the CustomerIDs of customers from NJ.
Example: list all customers with an address in New Jersey:
SELECT Name
FROM Customers
WHERE CustomerID = ANY
(SELECT CustomerID FROM AddressBook WHERE State = ‘NJ’);
Subquery is in WHERE clause:
(SELECT CustomerID FROM AddressBook WHERE State = ‘NJ’)
Correlated subquery: contains references to values in the outer query, and can not be
evaluated independently of that outer query. It is an inner subquery which is referenced by
the main outer query such that the inner query is considered as being executed repeatedly.
Example:
SELECT * FROM t1 WHERE column1 = ANY
(SELECT column1 FROM t2 (no ref to t1 here) WHERE t2.column2 = t1.column2);
Notice how the table t1 is referenced in the WHERE clause of the subquery even though it
it’s not named in the FROM clause of the subquery itself; it only exists in the outer
query. If you were to execute just the isolated subquery in this case, you would receive an
error.
In summary: a correlated subquery is a subquery that contains a reference to a table that
also appears in the outer query—cannot run by itself.
Note: Subtle distinction between ALL and ANY. If subquery is empty then ALL always
returns True, whereas the ANY returns False.
The result of either SubQuery is a result set. The outer query tests whether CustomerID
(noncorrelated subquery) or column1 (correlated subquery) are equal to ANY of the values
retrieved by the SubQuery. If CustomerID or column1 are equal to at least one of the
values retrieved by the subquery, then = ANY is true.
The ALL keyword specifies that the search condition is TRUE if the comparison is TRUE for
every value that the subquery returns. If the subquery returns no value, the condition is
TRUE.
2. The ANY keyword denotes that the search condition is TRUE if the comparison is TRUE for
at least one of the values that is returned. If the subquery returns no value, the search
condition is FALSE. The SOME keyword is a synonym for ANY.
Views
Advantages:
• Security: restricts user access to stored data
• Simplify complex schemas and/or queries
• Insulation from change: “frozen” image of data when created, even when data
source changes
Disadvantages:
• Performance: must translate queries against the view into queries against the
underlying source tables—the problem is that a simple view may contain a complex
query (and various joins) that take time and processing power to perform.
• Manageability: Like other database objects, wiews must be managed. Users with the
ability to create views make the DBA’s job more difficult—especially when trying to
resolve problems with views that reference other views.
• Update restrictions: some views are updateable, others are not. Depends upon the
DBMS restrictions, and well as the restrictions on views.
Example:
CREATE TABLE employee
(
empid INT(4) not null auto_increment,
fname VARCHAR(15),
lname VARCHAR(20),
salary decimal(8,2),
ssn CHAR(9),
primary key (empid)
);
INSERT INTO employee
VALUES
(NULL,'Doe','John',103590.00,'123456789');
/* Do not show salary or ssn */
CREATE VIEW v_empinfo
AS
SELECT empid, fname, lname
FROM employee;
3. Views vs. Tables:
mysql> SELECT * FROM v_empinfo;
+-------+-------+-------+
| empid | fname | lname |
+-------+-------+-------+
| 1 | Doe | John |
+-------+-------+-------+
1 row in set (0.00 sec)
mysql> select empid from v_empinfo;
+-------+
| empid |
+-------+
| 1 |
+-------+
1 row in set (0.01 sec)
mysql> select ssn from v_empinfo;
ERROR 1054 (42S22): Unknown column 'ssn' in 'field list'
mysql> select ssn from employee;
+-----------+
| ssn |
+-----------+
| 123456789 |
+-----------+
1 row in set (0.00 sec)
drop view if exists v_emp_info;
Stored Procedures
Definition: A stored procedure, by definition, is a segment of declarative SQL code which is
stored in the database catalog and can be invoked later by a program, a trigger or even
another stored procedure.
A stored procedure, which calls itself, is recursive stored procedure. Most DMBSs support
recursive stored procedures but (right now) MySQL does not support it.
Advantages:
• Increases runtime performance. Once created, a stored procedure is compiled and
stored in the database catalog. It runs faster than uncompiled SQL statements which
are sent from a client application
• Reduce network traffic: Instead of sending multiple uncompiled SQL statements, the
client application only has to send the stored procedure name.
• Reusability: may be called and reused by any application which wants to use it (with
appropriate permissions). Stored procedure exposes the database interface to all
applications so developer doesn’t have to program the functionality which is already
supported in a stored procedure available to all programs.
• Security. Database administrator can grant rights to access individual stored
procedures, without granting permissions to the underlying database tables.
• Simplicity of access: simple call to stored procedure, rather than elaborate SQL
statements.
• Encapsulation: hide data structures, values, and access to data.
• Business Rules Enforcement: can contain logic to check data constraints
4. Disadvantages:
• Stored procedures make the database server high load in both memory and
processing. Instead of focusing on storing and retrieving data, the server could be
required to perform a number of complex business operations, which is generally not
the role of the server.
• Stored procedures only contain declarative SQL, so it is very difficult to write a
procedure with complex business logic like that in other languages at the application
layer such as Java, C#, C++, etc.
• You cannot debug stored procedures most DMBSs.
• Writing and maintaining stored procedures is a specialized skill set that not all
developers possess.
Example: drop and add new employee table
drop table if exists employee;
CREATE TABLE employee
(
empid INT(4) not null auto_increment,
fname VARCHAR(15),
lname VARCHAR(20),
salary decimal(8,2),
ssn CHAR(9),
primary key (empid)
);
INSERT INTO employee
VALUES
(NULL,'Doe','John',103590.00,'123456789');
INSERT INTO employee
VALUES
(NULL,'Doe','Jane',103590.00,'234567890');
INSERT INTO employee
VALUES
(NULL,'Doe','John Jr.',3590.00,'345678901');
Create stored procedure (must change delimiter, see below):
CREATE PROCEDURE sp_mysp()
BEGIN
SELECT round(avg(salary), 2) AS avgsal
FROM employee;
update employee set salary = salary * 1.03 where empid < 3;
SELECT round(avg(salary), 2) AS avgsal
FROM employee;
END;
• Analysis
Give 3% raise…
The stored procedure is named sp_mysp and is thus defined with the statement CREATE
PROCEDURE sp_mysp(). Had the stored procedure accepted parameters, these would have
been enumerated between the parentheses ( ... ). This stored procedure has no
parameters, but the trailing () is still required. BEGIN and END statements are used to
5. delimit the stored procedure body (required for multiple statements), and the body itself is
just a simple SELECT statement (using the ROUND() and Avg() functions.
When MySQL processes this code it creates a new stored procedure named sp_mysp. No
data is returned because the code does not call the stored procedure, it simply creates it for
future use. An explicit call to the stored procedure is required for it to be invoked.
Note: The default MySQL statement delimiter is “;”. However, the mysql command-line
utility also uses ; as a delimiter. If the command-line utility were to interpret the semicolon
characters (;) inside of the stored procedure itself, those would not end up becoming part of
the stored procedure, and that would make the SQL in the stored procedure syntactically
invalid.
The solution is to temporarily change the command-line utility delimiter, as seen here:
DELIMITER //
DROP PROCEDURE IF EXISTS sp_mysp;
CREATE PROCEDURE sp_mysp()
BEGIN
SELECT round(avg(salary), 2) AS avgsal
FROM employee;
update employee set salary = salary * 1.03 where empid < 3;
SELECT round(avg(salary), 2) AS avgsal
FROM employee;
END //
DELIMITER ;
The example uses the mysql client delimiter command to change the statement delimiter
from ; to // while the procedure is being defined. This enables the ; delimiter used in the
procedure body to be passed through to the server rather than being interpreted by mysql
itself.
Also, DELIMITER // tells the command-line utility to use // as the new end of statement
delimiter, and you will notice that the END that closes the stored procedure is defined as
END // instead of the expected END;. This way the ; within the stored procedure body
remains intact and is correctly passed to the database engine. And then, to restore things
back to how they were initially, the statement closes with a DELIMITER ;.
Any character may be used as the delimiter except for .
If you are using the mysql command-line utility, keep this in mind as you work through this
tutorial.
6. So how would you use this stored procedure? Like this:
• Input (when arguments are used)/Output
mysql> call sp_mysp();
+----------+
| avgsal |
+----------+
| 70256.67 |
+----------+
1 row in set (0.00 sec)
• Analysis
CALL sp_mysp(); executes the stored procedure and displays returned result. As a stored
procedure is actually a type of function, () characters are required after the stored
procedure name (even when no parameters are being passed).
Dropping Stored Procedures
After they are created, stored procedures remain on the server, ready for use, until
dropped. The drop command (similar to tables) removes the stored procedure from the
server.
To remove the stored procedure, use the following statement (Notice that the trailing () are
not used):
DROP PROCEDURE IF EXISTS sp_mysp;
Note: To delete a procedure if it exists (and not throw an error if it does not), use DROP
PROCEDURE IF EXISTS.
Views vs. Stored procedures
Stored procedure:
• accepts parameters
• can NOT be used as building block in a larger query
• can contain several statements, loops, IF ELSE, etc.
• can perform modifications to one or several tables
• can NOT be used as the target of an INSERT, UPDATE or DELETE statement.
View:
• does NOT accept parameters
• can be used as building block in a larger query
• can contain only one single SELECT query
• (usually) does NOT perform modifications to any table
• but can (sometimes with limitations, see below) be used as the target of an INSERT,
UPDATE or DELETE statement.
Example:
This is ok…
CREATE VIEW v_empinfo
AS
SELECT empid, fname, lname
FROM employee;
This is NOT…
7. CREATE VIEW v_empinfo2
AS
update employee set salary = salary * 1.03 where empid < 3;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual
that corresponds to your MySQL server version for the right syntax to use
near 'update employee set salary = salary * 1.03 where empid < 3' at line 3
mysql>
18.4.3. Updatable and Insertable Views:
http://dev.mysql.com/doc/refman/5.0/en/view-updatability.html
Some views are updatable. That is, you can use them in statements such as UPDATE, DELETE, or
INSERT to update the contents of the underlying table. For a view to be updatable, there must be a
one-to-one relationship between the rows in the view and the rows in the underlying table. There are
also certain other constructs that make a view nonupdatable. To be more specific, a view is not
updatable if it contains any of the following:
• Aggregate functions (SUM(), MIN(), MAX(), COUNT(), and so forth)
• DISTINCT
• GROUP BY
• HAVING
• UNION or UNION ALL
• Subquery in the select list
• Certain joins (see additional join discussion later in this section)
• Nonupdatable view in the FROM clause
• A subquery in the WHERE clause that refers to a table in the FROM clause
• Refers only to literal values (in this case, there is no underlying table to update)
• Uses ALGORITHM = TEMPTABLE (use of a temporary table always makes a view
nonupdatable)
• Multiple references to any column of a base table.
• … etc., etc., etc..
Triggers
An SQL trigger is an SQL statement or a set of SQL statements which is/are stored to be
activated or fired when an event associated with a database table occurs. The event can be
any event including INSERT, UPDATE, and DELETE actions.
8. The difference between a trigger and a stored procedure is that a trigger is activated or
called (fired) when an event occurs in a database table, a stored procedure must be called
explicitly. For example, some business logic may be invoked before or after inserting a new
record in a database table.
Advantages:
• Provides an alternative way to check integrity.
• Can catch errors in business logic.
• Business rules enforced with changes made to the database.
• Provides an alternative way to run scheduled tasks. Don’t have to wait to run
scheduled tasks. Handle tasks before or after changes made to database tables.
• Useful when you use it to audit changes of data in a database table.
9. Disadvantages:
• Can provide extended validation, but cannot replace all validation rules. Some simple
validations can be done in the application level. For example, you can validate input
check in the client side by using javascript or in the server side by server script using
PHP or ASP.NET.
• Executes invisibly from client-application which connects to the database server so it
is difficult to figure out what happens to the underlying database layer.
• Run with changes made to their associated tables, therefore it adds an additional
workload to the server and can cause systems to run more slowly.
Triggers or stored procedures? It depends on the situation.
When creating a trigger you need to specify four pieces of information:
1. Unique trigger name
2. Table to which the trigger is to be associated
3. Action that the trigger should respond to (DELETE, INSERT, or UPDATE)
4. When the trigger should be executed (before or after processing)
Tip:
Keep Trigger Names Unique per Database. In MySQL 5, trigger names must be unique per
table, but not per database. This means that two tables in the same database can have
triggers of the same name. This is not allowed in other DBMSs where trigger names must be
unique per database, and it is very likely that MySQL will make the naming rules stricter in a
future release. As such, it is a good idea to use database-wide unique trigger names now.
1. Trigger event, can be INSERT, UPDATE, DELETE
2. Trigger activation time, can be AFTER or BEFORE event
3. Trigger table (which table will be affected)
4. Trigger body (SQL statements)
Example:
Every time an administrator adds a new inventory record, insertion data will be logged to a
separate table (log), including administrator’s MySQL username, suitable notes (e.g.,
“recorded added”), and a modification time stamp.
Create inventory table:
drop table if exists inventory;
create table inventory
(
invent_id int (4) not null auto_increment,
item_desc varchar(30),
notes varchar(100),
primary key (invent_id)
);
Create log table:
drop table if exists log;
create table log
(
user varchar(30),
comment varchar(50),
mod_time timestamp
);
10. Create trigger:
drop trigger if exists trg_inventory_mod;
create trigger trg_inventory_mod
AFTER INSERT on inventory
for each row
insert into log (user, comment, mod_time)
values (current_user(), "record added", now());
Add new inventory record:
insert into inventory(invent_id, item_desc, notes)
values (null, "vacuum", "first item stocked");
Display log table:
mysql> select * from log;
+-------------------+----------------+---------------------+
| user | comment | mod_time |
+-------------------+----------------+---------------------+
| mjowett@localhost | recorded added | 2010-02-28 18:56:04 |
+-------------------+----------------+---------------------+
1 row in set (0.02 sec)
show triggers;
Triggers are created using the CREATE TRIGGER statement.
• Analysis:
CREATE TRIGGER is used to create the new trigger named trg_inventory_mod. Triggers can
be executed before or after an operation occurs, and here AFTER INSERT is specified so the
trigger will execute after a successful INSERT statement has been executed. The trigger
then specifies FOR EACH ROW and the code to be executed for each inserted row. In this
example, user modification info will be inserted into the log table, for each row inserted into
the inventory table.
To test this trigger, use the INSERT statement to add one or more rows to inventory; then
check and select all the records in the log table.
Note:
Triggers are only supported on tables, not on views (or temporary tables).
Triggers are defined per time, per event, per table, and only one trigger per time, per
event, per table is allowed. As such, up to six triggers are supported per table (before and
after each of INSERT, UPDATE, and DELETE). A single trigger cannot be associated with
multiple events or multiple tables, so if you need a trigger to be executed for both INSERT
and UPDATE operations, you'll need to define two triggers.
11. Transactions
One or more SQL statements that form a logical unit of work.
• Any action that reads/writes (including deletes) data from DB.
• Only work with DML statements: (select, update, insert, delete ...), affect "data."
• NOT with DDL statements: (create, drop, alter ...), affect db structure.
The statements in a transaction will be executed as an atomic unit of work in the database.
Either the results of all of the statements will be applied to the database, or none of the
statements will have results posted to the database.
ANSI (American National Standards Institute) SQL database transactions support:
Two SQL statements: COMMIT and ROLLBACK
General syntax, MySQL commands for transactions (require BEGIN or START
TRANSACTION):
1. BEGIN (or START TRANSACTION) ("end" is either commit or rollback)
2. COMMIT: Makes changes permanent
3. ROLLBACK: Cancels updates since last COMMIT
ACIDS-compliant DBMS:
1) ATOMICITY:
• Each transaction treated indivisible unit.
• All statements within transaction must be successful for transaction to be considered
successful.
• If transaction failure, system returned to pre-transaction (consistent) state.
Example: following statements treated as one logical unit of work
START TRANSACTION;
select ...
update ...
insert ...
delete ...
COMMIT;
2) CONSISTENCY:
• Once transaction completed, system must be in consistent state.
• If any integrity constraints fail (e.g., domain constraints, entity/referential integrity
constraints, etc.). Transaction aborted (rolled back).
Example: if any statement fails, entire transaction aborted
START TRANSACTION;
select ... (uses incorrect syntax)
update ...
insert ...
delete ...
COMMIT;
3) ISOLATION:
• Changes made by transaction invisible to other transactions (users) while in
progress.
12. • Data used for one transaction cannot be used by another transaction until first
transaction completed.
Example:
Connection 1:
START TRANSACTION;
insert into transaction (id) values (2);
select * from transaction; -- Connection 1 sees new data.
Connection 2:
SELECT * FROM transaction; -- Connection 2 does NOT (prior to COMMIT)
4) DURABILITY:
• Changes to the database persist.
• If transaction committed cannot be rolled back.
Example: Committed statements persist
START TRANSACTION;
select ...
update ...
insert ...
delete ...
COMMIT;
ROLLBACK; (cannot rollback, even if power failure after COMMIT)
5) SERIALIZABILITY:
"Ques" all transactions to occur "serially" (sequentially), in order of access
DBMS Scheduler: manages concurrency control to ensure serializability of transactions
(lock/unlock data)
Note:
• Isolation and serialization are nonissues in single-user database systems.
• Transaction log: records neccessary information to process transaction, if
interrupt/power failure.
• Engine will read logs on next startup and commit any remaining transactions.
End of Transaction:
1) COMMIT;
2) ROLLBACK;
3) Program ends successfully (equivalent to COMMIT)
4) Program abnormally terminates (equivalent to ROLLBACK)
Example:
START TRANSACTION;
select * from user;
UPDATE user SET lname=’Jones’ WHERE uid=1;
select * from user;
COMMIT;
