1. Tables and Triggers

2. DDL versus DML
SQL statements fall into two categories: the Data Definition Language (DDL) and the Data Manipulation Language (DML)
Data Definition Language Statements: build and modify the structure of the tables and other objects:
CREATE ALTER DROP
All SQL implementations have "data dictionaries", special tables that hold the contents of the descriptions of all of the structures.
For SQLite one such data dictionary is called "sqlite_master"
Data Manipulation Language: add, remove, query data in a database
CRUD operations (INSERT, SELECT, UPDATE, DELETE statements)

3. ALTER TABLE ALTER TABLE cse480_students RENAME TO students;
ALTER TABLE students ADD COLUMN course TEXT;
This statement is used to modify an existing (already created table)
SQLite only supports a subset of SQL standard for ALTER TABLE, so it is better to CREATE your table correctly instead of changing it later.
You can only do two things with SQLite's ALTER TABLE:
You can rename a table
You can add a column

4. Warning about altering tables
When you change or replace a table, the pre-existing constraints (foreign keys, checks, etc.) are sometimes lost.
You will have to recreate them.
See for details.

5. DROP TABLE DROP TABLE students; DROP TABLE IF EXISTS students;
This command removes a table from the database.
All the rows are implicitly DELETE FROM'ed the dropped table.
Foreign key constraints are not checked, and must be resolved manually.
The IF EXISTS clause stops the error for trying to drop a non-existent table.

6. Trigger Example
What if every time you added a student to the table, "students", you wanted to log the current time in the table "log".
students
log id
name 1
Josh 2
Tyler
student_id
time_inserted 1
12:40:00 2
14:37:34
You could do this with two commands:
INSERT INTO students (id, name) VALUES (3, 'Grant');
INSERT INTO log (student_id, time_inserted) VALUES (3, time('now'));

7. Problems  Problems: If you forget to do the "INSERT INTO log"
Previous commands:
INSERT INTO students (id, name) VALUES (3, 'Grant');
INSERT INTO log (student_id, time_inserted) VALUES (3, time('now'));
Problems:
If you forget to do the "INSERT INTO log"
You need to know the students.id for the second insert
You can't be sure it will always happen
For instance, what about INSERT INTO SELECT statements?

8. Triggers to the rescue
CREATE TRIGGER log_the_inserts AFTER INSERT ON students BEGIN
INSERT INTO log (student_id, time_inserted) VALUES
(NEW.id, time('now'));
END;
This trigger activates after every insert on the table "students".
It does the commands between the "BEGIN" and "END" keywords.
In this case there is only one command (to make an insert into the "log" table)
You can access the data for the row that activated the trigger with the "NEW" pseudo table.
You can see it in action with "NEW.id" which is the "id" of the row being added to students.

9. Trigger Syntax
CREATE TRIGGER trigger_name [Timing] event_name ON table_name [WHEN predicate] BEGIN
trigger logic / commands ...
END;
Event name can be INSERT, DELETE, or UPDATE
Timing can be BEFORE, AFTER, or INSTEAD OF. It specifies if the trigger's logic is applied before, after, or in replacement of the event
The WHEN clause is optional and if provided only activates trigger if true
You can can use NEW and OLD to refer to the row's NEW value (for INSERT and UPDATE) or OLD value (for UPDATE and DELETE).

10. Another Example: ID change
name 1
Josh 2
Tyler
student_id
time_inserted 1
12:40:00 2
14:37:34
students
log
What if a student got their "id" number changed? We need to update the table "log" too.
CREATE TRIGGER id_change AFTER UPDATE ON students WHEN NEW.id != OLD.id
BEGIN UPDATE log SET student_id = NEW.id WHERE student_id = OLD.id; END;

11. BEFORE versus AFTER Triggers
A trigger can be set to activate before or after a database modification that sets it off. Depending on what you want to do, one may be better than the other.
BEFORE:
Usually used when validation needs to happen BEFORE the database is changed. Your trigger could activate and stop an illegal change.
AFTER:
Usually used when you need to update information in other tables because of a change.

12. INSTEAD OF CREATE TRIGGER change_name INSTEAD OF UPDATE ON students
BEGIN INSERT INTO audit VALUES
(OLD.id, 'Tried to change name, alert the spies.');
END;
The INSTEAD OF clause causes the trigger to activate instead of the event which activated it.

13. UPDATE OF
CREATE TRIGGER trig_exam AFTER UPDATE OF Name, TrackId ON Tracks BEGIN;
-- SQL statements
END;
You can use the UPDATE OF <comma-separated column names> to specify that you only want the trigger to activate upon the update of specific columns, instead of every update.
There is no INSERT OF <columns> or DELETE OF <columns> because every column in a row is changed by INSERT and DELETE.

14. RAISE CREATE TRIGGER error_trig INSERT ON students BEGIN
SELECT RAISE(ABORT, 'ERROR message'); END;
RAISE is a special function that takes two arguments:
What to do: ABORT which causes the statement that caused the trigger to be undone
We'll talk about other options later in the course
What to say: An error message to be displayed
You can use the RAISE function to write triggers that enforce more complicated constraints
For instance, not allowing INSERT INTO the table "grades" after the due date
CREATE TRIGGER too_late INSERT ON grades
WHEN date('now') > date(' ') BEGIN
SELECT RAISE(ABORT, 'Can not add to grades, due date past!'); END;

15. Multiple Statements in a Trigger
You can put as many SQL statements as desired between BEGIN and END.
So you can do complicated changes to the table that activated the trigger
Or any other tables as well

16. DROP TRIGGER DROP TRIGGER too_late; DROP TRIGGER IF EXISTS too_late;
Works the same as DROP TABLE.

17. What should happen if a trigger's "on" table is dropped?
ERROR, you need to DROP TRIGGER first The trigger should be dropped automatically The trigger should be dropped, but only if it doesn't refer to other tables Then you must prepare for "The Drop", when the beat kicks in

18. Trigger Pros and Cons Pros:
They always activate when the operation they are watching for happens
They are logic that is stored in the database, not the application talking to the database
Very useful for auditing and validation
Cons:
Not transparent (they can activate without you knowing about them)
They can lead to inefficiencies if you don't know they are happening in the background
Often stored procedures (we'll learn about them later) are a better alternative