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 its 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 querycannot 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.

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 tablesthe 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 DBAs job more difficultespecially 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;

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 doesnt 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

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 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.

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

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 UDL ISRupdate the , PE toT ,Aor N E E 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:
M,(and Aggregate functions (SM)AON so forth) , UI X) ,(NCU ,( DS I T GO R U HV A I UI UI N NN O or O

Subquery in the select list Certain joins (see additional join discussion later in this section) R Nonupdatable view in the F clause H R R A subquery in the WE clause that refers to a table in the F clause Refers only to literal values (in this case, there is no underlying table to update) L Uses A (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. 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. Dont 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.

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. 2. 3. 4. Trigger Trigger Trigger Trigger event, can be INSERT, UPDATE, DELETE activation time, can be AFTER or BEFORE event table (which table will be affected) body (SQL statements)

Example: Every time an administrator adds a new inventory record, insertion data will be logged to a separate table (log), including administrators 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

); 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.

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.

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;

References http://dev.mysql.com/doc/refman/5.0/en/create-view.html http://themetricsystem.rjmetrics.com/2008/10/28/correlated-subqueries-in-mysql/ http://dev.mysql.com/doc/refman/5.1/en/correlated-subqueries.html http://www.paragoncorporation.com/ArticleDetail.aspx?ArticleID=28 http://databases.aspfaq.com/database/should-i-use-a-view-a-stored-procedure-or-a-userdefined-function.html http://bytes.com/topic/sql-server/answers/450173-views-vs-stored-procedures-whatsdifference http://www.brainbell.com/tutorials/MySQL/Using_Stored_Procedures.htm http://forums.mysql.com/read.php?98,358569,358569 http://groups.google.com/group/microsoft.public.sqlserver.newusers/browse_frm/thread/b2 0d4abdede81ada/75cc4092b8603807?lnk=st&q=view+stored+procedure+author %3Ahugo+author%3Akornelis&rnum=1&hl=en#75cc4092b8603807 http://dev.mysql.com/doc/refman/5.1/en/create-trigger.html http://dev.mysql.com/doc/refman/5.1/en/triggers.html http://www.brainbell.com/tutorials/MySQL/Creating_Triggers.htm http://download.oracle.com/docs/cd/B10501_01/appdev.920/a96590/adg13trg.htm