This commit is contained in:
1
Career/Database - SQL/Airflow Dags.md
Normal file
1
Career/Database - SQL/Airflow Dags.md
Normal file
@@ -0,0 +1 @@
|
||||
A DAG (short for directed acyclic graphs) is a model that encapsulates everything needed to execute a workflow. [See this](https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/dags.html)
|
||||
9
Career/Database - SQL/Airflow Tasks.md
Normal file
9
Career/Database - SQL/Airflow Tasks.md
Normal file
@@ -0,0 +1,9 @@
|
||||
A task in the context of airflow is the basic unit of execution. They are arranged into [[Airflow Dags]] and then have upstream and downstream dependencies set between them in order to express the order in which they should be run.
|
||||
|
||||
There are three kinds of tasks:
|
||||
|
||||
1. Operators: they are predefined task templates that you can string together quickly.
|
||||
2. Sensors: special subclass of operators, which are entirely about waiting for an external event to happen.
|
||||
3. A Taskflow-decorated @task, which is a custom python function packaged as a task.
|
||||
|
||||
[See this](https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/tasks.html)
|
||||
20
Career/Database - SQL/Airflow.md
Normal file
20
Career/Database - SQL/Airflow.md
Normal file
@@ -0,0 +1,20 @@
|
||||
# xcom
|
||||
|
||||
XComs stands for cross-communications, and as the name suggests, it allows [[Airflow Tasks]] to talk to each other (because by default, tasks are entirely isolated and can run on seperate machines).
|
||||
|
||||
See [this](https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/xcoms.html)
|
||||
|
||||
# parquets
|
||||
|
||||
**Key Takeaways**
|
||||
|
||||
- What is Parquet: An open-source columnar storage file format for efficient analytics.
|
||||
- Core Benefits: Superior compression, faster query performance (via column pruning and predicate pushdown), and schema evolution support.
|
||||
- Common Alternatives: Compared to row-based (CSV, Avro), columnar (ORC), and table formats (Iceberg, Delta Lake).
|
||||
- DuckDB & MotherDuck: Parquet integrates seamlessly with DuckDB for high-performance SQL queries directly on Parquet files.
|
||||
|
||||
**What is Parquet?**
|
||||
|
||||
Parquet is a columnar storage file format. When data engineers ask 'what is a Parquet file?', the simple answer is that it's a file that stores data in columns, not rows. This Parquet data format is designed for efficient data processing, particularly in the context of big data applications. Developed as part of the Apache Hadoop ecosystem, Parquet has gained widespread adoption due to its ability to optimize storage and query performance.
|
||||
|
||||
[See this](https://motherduck.com/learn-more/why-choose-parquet-table-file-format/)
|
||||
2
Career/Database - SQL/Database MOC.md
Normal file
2
Career/Database - SQL/Database MOC.md
Normal file
@@ -0,0 +1,2 @@
|
||||
- [[Postgres]]
|
||||
- [[Airflow]]
|
||||
@@ -0,0 +1,238 @@
|
||||
# Introduction
|
||||
|
||||
Database security is a crucial part of database administration. It ensures that only authorised users can access, modify, or manage data. Three core concepts used to control access are:
|
||||
|
||||
1. Accounts (logins/users)
|
||||
2. Roles
|
||||
3. Permissions
|
||||
|
||||
These concepts work together to create structured and secure access control inside a database system.
|
||||
|
||||
# 1\. Database Accounts
|
||||
|
||||
A **database account** represents an identity that can connect to the database system. In Microsoft SQL Server this is typically split into two layers:
|
||||
|
||||
- **Login** → Authentication at the server level
|
||||
- **User** → Authorisation inside a specific database
|
||||
|
||||
## Login (Server Level)
|
||||
|
||||
A login allows someone or something to authenticate with the SQL Server instance.
|
||||
|
||||
Example: Creating a login
|
||||
|
||||
``` sql
|
||||
CREATE LOGIN student_user
|
||||
WITH PASSWORD = 'StrongPassword123!';
|
||||
```
|
||||
|
||||
You can also create a login linked to Windows authentication.
|
||||
|
||||
``` sql
|
||||
CREATE LOGIN [DOMAIN\Zaine] FROM WINDOWS;
|
||||
```
|
||||
|
||||
## Database User
|
||||
|
||||
A login must be mapped to a user inside a database before it can access that database.
|
||||
|
||||
Example:
|
||||
|
||||
``` sql
|
||||
USE SchoolDB;
|
||||
|
||||
CREATE USER student_user
|
||||
FOR LOGIN student_user;
|
||||
```
|
||||
|
||||
Now the login can access the **SchoolDB** database as the user **student<sub>user</sub>**.
|
||||
|
||||
# 2\. Permissions
|
||||
|
||||
Permissions define **what actions a user can perform**. These actions include reading data, inserting rows, modifying tables, or executing procedures.
|
||||
|
||||
Common SQL Server permissions include:
|
||||
|
||||
- SELECT → Read data
|
||||
- INSERT → Add new data
|
||||
- UPDATE → Modify data
|
||||
- DELETE → Remove data
|
||||
- EXECUTE → Run stored procedures
|
||||
- ALTER → Modify database objects
|
||||
- CONTROL → Full control over an object
|
||||
|
||||
## Granting Permissions
|
||||
|
||||
Permissions are given using the **GRANT** statement.
|
||||
|
||||
Example: Allow a user to read data from a table.
|
||||
|
||||
``` sql
|
||||
GRANT SELECT
|
||||
ON Students
|
||||
TO student_user;
|
||||
```
|
||||
|
||||
## Grant Multiple Permissions
|
||||
|
||||
``` sql
|
||||
GRANT SELECT, INSERT
|
||||
ON Students
|
||||
TO student_user;
|
||||
```
|
||||
|
||||
This allows the user to read and add new rows.
|
||||
|
||||
## Revoking Permissions
|
||||
|
||||
If a permission should be removed:
|
||||
|
||||
``` sql
|
||||
REVOKE INSERT
|
||||
ON Students
|
||||
FROM student_user;
|
||||
```
|
||||
|
||||
## Denying Permissions
|
||||
|
||||
A **DENY** explicitly blocks an action, even if another role grants it.
|
||||
|
||||
``` sql
|
||||
DENY DELETE
|
||||
ON Students
|
||||
TO student_user;
|
||||
```
|
||||
|
||||
# 3\. Roles
|
||||
|
||||
Roles are collections of permissions that can be assigned to multiple users. They simplify permission management by allowing administrators to assign permissions once and reuse them.
|
||||
|
||||
Instead of granting permissions to many individual users, you grant them to a role.
|
||||
|
||||
Example scenario:
|
||||
|
||||
- Many students should be able to view course data.
|
||||
- Instead of assigning permissions to each student individually, create a role.
|
||||
|
||||
## Creating a Role
|
||||
|
||||
``` sql
|
||||
CREATE ROLE student_role;
|
||||
```
|
||||
|
||||
## Assign Permissions to the Role
|
||||
|
||||
``` sql
|
||||
GRANT SELECT
|
||||
ON Courses
|
||||
TO student_role;
|
||||
```
|
||||
|
||||
## Add Users to the Role
|
||||
|
||||
``` sql
|
||||
ALTER ROLE student_role
|
||||
ADD MEMBER student_user;
|
||||
```
|
||||
|
||||
Now **student<sub>user</sub>** inherits all permissions from **student<sub>role</sub>**.
|
||||
|
||||
# 4\. Built-in Database Roles
|
||||
|
||||
SQL Server includes several predefined roles that already have common permission sets.
|
||||
|
||||
Examples:
|
||||
|
||||
| Role Name | Purpose |
|
||||
| ----------------------- | --------------------------------- |
|
||||
| db<sub>owner</sub> | Full control over the database |
|
||||
| db<sub>datareader</sub> | Read all tables |
|
||||
| db<sub>datawriter</sub> | Insert/update/delete all tables |
|
||||
| db<sub>ddladmin</sub> | Create or modify database objects |
|
||||
|
||||
Example: Add a user to the read-only role.
|
||||
|
||||
``` sql
|
||||
ALTER ROLE db_datareader
|
||||
ADD MEMBER student_user;
|
||||
```
|
||||
|
||||
This allows the user to read all tables without giving modification rights.
|
||||
|
||||
# 5\. Example: Simple University Database Security
|
||||
|
||||
Assume a database called **UniversityDB** with two tables:
|
||||
|
||||
- Students
|
||||
- Courses
|
||||
|
||||
Goal:
|
||||
|
||||
- Students → Read course information
|
||||
- Teachers → Modify course data
|
||||
- Admin → Full control
|
||||
|
||||
## Step 1: Create Roles
|
||||
|
||||
``` sql
|
||||
CREATE ROLE student_role;
|
||||
CREATE ROLE teacher_role;
|
||||
CREATE ROLE admin_role;
|
||||
```
|
||||
|
||||
## Step 2: Assign Permissions
|
||||
|
||||
Student role (read-only):
|
||||
|
||||
``` sql
|
||||
GRANT SELECT
|
||||
ON Courses
|
||||
TO student_role;
|
||||
```
|
||||
|
||||
Teacher role:
|
||||
|
||||
``` sql
|
||||
GRANT SELECT, INSERT, UPDATE
|
||||
ON Courses
|
||||
TO teacher_role;
|
||||
```
|
||||
|
||||
Admin role:
|
||||
|
||||
``` sql
|
||||
GRANT CONTROL
|
||||
ON DATABASE::UniversityDB
|
||||
TO admin_role;
|
||||
```
|
||||
|
||||
## Step 3: Add Users
|
||||
|
||||
``` sql
|
||||
ALTER ROLE student_role ADD MEMBER student_user;
|
||||
ALTER ROLE teacher_role ADD MEMBER teacher_user;
|
||||
ALTER ROLE admin_role ADD MEMBER admin_user;
|
||||
```
|
||||
|
||||
Now permissions are organised through roles instead of assigning them individually.
|
||||
|
||||
# 6\. Why Roles Are Important
|
||||
|
||||
Roles provide several benefits:
|
||||
|
||||
- **Simpler management** → Change permissions in one place
|
||||
- **Scalability** → Works well with many users
|
||||
- **Security consistency** → Reduces risk of incorrect permissions
|
||||
- **Easier auditing** → Clear structure of access control
|
||||
|
||||
Without roles, administrators would need to manually manage permissions for every individual user.
|
||||
|
||||
# Summary
|
||||
|
||||
Database access control relies on three key components:
|
||||
|
||||
- **Accounts** identify who is accessing the system (logins and users).
|
||||
- **Permissions** define what actions can be performed.
|
||||
- **Roles** group permissions together for easier management.
|
||||
|
||||
In Microsoft SQL Server, administrators typically create logins, map them to database users, assign them to roles, and grant permissions to those roles. This layered approach ensures a secure and manageable database system.
|
||||
3
Career/Database - SQL/Postgres.md
Normal file
3
Career/Database - SQL/Postgres.md
Normal file
@@ -0,0 +1,3 @@
|
||||
``` bash
|
||||
psql -h 82.18.104.48 -p 5432 -U zaine -d org_web
|
||||
```
|
||||
10
Career/Database - SQL/SQL Joins.md
Normal file
10
Career/Database - SQL/SQL Joins.md
Normal file
@@ -0,0 +1,10 @@
|
||||
# The SQL JOIN Clause
|
||||
|
||||
The JOIN clause is used to combine rows from two or more tables, based on a related column between them.
|
||||
|
||||
Here are the different types of JOINs in SQL:
|
||||
|
||||
****(INNER) JOIN****: Returns only rows that have matching values in both tables
|
||||
****LEFT (OUTER) JOIN****: Returns all rows from the left table, and only the matched rows from the right table
|
||||
****RIGHT (OUTER) JOIN****: Returns all rows from the right table, and only the matched rows from the left table
|
||||
****FULL (OUTER) JOIN****: Returns all rows when there is a match in either the left or right table
|
||||
Reference in New Issue
Block a user