more updated content to display on the new site

363/lec/lec10.md

@@ -1,43 +1,47 @@
-# lec10
+lec1
+====
 
-This lecture has a corresponding lab excercise who's instructions can be found in `triggers-lab.pdf`.
+Databases introduction
+----------------------
 
-## What is a trigger
+First off why do we even need a database and what do they accomplish?
 
-Something that executes when _some operation_ is performed
+Generally a databse will have 3 core elements to it:
 
-## Structure 
+1.  querying
+    -   Finding things
+        -   Just as well structured data makes querying easier
+2.  access control
+    -   who can access which data segments and what they can do with
+        that data
+        -   reading, writing, sending, etc
+3.  corruption prevention
+    -   mirroring/raid/parity checking/checksums/etc as some examples
 
-```
-create trigger NAME before some_operation
-when(condition)
-begin
-	do_something
-end;
-```
+Modeling Data
+-------------
 
-To explain: First we `create trigger` followed by some trigger name.
-Then we have to denote that this trigger should fire whenever some operation happens.
-This trigger then executes everything in the `begin...end;` section _before_ the new operation happens.
+Just like other data problems we can choose what model we use to deal
+with data. In the case for sqlite3 the main data model we have are
+tables, where we store our pertinent data, and later we'll learn even
+data about our data is stored in tables.
 
-> `after`
+Because everything goes into a table, it means we also have to have a
+plan for *how* we want to lay out our data in the table. The **schema**
+is that design/structure for our databse. The **instance** is the
+occurance of that schema with some data inside the fields, i.e. we have
+a table sitting somewhere in the databse which follows the given
+structure of a aforemention schema.
 
-Likewise if we want to fire a trigger _after_ some operation we ccan just replace the before keyword with `after`.
-
-> `new.adsf`
-
-Refers to _new_ value being added to a table.
-
-> `old.adsf` 
-
-Refers to _old_ vvalue being changed in a table.
-
-	
-## Trigger Metadata
-
-If you want to look at what triggers exist you can query the `sql_master` table.
-
-```
-select * from sql_master where name='trigger';
-```
+**Queries** are typically known to be declarative; typically we don't
+care about what goes on behind the scenes in practice since by this
+point we are assuming we have tools we trust and know to be somewhat
+efficient.
 
+Finally we have **transactions** which are a set of operations who are
+not designed to only commit if they are completed successfully.
+Transactions are not alllowed to fail. If *anything* fails then
+everything should be undone and the state should revert to previous
+state. This is useful because if we are, for example, transferring money
+to another account we want to make sure that the exchange happens
+seamlessly otherwise we should back out of the operation altogether.