More SQL notes
This commit is contained in:
parent
001d64a579
commit
eeae4b1af1
13 changed files with 197 additions and 286 deletions
|
@ -1,56 +0,0 @@
|
|||
---
|
||||
categories:
|
||||
- Databases
|
||||
- Programming Languages
|
||||
tags: [SQL]
|
||||
---
|
||||
|
||||
# SQL: Demonstration database
|
||||
|
||||
For the purposes of demonstration we will work from a made-up database. The examples are created using SQLite but they are transferable to any SQL database.
|
||||
|
||||
This database stores information about computers, their manufacturers, properties and sale data:
|
||||
|
||||
- The overall database is `computer_sales`
|
||||
- It contains the following [tables](/Databases/Relational_database_architecture.md#table): `manufacturer`, `model`, `sales`
|
||||
- Example [fields](/Databases/Relational_database_architecture.md#field) that belong to these tables: `manufacturer_id` , `model_id` , `name`, `year_founded` , `ram` , `sale_date`
|
||||
|
||||
Below are the `model` and `manufacturer` tables output from the SQLite terminal client.
|
||||
|
||||
The model table:
|
||||
|
||||
```
|
||||
model_id manufacturer_id name cpu_speed ram cores wifi release_date
|
||||
---------- --------------- ---------------------- ---------- ---------- ---------- ---------- ------------
|
||||
1 1 Raspberry Pi 1 Model A 0.7 256.0 1 0 2013-02-01
|
||||
2 1 Raspberry Pi 1 Model B 0.7 256.0 1 0 2012-04-01
|
||||
3 1 Raspberry Pi 1 Model B 0.7 512.0 1 0 2012-10-01
|
||||
4 1 Raspberry Pi 1 Model A 0.7 512.0 1 0 2014-11-01
|
||||
5 1 Raspberry Pi 1 Model B 0.7 512.0 1 0 2014-07-01
|
||||
6 1 Raspberry Pi 2 Model B 0.9 1024.0 4 0 2015-02-01
|
||||
7 1 Raspberry Pi 3 Model B 1.2 1024.0 4 1 2016-02-01
|
||||
8 1 Raspberry Pi 3 Model B 1.4 1024.0 4 1 2018-03-14
|
||||
9 1 Raspberry Pi 3 Model A 1.4 1024.0 4 1 2018-11-01
|
||||
10 1 Raspberry Pi 4 Model B 1.5 1024.0 4 1 2019-06-24
|
||||
11 1 Raspberry Pi 4 Model B 1.5 2048.0 4 1 2019-06-24
|
||||
12 1 Raspberry Pi 4 Model B 1.5 4096.0 4 1 2019-06-24
|
||||
13 1 Raspberry Pi Zero 1.0 512.0 1 0 2015-11-01
|
||||
14 1 Raspberry Pi Zero W 1.0 512.0 1 1 2017-02-28
|
||||
15 2 Apple Lisa 0.008 1.0 1 0 1983-01-19
|
||||
16 2 Apple iMac 3.7 8192.0 4 1 2019-03-19
|
||||
17 2 Apple MacBook Pro 2.6 16384.0 6 1 2019-05-21
|
||||
18 2 Apple MacBook Air 2.6 8192.0 2 1 2019-07-09
|
||||
19 3 Commodore VIC-20 0.00102 0.005 1 0 1980-01-01
|
||||
20 3 Commodore 64 0.001023 0.064 1 0 1982-08-01
|
||||
21 3 Amiga 500 0.00716 0.5 1 0 1987-04-01
|
||||
```
|
||||
|
||||
The manufacturer table:
|
||||
|
||||
```
|
||||
manufacturer_id name url year_founded trading
|
||||
--------------- ------------ ----------------------- ------------ ----------
|
||||
1 Raspberry Pi <https://raspberrypi.org> 2008 1
|
||||
2 Apple <https://apple.com> 1976 1
|
||||
3 Commodore <https://www.commodore.c> 1954 0
|
||||
```
|
|
@ -7,45 +7,29 @@ tags: [SQL]
|
|||
|
||||
# SQL: Language structure
|
||||
|
||||
Before we start using the syntax we need to understand the grammar:
|
||||
The structure or syntax of SQL is composite and mirrors that of a natural or logical language. There are overall statements (queries) which subdivide hierarchially into clauses, predicates, and expressions.
|
||||
|
||||

|
||||
## Query
|
||||
|
||||
Expressions differ from clauses and predicates in that they are not the mechanism for returning data (i.e. declaring a clause and a logical colllllndition) they do something to the data, as part of the retrieval. This is a bit subtle:
|
||||
- A statement that updates or retrieves data from a table based on passed-in criteria
|
||||
- The highest level in the syntax tree, equivalent to a sentence in natural language
|
||||
- Examples:
|
||||
- `SELECT`
|
||||
- `UPDATE`
|
||||
- `DELETE`
|
||||
- Applied example:
|
||||
- `SELECT name FROM model`
|
||||
|
||||
- `SELECT name FROM model WHERE cores = "4"`
|
||||
- This retrieves the models that have 4 cores
|
||||
- `SELECT count(*) FROM model WHERE cores = "4" `
|
||||
- This counts the number of models that are returned where the counting is a function over and above the retrieval itself.
|
||||
## Clause
|
||||
|
||||
### Examples from `computer_sales.db`
|
||||
- Typically provides parameters for a given query
|
||||
- For example running a query against a specific table (`FROM`) that satisfies certain conditions (`WHERE`)
|
||||
|
||||
`sqlite> SELECT * from model WHERE cpu_speed=0.7` : return all models with a CPU speed equal to 0.7:
|
||||
## Predicates
|
||||
|
||||
```
|
||||
model_id manufacturer_id name cpu_speed ram cores wifi release_date
|
||||
---------- --------------- ---------------------- ---------- ---------- ---------- ---------- ------------
|
||||
1 1 Raspberry Pi 1 Model A 0.7 256.0 1 0 2013-02-01
|
||||
2 1 Raspberry Pi 1 Model B 0.7 256.0 1 0 2012-04-01
|
||||
3 1 Raspberry Pi 1 Model B 0.7 512.0 1 0 2012-10-01
|
||||
4 1 Raspberry Pi 1 Model A 0.7 512.0 1 0 2014-11-01
|
||||
5 1 Raspberry Pi 1 Model B 0.7 512.0 1 0 2014-07-01
|
||||
```
|
||||
- A logical or numerical condition which is passed to a given clause.
|
||||
- For example `WHERE` a given condition obtains
|
||||
|
||||
```
|
||||
count(*)
|
||||
----------
|
||||
5
|
||||
```
|
||||
### Expression
|
||||
|
||||
> Any value that is not a number should be in single-quotes, never double quotes
|
||||
|
||||
## Main commands
|
||||
|
||||
There are obviously many SQL commands but most standard CRUD actions can be executed with a small number of commands:
|
||||
|
||||
- `SELECT`
|
||||
- `UPDATE`
|
||||
- `CREATE`
|
||||
- `INSERT`
|
||||
- `DELETE`
|
||||
- The lowest level of the hierarchy: field, row names etc
|
||||
|
|
|
@ -1,82 +0,0 @@
|
|||
---
|
||||
categories:
|
||||
- Databases
|
||||
- Programming Languages
|
||||
tags: [SQL]
|
||||
---
|
||||
|
||||
# SQL: The SELECT query
|
||||
|
||||
## Print/retrieve/write an entire table, unfiltered
|
||||
|
||||
```sql
|
||||
SELECT * FROM [table_name]
|
||||
|
||||
SELECT * FROM model
|
||||
```
|
||||
|
||||
## Retrieve all data from a specific field
|
||||
|
||||
```sql
|
||||
SELECT [field_name] FROM [table_name]
|
||||
|
||||
SELECT name FROM manufacturer
|
||||
```
|
||||
|
||||
## Retrieve data and order it
|
||||
|
||||
This example orders alphabetically:
|
||||
|
||||
```sql
|
||||
SELECT [field_name] FROM [table_name] ORDER BY [property]
|
||||
SELECT name FROM model ORDER BY name
|
||||
```
|
||||
|
||||
> When `ORDER BY` is used the default method for strings is alphabetical and for integers it is ascending order.
|
||||
|
||||
Here's a more complex real-life request:
|
||||
|
||||
```sql
|
||||
SELECT name, cores, ram FROM model ORDER BY ram, name
|
||||
```
|
||||
|
||||
It gives us:
|
||||
|
||||
```
|
||||
name cores ram
|
||||
---------------- ---------- ----------
|
||||
Commodore VIC-20 1 0.005
|
||||
Commodore 64 1 0.064
|
||||
Amiga 500 1 0.5
|
||||
Apple Lisa 1 1.0
|
||||
Raspberry Pi 1 M 1 256.0
|
||||
Raspberry Pi 1 M 1 256.0
|
||||
Raspberry Pi 1 M 1 512.0
|
||||
Raspberry Pi 1 M 1 512.0
|
||||
Raspberry Pi 1 M 1 512.0
|
||||
Raspberry Pi Zer 1 512.0
|
||||
```
|
||||
|
||||
But we can obviously specify our own ordering method:
|
||||
|
||||
```sql
|
||||
SELECT name, cores, release_date FROM model ORDER BY cores DESC, name;
|
||||
```
|
||||
|
||||
Returns:
|
||||
|
||||
```
|
||||
name cores release_date
|
||||
----------------- ---------- ------------
|
||||
Apple MacBook Pro 6 2019-05-21
|
||||
Apple iMac 4 2019-03-19
|
||||
Raspberry Pi 2 Mo 4 2015-02-01
|
||||
Raspberry Pi 3 Mo 4 2018-11-01
|
||||
Raspberry Pi 3 Mo 4 2016-02-01
|
||||
Raspberry Pi 3 Mo 4 2018-03-14
|
||||
Raspberry Pi 4 Mo 4 2019-06-24
|
||||
Raspberry Pi 4 Mo 4 2019-06-24
|
||||
Raspberry Pi 4 Mo 4 2019-06-24
|
||||
```
|
||||
|
||||
> `ORDER BY` always comes last, after the selection and any filtering clauses but _before_ a `WHERE` clause
|
|
@ -1,29 +0,0 @@
|
|||
---
|
||||
categories:
|
||||
- Databases
|
||||
- Programming Languages
|
||||
tags: [SQL]
|
||||
---
|
||||
|
||||
# SQL: INSERT
|
||||
|
||||
## Adding a record
|
||||
|
||||
```sql
|
||||
INSERT INTO sales
|
||||
VALUES (1, 11, '2020-01-01','mhogan');
|
||||
```
|
||||
|
||||
If you intend to miss out a value, you shouldn't leave it blank, you should instead use `NULL` :
|
||||
|
||||
```sql
|
||||
INSERT INTO sales
|
||||
VALUES (1, 11, '2020-01-01', NULL);
|
||||
```
|
||||
|
||||
> There is a problem with this format: it only works so long as the order to the values in the `VALUES` clause corresponds to the order of the fields in the tables. To rule out error we should instead specify these fields along with the table name:
|
||||
|
||||
```sql
|
||||
INSERT INTO sales**(employee_id, sale_id, model_id, sale_date)**
|
||||
VALUES ('mhogan', 1, 11, '2020-01-01',);
|
||||
```
|
|
@ -1,68 +0,0 @@
|
|||
---
|
||||
categories:
|
||||
- Databases
|
||||
- Programming Languages
|
||||
tags: [SQL]
|
||||
---
|
||||
|
||||
# SQL: The WHERE clause and compound statements
|
||||
|
||||
Within the `SELECT` statement, the `WHERE` clause specifies the search criterion. The `WHERE` clause should always be last in the syntax. The clauses are always written in this order: `FROM` followed by `WHERE`.
|
||||
|
||||
`SELECT name, cores, release_date FROM model WHERE CORES="4";`:
|
||||
|
||||
```
|
||||
name cores release_date
|
||||
---------------------- ---------- ------------
|
||||
Raspberry Pi 2 Model B 4 2015-02-01
|
||||
Raspberry Pi 3 Model B 4 2016-02-01
|
||||
Raspberry Pi 3 Model B 4 2018-03-14
|
||||
Raspberry Pi 3 Model A 4 2018-11-01
|
||||
Raspberry Pi 4 Model B 4 2019-06-24
|
||||
Raspberry Pi 4 Model B 4 2019-06-24
|
||||
Raspberry Pi 4 Model B 4 2019-06-24
|
||||
Apple iMac 4 2019-03-19
|
||||
```
|
||||
|
||||
## Compound statements
|
||||
|
||||
Compound statements allow you to apply more filters to your clauses within an SQL statement. SQL allows you to build complex, combinatorial `WHERE` clauses by using Boolean and mathematical operators (i.e `AND` , `OR` , `>` , `<` , `!=` , `<=` ...)
|
||||
|
||||
Multiple clauses:
|
||||
|
||||
```sql
|
||||
SELECT name, ram, release_date
|
||||
FROM model
|
||||
WHERE release_date > '2018-01-01' AND ram > 512;
|
||||
```
|
||||
|
||||
More complex logic achieve with parentheses:
|
||||
|
||||
```sql
|
||||
SELECT name, cores, release_date
|
||||
FROM model
|
||||
WHERE (manufacturer_id = 1 OR manufacturer_id = 2) AND cores >= 2;
|
||||
```
|
||||
|
||||
## Wildcards
|
||||
|
||||
SQL does not use Regex. Instead it has a simpler glob-like syntax for carrying out string matching.
|
||||
|
||||
In order to signal that you wish to compare by a wildcard and not a value, you have to use the `LIKE` keyword. The actual wildcard operator is `%` .
|
||||
|
||||
In an SQL statement, the `%` wild card will match any number of occurrences of any character.
|
||||
Any characters can appear before or after ‘MacBook’ and the record will still be returned:
|
||||
|
||||
```sql
|
||||
SELECT name, cores, release_date
|
||||
FROM model
|
||||
WHERE name LIKE '%MacBook%';
|
||||
```
|
||||
|
||||
This wildcard only filters characters that come after `Raspberry` :
|
||||
|
||||
```sql
|
||||
SELECT name, cores, release_date
|
||||
FROM model
|
||||
WHERE name LIKE 'Raspberry%';
|
||||
```
|
|
@ -1,12 +0,0 @@
|
|||
---
|
||||
categories:
|
||||
- Databases
|
||||
- Programming Languages
|
||||
tags: [SQL]
|
||||
---
|
||||
|
||||
# SQL: The DELETE query
|
||||
|
||||
```sql
|
||||
DELETE FROM sales WHERE sale_id = 1;
|
||||
```
|
38
Databases/SQL/Delete_records_in_an_SQL_table.md
Normal file
38
Databases/SQL/Delete_records_in_an_SQL_table.md
Normal file
|
@ -0,0 +1,38 @@
|
|||
---
|
||||
categories:
|
||||
- Databases
|
||||
- Programming Languages
|
||||
tags: [SQL]
|
||||
---
|
||||
|
||||
# Deleting data in SQL
|
||||
|
||||
## Deleting records
|
||||
|
||||
We use `DELETE` to delete existing records in a table. Once this is applied, the records are permanently deleted.
|
||||
|
||||
To delete **all records** whilst maintaining the table:
|
||||
|
||||
```sql
|
||||
DELETE FROM sales
|
||||
```
|
||||
|
||||
We can also use `TRUNCATE` to achieve this. It is faster but it doesn't keep a log of each deletion:
|
||||
|
||||
```sql
|
||||
TRUNCATE TABLE sales
|
||||
```
|
||||
|
||||
To delete a **specifc entry** by field:
|
||||
|
||||
```sql
|
||||
DELETE FROM sales WHERE sale_id = 1;
|
||||
```
|
||||
|
||||
## Deleting tables
|
||||
|
||||
We use `DROP` to remove an entire table. This will delete the table definition, and all the data, indexes, triggers, constraints and permission specifications for that table.
|
||||
|
||||
```sql
|
||||
DROP TABLE sales
|
||||
```
|
35
Databases/SQL/Insert_data_into_SQL_table.md
Normal file
35
Databases/SQL/Insert_data_into_SQL_table.md
Normal file
|
@ -0,0 +1,35 @@
|
|||
---
|
||||
categories:
|
||||
- Databases
|
||||
- Programming Languages
|
||||
tags: [SQL]
|
||||
---
|
||||
|
||||
# Insert data into table with SQL `INSERT` statement
|
||||
|
||||
_A table named `sales`:_
|
||||
|
||||
| saleId | modelId | date | salesPerson |
|
||||
| ------ | ------- | ---------- | ----------- |
|
||||
| 223 | 2 | 2020-01-09 | tgomay |
|
||||
| 321 | 3 | 2020-03-14 | snedgamon |
|
||||
| 491 | 4 | 2021-08-06 | tricksahoy |
|
||||
|
||||
```sql
|
||||
INSERT INTO sales
|
||||
VALUES (1, 11, '2020-01-01','mhogan');
|
||||
```
|
||||
|
||||
> If you intend to miss out a value, you shouldn't leave it blank, you should instead use `NULL` :
|
||||
|
||||
```sql
|
||||
INSERT INTO sales
|
||||
VALUES (1, 11, '2020-01-01', NULL);
|
||||
```
|
||||
|
||||
> The approach above works well if the order of entry matches the order of the table fields. If this is not the case you can specify the order as part of the `INSERT` statement:
|
||||
|
||||
```sql
|
||||
INSERT INTO sales**(employee_id, sale_id, model_id, sale_date)**
|
||||
VALUES ('mhogan', 1, 11, '2020-01-01',);
|
||||
```
|
73
Databases/SQL/Retrieve_data_from_SQL_table.md
Normal file
73
Databases/SQL/Retrieve_data_from_SQL_table.md
Normal file
|
@ -0,0 +1,73 @@
|
|||
---
|
||||
categories:
|
||||
- Databases
|
||||
- Programming Languages
|
||||
tags: [SQL]
|
||||
---
|
||||
|
||||
# Retrieve data from table with SQL `SELECT` statement
|
||||
|
||||
> Select data from the database. The data returned is stored in a result table called the **result-set**.
|
||||
|
||||
_A table named `models`:_
|
||||
|
||||
| modelId | name | cores | releaseDate |
|
||||
| ------- | -------------------- | ----- | ----------- |
|
||||
| 2 | Raspberry Pi Model B | 2 | 2022-11-19 |
|
||||
| 3 | Raspberry Pi Model C | 4 | 2022-11-25 |
|
||||
| 4 | MacBook Pro M2 | 9 | 2022-03-18 |
|
||||
|
||||
## Basic usage
|
||||
|
||||
```sql
|
||||
SELECT name FROM models
|
||||
```
|
||||
|
||||
We can pass in a comma-separated **list of fields**:
|
||||
|
||||
```sql
|
||||
SELECT name, releaseDate FROM models
|
||||
```
|
||||
|
||||
## With parameters
|
||||
|
||||
### `WHERE`
|
||||
|
||||
The `WHERE` clause specifies a search criterion. The `WHERE` clause should always be last in the syntax. The clauses are always written in this order: `FROM` followed by `WHERE`
|
||||
|
||||
```sql
|
||||
SELECT name FROM models WHERE cores > 3
|
||||
```
|
||||
|
||||
### Compound statements
|
||||
|
||||
Compound statements allow you to apply more filters to your clauses within an SQL statement. SQL allows you to build complex, combinatorial `WHERE` clauses by using Boolean and mathematical operators (i.e `AND` , `OR` , `>` , `<` , `!=` , `<=` ...)
|
||||
|
||||
Multiple clauses:
|
||||
|
||||
```sql
|
||||
SELECT name, ram, release_date
|
||||
FROM model
|
||||
WHERE release_date > '2018-01-01' AND ram > 512;
|
||||
```
|
||||
|
||||
More complex logic achieve with parentheses:
|
||||
|
||||
```sql
|
||||
SELECT name, cores, release_date
|
||||
FROM model
|
||||
WHERE (manufacturer_id = 1 OR manufacturer_id = 2) AND cores >= 2;
|
||||
```
|
||||
|
||||
## Transform returned data
|
||||
|
||||
We can apply **ordering** to the return data
|
||||
|
||||
```sql
|
||||
SELECT name FROM models ORDER BY name, cores
|
||||
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
|
||||
|
||||

|
|
@ -5,9 +5,9 @@ categories:
|
|||
tags: [SQL]
|
||||
---
|
||||
|
||||
# SQL: The UPDATE query
|
||||
# Update existing data with the SQL `UPDATE` command
|
||||
|
||||
With UPDATE we modify existing records.
|
||||
We use `UPDATE` to modify existing records in our table.
|
||||
|
||||
## Schematic syntax
|
||||
|
||||
|
@ -17,7 +17,7 @@ SET [field]
|
|||
WHERE [conditional expression/filter]
|
||||
```
|
||||
|
||||
## Real example
|
||||
## Example
|
||||
|
||||
```sql
|
||||
UPDATE manufacturer
|
||||
|
@ -25,7 +25,7 @@ SET url = '<http://www.hp.co.uk>'
|
|||
WHERE manufacturer_id = 4; --typically this will be the primary key as you are updating and existing record and need to identify it uniquely
|
||||
```
|
||||
|
||||
## Multiple fields
|
||||
## Update multiple fields
|
||||
|
||||
```sql
|
||||
UPDATE manufacturer
|
29
Databases/SQL/Wildcards_in_SQL.md
Normal file
29
Databases/SQL/Wildcards_in_SQL.md
Normal file
|
@ -0,0 +1,29 @@
|
|||
---
|
||||
categories:
|
||||
- Databases
|
||||
- Programming Languages
|
||||
tags: [SQL]
|
||||
---
|
||||
|
||||
# Wildcards in SQL
|
||||
|
||||
SQL does not use Regex. Instead it has a simpler glob-like syntax for carrying out string matching.
|
||||
|
||||
In order to signal that you wish to compare by a wildcard and not a value, you have to use the `LIKE` keyword. The actual wildcard operator is `%` .
|
||||
|
||||
In an SQL statement, the `%` wild card will match any number of occurrences of any character.
|
||||
Any characters can appear before or after ‘MacBook’ and the record will still be returned:
|
||||
|
||||
```sql
|
||||
SELECT name, cores, release_date
|
||||
FROM model
|
||||
WHERE name LIKE '%MacBook%';
|
||||
```
|
||||
|
||||
This wildcard only filters characters that come after `Raspberry` :
|
||||
|
||||
```sql
|
||||
SELECT name, cores, release_date
|
||||
FROM model
|
||||
WHERE name LIKE 'Raspberry%';
|
||||
```
|
0
Networks/.gitkeep
Normal file
0
Networks/.gitkeep
Normal file
|
@ -1 +0,0 @@
|
|||
/home/thomas/repos/bash_scripts/automate_commit.sh
|
Loading…
Add table
Reference in a new issue