More SQL notes

Databases/Relational_Databases/Relational_database_architecture.md

@@ -16,10 +16,10 @@ A group of similar data with rows for **records** and columns for each **field**
 
 ## Record
 
-A horizontal row: a collection of items which may be of different data types all relating to the individual or object that the record describes. A single _entry_ in the table.
+A horizontal row: a collection of items which may be of different data types all relating to the individual or object that the record describes. A single _entry_ in the table. Sometimes called **row** interchangeably.
 
 ## Field
 
-A vertical column: stores a single particular unit of data for each record. Each field must use the same data type.
+A vertical column: stores a single particular unit of data for each record. Each field must use the same data type. Sometimes called **field** interchangeably.
 
 Each individual field has **properties:** such as the data type, length or the total memory allocation.

Databases/Relational_Databases/Role_of_unique_key_in_relational_databases.md

@@ -4,13 +4,15 @@ categories:
 tags: [relational-databases]
 ---
 
-# Primary key
+# Unique key
 
-> Every table in a relational database should have a **primary key**. A primary key is one **field that uniquely identifies each record**.
+> Every table in a relational database should have a **unique key**. A unique key is one **field that uniquely identifies each record**.
 
 This is essential for carrying out operations across database tables and for creating and deleting database entires in accordance with the [ACID principle](/Databases/ACID_principle.md). It is also a safeguard: it means you can always identify a record by itself and don't have to rely on generic queries to identify it.
 
-Sometimes you will have a dedicated field such as `UNIQUE_ID` for the primary key. Other times you can use an existing field to fulfil that function. In both cases the following constraints **must be met:**
+Sometimes you will have a dedicated field such as `UNIQUE_ID` for the unique key. Other times you can use an existing field to fulfil that function. When an existing, visible column is used as the unique key it is called the **primary key**. Other times the unique key can be hidden from the table.
+
+In both cases the following constraints **must be met:**
 
 1. No two records can have the **same** primary key data
 1. The primary key value should **never be reused**. Thus, if a record is deleted from the table, it should not be re-allocated to a new record.

Databases/SQL/Accessing_metadata_about_SQL_database.md

@@ -0,0 +1,18 @@
+---
+categories:
+  - Databases
+  - Programming Languages
+tags: [SQL]
+---
+
+# Accessing metadata about SQL database
+
+```sql
+SHOW DATABASES
+
+USE [database_name]
+
+SHOW TABLES
+
+DESCRIBE [table_name]
+```

Databases/SQL/Foreign_keys_in_SQL.md

@@ -9,9 +9,7 @@ tags: [SQL, relational-database]
 
 We utilise **foreign** and [primary keys](/Databases/Relational_Databases/Primary_key.md) to create relationships between tables in SQL. Foreign keys link data in one table to the data in another table and are how we cross-reference data in SQL.
 
-<!-- We can use this technique to create new tables from existing tables in the database or to generate [views](/Databases/Relational_Databases/Views_in_relational_databases.md). -->
-
-In essence you use the primary key of one table to access data in another table.
+In essence you use the primary key of one table to access data in another table. When one table _A_ contains the primary key of another table _B_ as a field, that key is "foreign" to _A_ hence the name.
 
 Let's say we have a `sales` table:
 
@@ -47,7 +45,7 @@ Here's our `returns` table:
 
 In this table `saleId` is identical to `saleId` in sales. It is the primary key in `sales` but a foreign key in `returns`. If a device has been returned it must have an entry in `returns` and the `salesId` of the entry in `returns` must match the `salesId` in `sales`.
 
-This is the primary benefit of utilising foreign keys: they add a restriction. Entries to the table with a foreign key **must** have a value that corresponds with the foreign key column. 
+This is the primary benefit of utilising foreign keys: they add a restriction. Entries to the table with a foreign key **must** have a value that corresponds with the foreign key column.
 
 We call this a **foreign key contraint**. More explicitly, our contraint is as follows:
 
@@ -66,6 +64,7 @@ CREATE TABLE returns (
 	FOREIGN KEY (sale_id) REFERENCES sales(sale_id)
 	);
 ```
+
 A table can have more than one foreign key.
 
-If you delete the source of the foreign key, you also delete its references in tables for which it is a foreign key. This is important to remember. So if a row was deleted from `sales` the row in `returns` with the corresponding `saleId` would also be deleted.
+If you delete the source of the foreign key, you also delete its references in tables for which it is a foreign key. This is important to remember. So if a row was deleted from `sales` the row in `returns` with the corresponding `saleId` would also be deleted.

Databases/SQL/Retrieve_data_from_SQL_table.md

@@ -69,3 +69,12 @@ SELECT name FROM models ORDER BY name, cores DESC
 ```
 
 > `ORDER BY` always comes last, after the selection and any filtering clauses but _before_ a `WHERE` clause
+
+## Paginate
+
+We can break our returned data into blocks with `LIMIT`
+
+```sql
+LIMIT 5 -- Return first five items
+LIMIT 5,5 -- Return first five items from the sixth row
+```

Logic/Boolean_functions.md

@@ -13,5 +13,3 @@ f(x,y,z) = (x \land y) \lor (\lnot(x) \land z )
 $$
 
 Here is a work through where $f(1, 0, 1)$:
-
-// Insert diagram