are removed when the user logs out when to use is not widely agreed on come with a huge performance penalty problems can usually be solved by derived tables suggested use: use when you need to keep a backup copy of your data do not use during “regular” work, just to make things appear easier

SELECT * FROM (SELECT * FROM someOtherTable) derivedT;

SELECT u.last_name, dT.state FROM User AS u, (SELECT user_id, state FROM Address) AS dT WHERE u.id = dT.user_id;

nothing is created you just name temporary datasets make it possible to refer to data inside of datasets in your query

Imagine you are a bank your DB has 2 stored procs withdraw funds deposit funds if a customer wants to transfer funds from one account into another, you first withdraw from one account, then deposit into the second one what if you withdraw, then the power goes out/server reboots/acct number is incorrect -> the money is gone!

units of work that must be done in order, and succeed or fail as a group (even a single failure point causes a transaction to fail) if a transaction fails, all changes are rolled back, like nothing ever happened

if we use transaction, if deposit fails, withdrawal is rolled back, money is back where it started

1. Begin Transaction 2. Do some processing 3. If succeeded -> Commit changes 4. If failed -> Rollback changes

INT BEGIN TRAN UPDATE Authors SET Phone = ' ' WHERE au_id = ' ' = IF <> 0) GOTO PROBLEM UPDATE Publishers SET city = 'Calcutta', country = 'India' WHERE pub_id = '9999' = IF <> 0) GOTO PROBLEM COMMIT TRAN PROBLEM: IF <> 0) BEGIN PRINT 'Unexpected error occurred!' ROLLBACK TRAN END

BEGIN TRAN BEGIN TRAN name

COMMIT TRAN COMMIT TRAN name

ROLLBACK TRAN ROLLBACK TRAN name

BEGIN TRAN transaction1 -- do something BEGIN TRAN transaction 2 -- do something else COMMIT TRAN transaction 2 -- do something else COMMIT TRAN transaction1 -- if issue with transaction1 -> ROLLBCK -- transaction2 ROLLBACK can happen either within transaction1, or outside of it, depending on your needs

data is stored in the DB in the order in which it was inserted when searching for a specific record/group of records if searching based on primary key – fast (it is indexed) if searching based on other columns – DB goes through every single record index -> when you add an index, you order the data in the specific column, so searching is faster

improves retrieval speeds slows down writes if update -> the DB may have to update the index/es if insert or delete -> the DB has to update the index/es takes up space - in RDBMS index is a copy of the column

should not index every column due to the costs for small tables, performance gain is minimal provide largest gains when the data on the indexed column varies widely (cardinality) help especially when you are trying to retrieve less than 25% of the data in the table if you are making massive updates/inserts/deletes on a table, consider dropping the index, making changes, recreating the index

index on columns used to join tables do not index columns that are updated frequently store indexes on separate HDD from the data do not use on columns that contain a large number of NULL values at the end of the day -> test/tune your index/es -> measure performance, create index, measure again

index created on more than one column creates 1 index, regardless how many columns were used to create it

changes how the data is stored on the disk usually only one per table usually on the primary key – they are most effective if data is scrolled through sequentially

see your book for more details – LESSON 15

CREATE INDEX test ON TestForIndex(column1);