SQL

History of Database:
The concept of a database dates back to the 1960s, when the first electronic data processing
systems were developed. At the time, data was stored on magnetic tapes or punch cards, and
accessing specific pieces of information was a slow and cumbersome process. In response to this
problem, researchers began developing ways to store and retrieve data more efficiently.

One of the first database systems was the Integrated Data Store (IDS), developed in the late 1960s
by Charles Bachman. IDS used a hierarchical data model to organize information into a tree-like
structure, with each node representing a record in the database. This model proved popular for
many years and was used in many early database systems.

In the 1970s, the relational data model was developed by Edgar Codd, who proposed a way of
representing data as sets of tables with well-defined relationships between them. This model
became the basis for the first commercial relational database management system (RDBMS), known
as Oracle, which was released in 1979.

During the 1980s and 1990s, the use of databases became more widespread, as more and more
businesses and organizations began to rely on computer systems for managing their operations.
Many new database systems were developed during this time, including Microsoft Access, IBM DB2,
and Sybase.

In the early 2000s, the development of open-source database systems, such as MySQL and
PostgreSQL, made it easier for smaller businesses and organizations to use databases without
incurring high licensing costs. Cloud computing and big data technologies also emerged, allowing
organizations to store and analyze vast amounts of data in real-time.

Today, databases are an essential part of modern computing, used in a wide range of applications,
from simple personal databases to large-scale enterprise systems. The evolution of database
technology has been driven by the need to store, manage, and analyze increasingly large and
complex data sets, and this trend is likely to continue as more and more aspects of our lives become
data-driven.

Data:
Data is any collection of facts, figures, or statistics that can be recorded, stored, and processed by a
computer. Data can come in many forms, including text, numbers, images, audio, and video.

Database:
A database is a collection of related data that is stored in a specific format, making it easy to search,
sort, and retrieve specific pieces of information. Databases are used to store and manage large
amounts of data, and they are a crucial part of many modern computer systems.

Types of databases:
Relational databases: This is the most common type of database, where data is stored in tables with
a predefined structure of columns and rows. Relationships between tables are established using
keys. Examples of relational databases include MySQL, Oracle, SQL Server, and PostgreSQL.
SQL
Object-oriented databases: This type of database stores data in objects, which can be manipulated
using object-oriented programming techniques. Examples of object-oriented databases include db4o
and ObjectDB.

NoSQL databases: NoSQL databases are non-relational databases that provide flexible data models
and scaling options. They are used for handling large amounts of unstructured data. Examples of
NoSQL databases include MongoDB, Cassandra, and Couchbase.

Graph databases: These databases store data in nodes and edges, which can be used to represent
complex relationships between data points. Examples of graph databases include Neo4j and
OrientDB.

Document-oriented databases: These databases store data as documents, typically in JSON or XML
format. Each document can have a unique structure and can be updated independently of other
documents. Examples of document-oriented databases include CouchDB and MongoDB.

Time-series databases: These databases are optimized for handling time-stamped data, such as IoT
sensor data, financial market data, or log files. Examples of time-series databases include InfluxDB
and TimescaleDB.

Spatial databases: These databases store spatial data, such as maps, geographic information
systems (GIS), or location-based services. Examples of spatial databases include PostGIS and Oracle
Spatial.

Database Management System

DBMS stands for Database Management System, which is software designed to manage and
manipulate data in a database. A DBMS provides a way to create, modify, and delete data in a
database, as well as retrieve and manipulate data in various ways.

RDBMS stands for Relational Database Management System, which is a type of DBMS that uses a
relational data model to organize data in tables or relations. In an RDBMS, data is stored in a
structured format using rows and columns, and tables can be linked together through relationships.

The key difference between a DBMS and an RDBMS is that an RDBMS uses a specific type of data
model (the relational data model) to organize and manage data, whereas a DBMS may use other
data models, such as hierarchical or network models. RDBMSs are often considered more powerful
and flexible than DBMSs, especially for handling large amounts of structured data, and they are
widely used in modern enterprise applications.

Additionally, RDBMSs have several features that make them distinct from DBMSs, including the use
of SQL (Structured Query Language) for querying and manipulating data, the ability to enforce data
integrity through constraints such as primary keys and foreign keys, and support for transactions to
ensure data consistency and reliability. These features make RDBMSs suitable for handling complex
business applications that require a high degree of data accuracy, consistency, and security.

Some popular examples of RDBMSs include MySQL, Oracle, Microsoft SQL Server, and PostgreSQL.
These systems are used in a wide range of applications, from e-commerce websites and social media
platforms to financial systems and scientific research.

Data Model:
SQL
Object-based design: This methodology emphasizes the use of object-oriented programming
concepts to design a database. It represents data as objects, with properties and methods, and is
used to build object-oriented databases.

Model-based design: This methodology involves creating a high-level model of the database
structure before designing the database. The model can be created using tools such as Entity-
Relationship(ER) diagrams or Unified Modelling Language(UML) diagrams. The model is then
translated into a database schema.

Physical-based design: This methodology involves designing a database with a focus on the physical
storage and performance characteristics of the database. It takes into account factors such as data
distribution, indexing, and partitioning.

Data models are abstract representations of the data that a database contains. They provide a way
to organize and structure data in a way that can be easily understood and manipulated by users and
applications. Here are some common types of data models:

Relational data model: This is the most common data model used by relational databases. It
organizes data into tables, each with a set of predefined columns and rows. The relationships
between tables are established using keys.

Object-oriented data model: This data model is used by object-oriented databases. It represents
data as objects, which can have properties, methods, and relationships with other objects.

Document data model: This model is used by document-oriented databases. It represents data as
flexible, semi-structured documents, typically in JSON or XML format.

Hierarchical data model: This model organizes data in a tree-like structure, with each node having a
parent and zero or more children.

Network data model: This model is similar to the hierarchical model but allows each node to have
multiple parent nodes.

Entity-relationship (ER) data model: This model is used to represent relationships between entities
in a database. It uses entities, attributes, and relationships to represent data.

Dimensional data model: This model is used for data warehousing and business intelligence. It
organizes data into dimensions and facts, with each dimension representing a category of data and
each fact representing a numeric value.

Key-value data model: This model stores data as a collection of key-value pairs, where each key
uniquely identifies a value.

Attributes in DBMS:
Simple attributes: These attributes are atomic and cannot be divided into smaller parts. For
example, the attribute "name" of a person entity would be a simple attribute.

Composite attributes: These attributes can be further divided into smaller parts. For example, the
attribute "address" of a person entity can be broken down into sub-attributes like street, city, and
state.

Single-valued attributes: These attributes can only have a single value for a given entity instance. For
example, the attribute "age" of a person entity would be a single-valued attribute.
SQL
Multi-valued attributes: These attributes can have multiple values for a given entity instance. For
example, the attribute "phone numbers" of a person entity could have multiple values.

Derived attributes: These attributes are derived from other attributes in the database. For example,
the attribute "age" could be derived from the attribute "date of birth".

Null-valued attributes: These attributes have no value for a given entity instance. For example, if the
date of birth of a person is not known, the attribute "date of birth" would be null-valued.

ACID properties:
ACID is an acronym that stands for Atomicity, Consistency, Isolation, and Durability. It is a set of
properties that guarantee reliability and consistency in database transactions. Here's a brief
overview of each component of ACID:

Atomicity: This property ensures that a database transaction is treated as a single "atomic"
operation, which means that either all the changes in the transaction are committed to the database
or none of them are. If any part of the transaction fails, the entire transaction is rolled back to its
original state.

Consistency: This property ensures that a database transaction brings the database from one
consistent state to another. The database should always be in a valid state before and after the
transaction.

Isolation: This property ensures that concurrent transactions do not interfere with each other. Each
transaction should be isolated from other transactions, and changes made in one transaction should
not be visible to other transactions until they are committed.

Durability: This property ensures that once a transaction is committed, its changes are permanent
and cannot be lost. The database should be able to recover from any hardware or software failure
without losing data.

ACID is a fundamental concept in database design, and it is essential for ensuring data integrity and
reliability in applications that rely on database transactions.

Datatypes:
Numeric Data Types:

INT: This data type is used to store whole numbers (integers) that range from -2147483648 to
2147483647 (in most database systems). The exact range can vary depending on the database
system and the implementation.

BIGINT: This data type is used to store large whole numbers (integers) that range from -
9223372036854775808 to 9223372036854775807 (in most database systems). The exact range can
vary depending on the database system and the implementation.

FLOAT: This data type is used to store floating-point numbers with a decimal point. It can store up to
15 digits of precision.

DOUBLE: This data type is similar to FLOAT, but it can store up to 30 digits of precision.
SQL
Character Data Types:

CHAR: This data type is used to store fixed-length character strings. It requires a specified length
when it is defined and pads the string with spaces to reach that length.

VARCHAR: This data type is used to store variable-length character strings. It can store up to a
specified length, but only uses the space required to store the actual string.

TEXT: This data type is used to store large variable-length character strings.

Date and Time Data Types:

DATE: This data type is used to store date values in the format YYYY-MM-DD.

TIME: This data type is used to store time values in the format HH:MM:SS.

DATETIME: This data type is used to store both date and time values in the format YYYY-MM-DD
HH:MM:SS.

TIMESTAMP: This data type is used to store date and time values in a more compact format than
DATETIME.

Boolean Data Types:

BOOLEAN: This data type is used to store Boolean values, which can be either true or false.

Binary Data Types:

BLOB: This data type is used to store large binary objects, such as images or multimedia content.

VARBINARY: This data type is used to store variable-length binary data.

BINARY: This data type is used to store fixed-length binary data.

Other Data Types:

ENUM: This data type is used to store a set of predefined values.

SET: This data type is similar to ENUM, but allows for multiple values to be stored.

JSON: This data type is used to store JSON (JavaScript Object Notation) data.

Constraints:
Constraints in SQL are rules that define what values are allowed to be stored in a table. They help to
enforce data integrity by preventing the insertion of invalid or inconsistent data.

PRIMARY KEY: This constraint is used to define a column (or a combination of columns) that
uniquely identifies each row in a table. It prevents duplicate values from being inserted into the
primary key column and is often used as a reference by foreign keys in related tables.

FOREIGN KEY: This constraint is used to define a column (or a combination of columns) that
references a primary key column in another table. It helps to enforce referential integrity by
preventing the insertion of values that do not exist in the referenced table.
SQL
UNIQUE: This constraint is used to define a column (or a combination of columns) that must contain
unique values. It prevents the insertion of duplicate values in the unique column.

CHECK: This constraint is used to define a condition that must be satisfied for a row to be inserted or
updated in a table. It helps to ensure that the data being inserted is consistent with the business
rules or requirements.

NOT NULL: This constraint is used to define a column that cannot contain NULL values. It helps to
ensure that important data is not missing from the table.

DEFAULT: This constraint is used to define a default value for a column if no value is specified during
an insert operation.

Attributes:
Attributes in SQL are properties that can be assigned to a column to define its behavior or
characteristics.

AUTO_INCREMENT: This attribute is used to define a column that automatically generates a unique
numeric value for each new row inserted into the table. It is often used in conjunction with the
PRIMARY KEY constraint to ensure that each row has a unique identifier.
CREATE TABLE users (
id INT AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(50),
email VARCHAR(50)
);
DEFAULT: This attribute is used to define a default value for a column if no value is specified during
an insert operation.
CREATE TABLE users (
id INT,
name VARCHAR(50),
age INT DEFAULT 18
);
NOT NULL: This attribute is used to define a column that cannot contain NULL values. It helps to
ensure that important data is not missing from the table.
CREATE TABLE users (
id INT AUTO_INCREMENT PRIMARY KEY,
username VARCHAR(50) NOT NULL,
email VARCHAR(50)
);
UNIQUE: This attribute is used to define a column that must contain unique values. It prevents the
insertion of duplicate values in the unique column.
CREATE TABLE users (
id INT AUTO_INCREMENT PRIMARY KEY,
username VARCHAR(50) NOT NULL,
email VARCHAR(50) UNIQUE
);
SQL
CHECK: This attribute is used to define a condition that must be satisfied for a row to be inserted or
updated in a table. It helps to ensure that the data being inserted is consistent with the business
rules or requirements.
ALTER TABLE users ADD CHECK (age >= 18);

FOREIGN KEY: This attribute is used to define a column (or a combination of columns) that
references a primary key column in another table. It helps to enforce referential integrity by
preventing the insertion of values that do not exist in the referenced table.
CREATE TABLE customers (
id INT PRIMARY KEY,
name VARCHAR(50)
);

CREATE TABLE orders (

id INT PRIMARY KEY,
customer_id INT,
amount DECIMAL(10,2),
FOREIGN KEY (customer_id) REFERENCES customers(id)
);

Code:
-- Create a new database
CREATE DATABASE mydatabase;
-- Use the new database
USE mydatabase;
-- Create a new table
CREATE TABLE customers (
id INT PRIMARY KEY,
name VARCHAR(50),
email VARCHAR(50),
phone_number VARCHAR(20)
);
-- Insert data into the table
INSERT INTO customers (id, name, email, phone_number)
VALUES (1, 'John Doe', 'johndoe@email.com', '555-555-5555');
-- Update data in the table
SET SQL_SAFE_UPDATES = 1;
UPDATE customers
SET email='newemail@email.com'
WHERE name='John Doe';
-- Select data from the table
SELECT * FROM customers;
-- Grant privileges to a user
-- Create a new user
CREATE USER 'marketing_team'@'localhost' IDENTIFIED BY 'password';

-- Grant privileges to the new user

GRANT SELECT, INSERT ON mydatabase.customers TO
'marketing_team'@'localhost';
-- Revoke privileges from a user
REVOKE INSERT ON mydatabase.customers FROM
'marketing_team'@'localhost';
-- Start a new transaction
SQL
SET AUTOCOMMIT = 0;
BEGIN;
-- Insert more data into the table
INSERT INTO customers (id, name, email, phone_number)
VALUES (2, 'Jane Smith', 'janesmith@email.com', '555-555-5555');
-- Save the changes to the database
COMMIT;
-- Delete data from the table
DELETE FROM customers WHERE name='Jane Smith';
-- Roll back the transaction
ROLLBACK;

SQL Clauses:
In SQL, a clause is a specific set of keywords and options that are used to define the parameters and
conditions of a database query. There are several different types of clauses in SQL, each with their
own specific purpose and syntax.

SELECT Clause: Used to retrieve data from one or more tables in a database.
SELECT first_name, last_name, email
FROM customers;

WHERE Clause: Used to filter data based on specific conditions.

SELECT first_name, last_name, email
FROM customers
WHERE city = 'New York';

JOIN Clause: Used to combine data from two or more tables based on a common column.
SELECT orders.order_id, customers.first_name, customers.last_name
FROM orders
JOIN customers ON orders.customer_id = customers.customer_id;

GROUP BY Clause: Used to group data based on one or more columns.

SELECT category, COUNT(*) as num_products
FROM products
GROUP BY category;

HAVING Clause: Used to filter data based on conditions that involve aggregates (e.g., COUNT, SUM,
AVG).
SELECT category, AVG(price) as avg_price
FROM products
GROUP BY category
HAVING AVG(price) > 500;

ORDER BY Clause: Used to sort data in ascending or descending order based on one or more
columns.
SELECT product_name, price
FROM products
WHERE category = 'Electronics'
ORDER BY price DESC;
SQL
TOP/LIMIT Clause: Used to limit the number of rows returned by a query.
SQL Server:
SELECT TOP 10 product_name, price
FROM products
ORDER BY price DESC;
Mysql
SELECT product_name, price
FROM products
ORDER BY price DESC
LIMIT 10;

OFFSET Clause: Used in conjunction with the LIMIT clause to specify a starting point for the returned
rows.

SQL Server
SELECT product_name, price
FROM products
ORDER BY price DESC
OFFSET 5 ROWS
FETCH NEXT 5 ROWS ONLY;
MySQL
SELECT product_name, price
FROM products
ORDER BY price DESC
LIMIT 5 OFFSET 5;
INSERT INTO Clause: Used to insert new data into a table.
INSERT INTO customers (first_name, last_name, email, city)
VALUES ('John', 'Doe', 'johndoe@email.com', 'San Francisco');

UPDATE Clause: Used to update existing data in a table.

UPDATE orders
SET status = 'Shipped'
WHERE order_id = 1234;

DELETE Clause: Used to delete data from a table.

DELETE FROM customers
WHERE last_name = 'Smith';

DISTINCT Clause: Used to return only distinct (unique) values from a query.
SELECT DISTINCT category
FROM products;

IN Clause: Used to filter data based on a set of specified values.

SELECT product_name, price
FROM products
WHERE category IN ('Electronics', 'Office Supplies');
SELECT product_name, price
FROM products
WHERE category NOT IN ('Clothing', 'Shoes');
SQL
BETWEEN Clause: Used to filter data based on a range of values.
SELECT *
FROM orders
WHERE order_date BETWEEN '2022-01-01' AND '2022-01-31';

LIKE Clause: Used to filter data based on a pattern matching criteria.

SELECT product_name, price
FROM products
WHERE product_name LIKE '%computer%';

CASE Clause: Used to perform conditional logic within a query.

SELECT order_id, order_date,
CASE
WHEN total_amount > 1000 THEN 'High'
WHEN total_amount > 500 THEN 'Medium'
ELSE 'Low'
END AS amount_level
FROM orders;

ALL/ANY Clause: Used to compare a value to a set of values returned by a subquery. The ALL
keyword requires that all values returned by the subquery meet the comparison criteria, while the
ANY keyword requires that at least one value returned by the subquery meet the comparison
criteria.
SELECT customer_name, city
FROM customers
WHERE city = ALL (SELECT city FROM orders WHERE order_date = '2022-03-
15');
SELECT customer_name, city
FROM customers
WHERE city = ANY (SELECT city FROM orders WHERE order_date = '2022-03-
15');

AS Clause: Used to assign an alias (i.e., alternative name) to a table or column in a query. This can be
useful for improving the readability and clarity of the query results.
SELECT product_name AS name, price AS cost
FROM products;

FETCH Clause: Used to retrieve a specified number of rows from a query, starting at a specified
offset. This can be useful for paginating large sets of data.
Sql server:

SELECT * FROM mytable

ORDER BY id
FETCH FIRST 10 ROWS ONLY;
Mysql
SELECT * FROM mytable
ORDER BY id
LIMIT 3;
SQL
FOR UPDATE/SHARE Clause: Used to lock rows in a table to prevent other transactions from
modifying them while the current transaction is in progress. This can be useful for ensuring data
integrity and preventing conflicts. FOR UPDATE locks the selected rows for update, while FOR SHARE
locks them for read-only access.
SELECT * FROM mytable
WHERE id = 1
FOR UPDATE;
#####################################################################

WINDOW/OVER Clause: Used to perform aggregate functions (e.g., SUM, AVG, MAX) over a specific
window or subset of rows within a result set. This can be useful for calculating running totals,
moving averages, and other types of rolling calculations.
SELECT col1, col2, SUM(col3) OVER (ORDER BY col1) as running_total
FROM mytable;

PARTITION BY Clause: Used in conjunction with the WINDOW/OVER clause to specify how the data
should be partitioned or grouped within the window. This can be useful for calculating aggregates or
other calculations within specific subsets of data.
SELECT col1, col2, AVG(col3) OVER (PARTITION BY col1) as group_average
FROM mytable;

RANK/DENSE_RANK Clause: Used to assign a rank or dense rank to each row in a result set based on
a specified order. This can be useful for ranking items by popularity, sales, or other criteria.
SELECT name, salary, RANK() OVER (ORDER BY salary DESC) as salary_rank
FROM employees;

OFFSET-FETCH Clause: Used to retrieve a specified number of rows from a query, starting at a
specified offset. This is similar to the FETCH clause mentioned earlier, but allows for more precise
control over the starting offset and number of rows to retrieve.
SELECT * FROM mytable
ORDER BY id
OFFSET 10 ROWS
FETCH NEXT 10 ROWS ONLY;
SELECT * FROM mytable
ORDER BY id
OFFSET 10
LIMIT 10;

TRUNCATE Clause: Used to delete all rows from a table, while keeping the table structure intact.
This is similar to the DELETE clause mentioned earlier, but is typically faster and more efficient for
clearing large tables.
TRUNCATE TABLE mytable;
SQL
WITH Clause: Used to define a common table expression (CTE) that can be referenced multiple times
within a single query. This can be useful for simplifying complex queries and reducing the amount of
duplicate code.
WITH sales_data AS (
SELECT product_name, SUM(quantity) AS total_sales
FROM sales
GROUP BY product_name
)
SELECT *
FROM sales_data
WHERE total_sales > 1000;

MERGE Clause: Used to perform an "upsert" operation, which inserts new rows into a table or
updates existing rows based on a specified condition. This can be useful for synchronizing data
between different systems or applications.
MERGE INTO target_table AS t
USING source_table AS s
ON t.id = s.id
WHEN MATCHED THEN
UPDATE SET t.column1 = s.column1, t.column2 = s.column2
WHEN NOT MATCHED THEN
INSERT (id, column1, column2) VALUES (s.id, s.column1, s.column2);

(For SQL Server)

CROSS APPLY/OUTER APPLY Clause:The CROSS APPLY and OUTER APPLY clauses are used in SQL
Server to join a table or a set of rows with a table-valued function.

The CROSS APPLY operator returns only the rows from the left table that produce a result set from
the right table or function. In other words, it returns the intersection of the two tables.

The OUTER APPLY operator, on the other hand, returns all rows from the left table, and the
matching rows from the right table or function. If there is no matching row in the right table or
function, the result will still include the row from the left table with NULL values for the columns
from the right table.

In summary, the CROSS APPLY operator returns only the matching rows between the two tables,
while the OUTER APPLY operator returns all rows from the left table, even if there is no match in the
right table.

CREATE TABLE Customers (

CustomerID INT PRIMARY KEY,
CustomerName VARCHAR(50),
CustomerCity VARCHAR(50)
);

CREATE TABLE Orders (

OrderID INT PRIMARY KEY,
CustomerID INT,
OrderDate DATETIME,
OrderAmount DECIMAL(10,2)
);
SQL
INSERT INTO Customers (CustomerID, CustomerName, CustomerCity) VALUES
(1, 'John Doe', 'New York'),
(2, 'Jane Smith', 'Los Angeles'),
(3, 'Bob Johnson', 'Chicago'),
(4, 'Alice Brown', 'Houston');

INSERT INTO Orders (OrderID, CustomerID, OrderDate, OrderAmount) VALUES

(1, 1, '2022-01-01', 100.00),
(2, 1, '2022-02-01', 200.00),
(3, 2, '2022-03-01', 150.00),
(4, 2, '2022-04-01', 50.00),
(5, 3, '2022-05-01', 300.00);

SELECT c.CustomerID, c.CustomerName, c.CustomerCity, o.OrderID,

o.OrderDate, o.OrderAmount
FROM Customers c
CROSS APPLY (
SELECT TOP 1 OrderID, OrderDate, OrderAmount
FROM Orders
WHERE CustomerID = c.CustomerID
ORDER BY OrderDate DESC
) o;
SELECT o.OrderID, o.OrderDate, o.OrderAmount, c.CustomerID,
c.CustomerName, c.CustomerCity
FROM Orders o
OUTER APPLY (
SELECT CustomerID, CustomerName, CustomerCity
FROM Customers
WHERE CustomerID = o.CustomerID
) c;

EXISTS Clause: Used to check whether a subquery returns any rows. This can be useful for
performing conditional logic and determining whether certain actions should be taken based on the
presence or absence of data.
SELECT customer_name, city
FROM customers
WHERE EXISTS (SELECT * FROM orders WHERE orders.customer_id =
customers.customer_id);

EXISTS Clause: Used to check if a subquery returns any rows.

SELECT customer_id, first_name, last_name
FROM customers
WHERE EXISTS (
SELECT *
FROM orders
WHERE orders.customer_id = customers.customer_id
);

UNION Clause: Used to combine the results of two or more SELECT statements.
SELECT product_name
FROM products
WHERE category = 'Electronics'
SQL
UNION
SELECT product_name
FROM products
WHERE category = 'Office Supplies';

Joins in SQL
In SQL, a join is used to combine rows from two or more tables based on a related column between
them. Here are the most commonly used types of joins in SQL:

INNER JOIN:

The INNER JOIN returns only the matching rows between two tables based on the specified
condition. Here's an example:
SELECT *
FROM orders
INNER JOIN customers
ON orders.customer_id = customers.id;

This query joins the orders and customers tables on the customer_id column and returns only the
rows where there is a match.

LEFT JOIN:

The LEFT JOIN returns all the rows from the left table and the matching rows from the right table, or
NULL values for the right table if there is no match. Here's an example:
SELECT *
FROM customers
LEFT JOIN orders
ON customers.id = orders.customer_id;
SQL
This query returns all the rows from the customers table, and only the matching rows from the
orders table. If there is no matching row in the orders table, NULL values are returned for the
columns in the orders table.

RIGHT JOIN:

The RIGHT JOIN returns all the rows from the right table and the matching rows from the left table,
or NULL values for the left table if there is no match. Here's an example:
SELECT *
FROM orders
RIGHT JOIN customers
ON orders.customer_id = customers.id;

This query returns all the rows from the orders table, and only the matching rows from the
customers table. If there is no matching row in the customers table, NULL values are returned for
the columns in the customers table.

FULL OUTER JOIN:

The FULL OUTER JOIN returns all the rows from both tables and NULL values for any non-matching
rows. Here's an example:
SELECT *
FROM customers
FULL OUTER JOIN orders
ON customers.id = orders.customer_id;

This query returns all the rows from both the customers and orders tables, and NULL values for any
non-matching rows in either table.

CROSS JOIN:

The CROSS JOIN returns the Cartesian product of the two tables, which means all possible
combinations of rows between the two tables. Here's an example:
SELECT *
FROM customers
CROSS JOIN products;

This query returns all possible combinations of rows between the customers and products tables.

Keys:
In SQL, keys are used to uniquely identify a record or a set of records within a table. There are
several types of keys in SQL, including:

● Primary Key: A primary key is a unique identifier for a record in a table. It must be unique
and not null. Each table can have only one primary key.
● Foreign Key: A foreign key is a field in a table that refers to the primary key of another table.
It is used to establish a relationship between two tables.
● Candidate Key: A candidate key is a column or set of columns in a table that can uniquely
identify a record. It is similar to a primary key, but a table can have more than one candidate
key.
SQL
● Super Key: A super key is a combination of columns that can uniquely identify a record in a
table. It may contain extra columns that are not required to identify a record.
● Unique Key: A unique key is a constraint that ensures that a column or set of columns has
unique values. It can be used to enforce uniqueness on a column that is not a primary key.

Keys are an essential concept in SQL databases and are used to enforce data integrity and maintain
consistency between related tables.

Wildcards:
Wildcards in SQL are special characters used to match one or more characters in a string. They are
commonly used in SQL queries to perform pattern matching or to search for specific values in a
database.

The two most commonly used wildcards in SQL are the percent sign (%) and underscore (_). The
percent sign represents zero or more characters, while the underscore represents a single character.
Here are some examples of how to use these wildcards in SQL:

Using the percent sign:

-- Query 1: Retrieve all employees whose last name starts with 'Sm'
SELECT *
FROM employees
WHERE last_name LIKE 'Sm%';

-- Query 2: Retrieve all products whose name contains the word 'widget'
SELECT *
FROM products
WHERE product_name LIKE '%widget%';

Using the underscore:

-- Query 1: Retrieve all customers whose phone number starts with '555-1' and
has two more digits in the middle and four more digits at the end
SELECT *
FROM customers
WHERE phone_number LIKE '555-1__-____';
-- Query 2: Retrieve all orders whose ID starts with '10' and has one more
digit after it
SELECT *
FROM orders
WHERE order_id LIKE '10_';

Wildcards can also be combined with other SQL keywords to perform more complex searches. For
example, you can use wildcards with the IN keyword to search for values in a list, or with the NOT
keyword to exclude certain values from a search.

Sub-Query:
In SQL, a subquery is a query that is nested inside another query. It is used to retrieve data from one
or more tables based on the result of an outer query. A subquery can be used in various ways, such
as filtering, sorting, or joining data from different tables.

Here's an example of how to use a subquery in SQL:

SQL
SELECT * FROM orders WHERE customer_id IN (SELECT customer_id FROM
customers WHERE country = 'USA');

In this example, the subquery (SELECT customer_id FROM customers WHERE country = 'USA') is
nested inside the outer query SELECT * FROM orders WHERE customer_id IN (...). The subquery
returns a list of all customer IDs from the customers table where the country is 'USA'. The outer
query then uses this list to retrieve all orders that belong to those customers.

Subqueries can also be used in conjunction with other SQL keywords, such as SELECT, FROM,
WHERE, GROUP BY, HAVING, and JOIN. Here are some other examples:

Using a subquery with the SELECT statement:

SELECT customer_name, (SELECT COUNT(*) FROM orders WHERE
orders.customer_id = customers.customer_id) AS order_count FROM
customers;

This query returns a list of all customer names with the number of orders they have placed.

Using a subquery with the FROM statement:

SELECT products.product_name, subquery.total_sales FROM products INNER
JOIN (SELECT product_id, SUM(quantity * price) AS total_sales FROM
order_details GROUP BY product_id) AS subquery ON products.product_id =
subquery.product_id;

This query returns a list of all product names with the total sales for each product, calculated by
multiplying the quantity and price of each order detail in the order_details table.

Overall, subqueries are a powerful tool in SQL that allow you to perform complex queries and
retrieve data from multiple tables based on various conditions.

Normalization
Normalization is a database design technique used to reduce data redundancy and improve data
integrity. It involves breaking down a large table into smaller, more manageable tables and
establishing relationships between them.

In SQL, normalization is typically achieved through the use of primary and foreign keys. Primary keys
are unique identifiers for each row in a table, while foreign keys are used to establish relationships
between tables by referencing the primary key of another table.

There are several levels of normalization, referred to as normal forms, each with its own set of rules
and requirements. The most common normal forms are:

● First normal form (1NF): This requires that each table cell contains a single value and that
each column has a unique name.

OrderID ProductName Qty

123 Apples, Oranges, Bananas, Grapes 2, 3, 1, 4

SQL
This table violates 1NF because the ProductName and Qty columns contain multiple values
separated by commas.

To normalize this table to 1NF, you could create a new row for each product and its
corresponding quantity:

OrderID ProductName Qty

123 Apples 2

123 Oranges 3

123 Bananas 1

123 Grapes 4

● Second normal form (2NF): This requires that the table is in 1NF and that each non-key
column is functionally dependent on the table's primary key.

OrderID ProductName SupplierName SupplierCity Qty Price

1 Apples Supplier1 New York 2 0.5

1 Apples Supplier2 Los Angeles 3 0.6

2 Oranges Supplier1 New York 1 0.7

2 Oranges Supplier2 Los Angeles 2 0.8

This table violates 2NF because the Price column is dependent on both the ProductName
and SupplierName columns, which together form a composite primary key.

To normalize this table to 2NF, you could create a new table for the supplier information:

SupplierID SupplierName SupplierCity

1 Supplier1 New York

2 Supplier2 Los Angeles

SQL
And then create a new table to represent the order details:

OrderID ProductID SupplierName Qty Price

1 1 1 2 0.5

1 1 2 3 0.6

2 2 1 1 0.7

2 2 2 2 0.8

● Third normal form (3NF): This requires that the table is in 2NF and that each non-key
column is not dependent on another non-key column.

OrderID ProductName Category Category Qty

Description

1 Apples Fruit Contains 0.5

fruit

2 Oranges Fruit Contains 0.6

fruit

3 Flour Baking Used for 0.7

baking

4 Milk Dairy Contains 0.8

dairy
This table violates 3NF because the CategoryDescription column is dependent on the
Category column, which is not part of the primary key.

To normalize this table to 3NF, you could create a new table for the categories:

CategoryID Category Category Description

1 Fruit Contains Fruit

2 Baking Used for baking

3 Dairy Contains Dairy

SQL
And then create a new table for the order details:

OrderID ProductName CategoryID Qty

1 Apple 1 2

2 Oranges 1 3

3 Flour 2 4

4 Milk 3 1

● Boyce-Codd normal form (BCNF): This requires that every determinant is a candidate key. In
other words, every non-trivial functional dependency must be a dependency on a superkey.

ProductID ProductName CategoryID CategoryName

1 Apple 1 Fruit

2 Oranges 1 Fruit

3 Flour 2 Baking

4 Milk 3 Dairy

5 Cheese 3 Dairy

This table violates BCNF because the CategoryName column is dependent on the CategoryID
column, which is not a candidate key.

To normalize this table to BCNF, you could create a new table for the categories:

CategoryID CategoryName

1 Fruit

2 Baking

3 FlourDairy

And then create a new table for the products:

SQL
● Fourth normal form (4NF): This requires that there are no multi-valued dependencies. In
other words, each attribute should depend only on the candidate keys and not on other non-
key attributes.

OrderID CustomerName ProductID ProductName

1 Alice 1 Apples

2 Alice 2 Oranges

3 Alice 3 Flour

4 Bob 2 Oranges

5 Bob 3 Flour

This table violates 4NF because there is a multi-valued dependency between the OrderID
and ProductID columns, both of which are part of the primary key.

To normalize this table to 4NF, you could create a new table for the orders:

OrderID CustomerName

1 Alice

2 Bob

And then create a new table for the order items:

OrderID ProductID qty

1 1 2

1 2 3

1 3 4

2 2 5

2 3 6

● Fifth normal form (5NF) or Project-Join normal form (PJNF): This requires that there are no
join dependencies between two or more candidate keys.
SQL
Each normal form builds on the previous one, and higher normal forms generally result in more
complex database designs and more stringent requirements for data integrity. Choosing an
appropriate level of normalization for a database depends on factors such as the complexity of the
data, the types of queries that will be run, and the performance requirements of the application.

Normalization can help improve the performance of a database by reducing the amount of
redundant data and ensuring data consistency. However, it can also result in a more complex
database design, and it may require more complex queries to retrieve data.

Database: Company

emp_id, first_name, last_name, birth_date, sex, salary, super_id, branch_id

100, David Wallace, 1967-11-17, M, 250000, NULL, 1
101, Jan Levinson, 1961-05-11, F, 110000, 100, 1
102, Michael Scott, 1964-03-15, M, 75000, 100, 2
103, Angela Martin, 1971-06-25, F, 63000, 102, 2
104, Kelly Kapoor, 1980-02-05, F, 55000, 102, 2
105, Stanley Hudson, 1958-02-19, M, 69000, 102, 2
106, Josh Porter, 1969-09-05, M, 78000, 100, 3
107, Andy Bernard, 1973-07-22, M, 65000, 106, 3
108, Jim Halpert, 1978-10-01, M, 71000, 106, 3

branch_id, branch_name, mgr_id, mgr_start_date

1, Corporate, 100, 2006-02-09
2, Scranton, 102, 1992-04-06
SQL
3, Stamford, 106, 1998-02-13

client_id, client_name, branch_id

400, ‘Dunmore Highschool’, 2
401, ‘Lackawana Country’, 2
402, ‘FedEx’ ,3
403, ‘John Daly Law, LLC’, 3
404, ‘Scranton Whitepages’, 2
405, ‘Times Newspaper’, 3
406, ‘FedEx’, 2

works_with
emp_id, client_id, total_sales
105, 400, 55000
102, 401, 267000
SQL
108, 402, 22500
107, 403, 5000
108, 403, 12000
105, 404, 33000
107, 405, 26000
102, 406, 15000
105, 406, 130000

Branch supplier
branch_id, supplier_name, supply_type
2, Hammer Mill, Paper
2, Uni-ball, Writing Utensils
3, Patriot Paper, Paper
2, J.T. Forms & Labels, Custom Forms
3, Uni-ball, Writing Utensils
3, Hammer Mill, Paper
3, Stamford Lables, Custom Forms

Query
-- 1. Find all employees
Select * from employee;
-- 2. Find all clients
-- 3. Find all employees ordered by salary
-- 4. Find all employees ordered by sex then first name
-- 5. Find the first 5 employees in the table
-- 6. Find the first and last names of all employees
-- 7. Find the forename and surnames names of all employees
-- 8. Find out all the different genders
-- 9. Find all male employees
-- 10. Find all employees at branch 2
-- 11. Find all employee's id's and names who were born after 1969
-- 12. Find all female employees at branch 2
-- 13. Find all employees who are female & born after 1969 or who make
over 80000
-- 14. Find all employees born between 1970 and 1975
-- 15. Find all employees named Jim, Michael, Johnny or David

-----------------------------------------------------------------------
------------------------------Function---------------------------------
-----------------------------------------------------------------------
-- Find the number of employees
-- Find the number of supervisor
-- Find the number of females employees born after 1970
-- Find the average of all employee's salaries
-- Find the sum of all employee's salaries
-- Find out how many males and females there are
-- Find the total sales of each salesman
-- Find the total amount of money spent by each client

-----------------------------------------------------------------------
----------------------Wild Cards---------------------------------------
-----------------------------------------------------------------------
SQL
-- % = any # characters, _ = one character

-- Find any client's who are an LLC

-- Find any branch suppliers who are in the label business
-- Find any employee born on the 10th day of the month
-- Find any clients who are schools

------------------------------------------------------------------
--------------------------Union-----------------------------------
------------------------------------------------------------------

-- Find a list of employee and branch names

-- Find a list of all clients & branch suppliers' names

------------------------------------------------------------------
--------------------------Other-----------------------------------
------------------------------------------------------------------

-- Add the extra branch

-- Find names of all employees who have sold over 50,000
-- Find all clients who are handles by the branch that Michael Scott
manages
-- Find the names of employees who work with clients handled by the
scranton branch
-- Find the names of all clients who have spent more than 100,000
dollars

SQL V/s NoSQL

NoSQL (Not Only SQL) is a type of database management system that is designed to handle large
volumes of unstructured or semi-structured data. Unlike SQL databases, which use a fixed schema to
organize data into tables, NoSQL databases use flexible data models that allow data to be stored in a
variety of formats, such as key-value, document, column-family, and graph databases.

NoSQL databases are often used for big data applications, real-time web applications, and other
applications that require fast and flexible data access. They are designed to be highly scalable, and
can be easily distributed across multiple servers to handle large volumes of data and traffic.

There are several types of NoSQL databases, each with its own strengths and weaknesses. Some of
the most popular NoSQL databases include:

● Document databases: These databases store data in JSON or XML documents, which are
flexible and easily scalable.
● Key-value stores: These databases store data as key-value pairs, which are simple and fast
to retrieve.
● Column-family databases: These databases store data in columns rather than rows, which
can improve performance and scalability.
● Graph databases: These databases store data as nodes and edges, which can be used to
represent complex relationships and hierarchies.

NoSQL databases offer several advantages over SQL databases, including scalability, flexibility, and
performance. However, they may be less suitable for applications that require strong data
consistency, strict schemas, and complex querying capabilities.
SQL
SQL (Structured Query Language) and NoSQL (Not Only SQL) are two types of database management
systems with different approaches to handling data.

SQL databases are relational databases that store data in tables with predefined schemas. Data is
organized into columns and rows, and relationships between tables are established through the use
of foreign keys. SQL databases are widely used for transactional and analytical applications, and they
are known for their ability to handle complex queries and large amounts of structured data.

NoSQL databases, on the other hand, are non-relational databases that store data in flexible,
document-like structures. They can handle unstructured and semi-structured data and are designed
to scale horizontally across multiple servers. NoSQL databases are often used for real-time web
applications and big data analytics, where high-speed processing of large volumes of data is
required.

Some key differences between SQL and NoSQL databases include:

● Schema: SQL databases have a fixed schema that must be defined before data can be
inserted, while NoSQL databases allow for dynamic and flexible schemas that can be
adjusted as needed.
● Scalability: NoSQL databases are designed to scale horizontally across multiple servers,
while SQL databases are typically scaled vertically by adding more resources to a single
server.
● Query Language: SQL databases use SQL as the query language, which is standardized and
widely used, while NoSQL databases use a variety of query languages depending on the
database type.
● Data Integrity: SQL databases enforce strict data integrity rules, while NoSQL databases
prioritize flexibility over data integrity.

Advantages of SQL over NoSQL databases:

● Better support for complex queries: SQL databases are optimized for complex queries that
require joining multiple tables, filtering data based on multiple criteria, and aggregating
data. This makes them well-suited for business intelligence, data warehousing, and other
applications that require advanced analytics.
● Strong data consistency: SQL databases enforce strong data consistency rules, which ensure
that data is always valid and up-to-date. This is important in applications where data
integrity is critical, such as financial systems, e-commerce sites, and healthcare applications.
● Well-established standards: SQL is a well-established and widely used standard for querying
relational databases. This means that there are many tools, libraries, and frameworks
available for working with SQL databases, which can simplify development and
maintenance.
● Better security: SQL databases have been around for a long time and have a proven track
record of security. They provide features like access control, encryption, and transactional
integrity that make them more secure than some NoSQL databases.
● ACID-compliant transactions: SQL databases are designed to ensure ACID-compliant
transactions, which stands for Atomicity, Consistency, Isolation, and Durability. This means
that database transactions are guaranteed to be consistent, even in the event of power
outages, hardware failures, or other unforeseen events.
SQL
In summary, SQL databases offer better support for complex queries, strong data consistency, well-
established standards, better security, and ACID-compliant transactions, making them well-suited for
applications where data integrity, security, and advanced analytics are important.

Advantages of NoSQL over SQL databases:

Flexible data models: NoSQL databases offer a flexible data model that can handle unstructured,
semi-structured, and complex data, making them well-suited for handling large volumes of varied
data types, including multimedia data.

● Scalability: NoSQL databases can scale horizontally by adding more servers to a cluster,
making them a good choice for high-traffic web applications or big data applications that
need to handle massive amounts of data.
● High performance: NoSQL databases are designed for high performance and can handle
millions of transactions per second. They use distributed architectures that enable parallel
processing, which improves query performance and reduces latency.
● Lower cost: NoSQL databases are often less expensive to set up and maintain than SQL
databases, especially when it comes to scaling. This is because they are designed to run on
commodity hardware, which is generally less expensive than high-end servers.
● Schema flexibility: NoSQL databases do not have a fixed schema, which means that data can
be added or changed on the fly, without having to alter the database schema or interrupt
service. This can be an advantage in applications where data models are subject to frequent
change or evolution.

In summary, NoSQL databases offer flexible data models, scalability, high performance, lower cost,
and schema flexibility, making them well-suited for handling big data, unstructured data, and high-
traffic web applications.

SQL Connection
MySQL
Using mysql.connector
pip install mysql-connector-python
import mysql.connector
# Connect to the database
cnx = mysql.connector.connect(user='username', password='password',
host='localhost', database='mydatabase')
# Create a cursor object
cursor = cnx.cursor()
# Execute a query
query = "SELECT * FROM mytable"
cursor.execute(query)
# Fetch the results
results = cursor.fetchall()
# Print the results
for row in results:
SQL
print(row)
# Close the cursor and connection
cursor.close()
cnx.close()

Using sqlalchemy
from sqlalchemy import create_engine
# Create a connection to the database
engine =
create_engine('mysql+mysqlconnector://username:password@localhost/
mydatabase')
# Execute a query and fetch the results
with engine.connect() as conn:
result = conn.execute("SELECT * FROM mytable")
for row in result:
print(row)

PostgreSQL
Using psycopg2
import psycopg2
# Connect to the database
conn = psycopg2.connect(dbname='mydatabase', user='username',
password='password', host='localhost')
# Create a cursor object
cursor = conn.cursor()
# Execute a query
query = "SELECT * FROM mytable"
cursor.execute(query)
# Fetch the results
results = cursor.fetchall()
# Print the results
for row in results:
print(row)
# Close the cursor and connection
cursor.close()
conn.close()

Using sqlalchemy
from sqlalchemy import create_engine
# Create a connection to the database
engine =
create_engine('postgresql://username:password@localhost/mydatabase')
# Execute a query and fetch the results
with engine.connect() as conn:
result = conn.execute("SELECT * FROM mytable")
for row in result:
print(row)

SQL Server
Using pyodbc
SQL
import pyodbc
# Connect to the database
conn = pyodbc.connect('DRIVER={SQL
Server};SERVER=servername;DATABASE=mydatabase;UID=username;PWD=password')
# Create a cursor object
cursor = conn.cursor()
# Execute a query query = "SELECT * FROM mytable"
cursor.execute(query)
# Fetch the results
results = cursor.fetchall()
# Print the results
for row in results:
print(row)
# Close the cursor and connection
cursor.close()
conn.close()

Using sqlalchemy
from sqlalchemy import create_engine
# Create a connection to the database
engine =
create_engine('mssql+pyodbc://username:password@servername/mydatabase?
driver=SQL+Server')
# Execute a query and fetch the results
with engine.connect() as conn:
result = conn.execute("SELECT * FROM mytable")
for row in result:
print(row)

Push Data from python to SQL:

import pandas as pd
from sqlalchemy import create_engine
# Read the CSV file into a pandas dataframe
df = pd.read_csv('mydata.csv')
# Create a connection to the database
engine =
create_engine('postgresql://username:password@localhost/mydatabase')
# Use pandas to write the dataframe to the database
df.to_sql('mytable', con=engine, if_exists='replace', index=False)

Normalisation updated:
SQL
The "CustomerName" column is not atomic because it contains both the customer's first and last
name. To make this table 1NF, we need to split the "CustomerName" column into two separate
columns: "CustomerFirstName" and "CustomerLastName".

1NF stands for "First Normal Form," and it is the first step in the normalization process. The goal of
1NF is to ensure that each table has a primary key and that all data is atomic.

Atomicity means that each column should contain only one piece of data.

Now each column contains only one piece of data, and the table has a primary key (the
"OrderNumber" column). This table is now in 1NF.

2NF stands for "Second Normal Form," and it builds upon the requirements of 1NF. The goal of 2NF
is to eliminate partial dependencies, which occur when a non-key attribute is functionally dependent
on only part of the primary key.

To understand this, let's first define what a functional dependency is. A functional dependency exists
when the value of one attribute (the dependent attribute) is determined by the value of another
attribute (the determinant attribute).

The "Price" attribute is functionally dependent on the combination of "OrderNumber" and

"ProductName", because for each combination of these two attributes, there is only one
corresponding "Price" value.

Now let's consider partial dependencies. A partial dependency occurs when a non-key attribute is
functionally dependent on only part of the primary key. In the example above, there are no partial
dependencies because the "Price" attribute is functionally dependent on the entire primary key.
SQL
In this version of the table, "ProductCategory" is functionally dependent on "ProductName", but
"ProductName" is only part of the primary key. This means that "ProductCategory" is only partially
dependent on the primary key, and the table is not in 2NF.

To put this table in 2NF, we need to split it into two tables: "Orders" and "Products".

The "Orders" table will have the following attributes:

OrderNumber (primary key)
CustomerFirstName
CustomerLastName
OrderDate

And the "Products" table will have the following attributes:

ProductName (primary key)
Price
ProductCategory
The "OrderDetails" table will be deleted, and its attributes will be split between the "Orders" and
"Products" tables.

The "OrderNumber" attribute is the primary key in the "Orders" table, and the "ProductName"
attribute is the primary key in the "Products" table.

The "Quantity" attribute from the original "OrderDetails" table is no longer included, as it is not
functionally dependent on the primary key of either table. Instead, it can be added to a new table
called "OrderLineItems", which links the "Orders" and "Products" tables using foreign keys.
SQL

In this table, "OrderNumber" and "ProductName" together make up the primary key, and "Quantity"
is functionally dependent on both of them.

By splitting the original table into three separate tables, we have eliminated partial dependencies
and ensured that each attribute is only functionally dependent on the primary key of its respective
table. This means that our tables are now in 2NF.

For DateTime
SELECT NOW(); -- returns the current date and time
SELECT DATE('2022-10-15 08:30:00'); -- returns the date portion of the given datetime value
SELECT TIME('2022-10-15 08:30:00'); -- returns the time portion of the given datetime value
SELECT YEAR('2022-10-15'); -- returns the year of the given date
SELECT MONTH('2022-10-15'); -- returns the month of the given date
SELECT DAY('2022-10-15'); -- returns the day of the given date
SELECT HOUR('08:30:00'); -- returns the hour of the given time
SELECT MINUTE('08:30:00'); -- returns the minute of the given time
SELECT SECOND('08:30:00'); -- returns the second of the given time
SELECT WEEKDAY('2022-10-15'); -- returns the day of the week for the given date starting
from monday as 0.
SELECT DATEDIFF('2022-10-15', '2022-10-10'); -- returns the number of days between the two dates
SELECT DATE_ADD('2022-10-15', INTERVAL 1 WEEK); -- adds one week to the given date
SELECT DATE_SUB('2022-10-15', INTERVAL 1 MONTH); -- subtracts one month from the given date
SELECT CONVERT("2017-08-29", DATE); – Converts a string to date format
SELECT DATE_FORMAT("2019-05-10 19:30:10", "%d/%m/%Y %h:%i %p"); – Used to change format of
a date.
TIMESTAMPDIFF(‘Month’,start_date,end_date);
STR_TO_DATE(Date_to_convert, '%d-%m-%Y');

Triggers
In SQL, there are two types of triggers:

Before Trigger: This trigger is executed before the actual data modification event (such as INSERT,
UPDATE or DELETE) occurs. It is mainly used to validate data and/or perform data manipulations
before the actual data modification happens.
SQL
After Trigger: This trigger is executed after the actual data modification event occurs. It is mainly
used to audit data, perform data manipulations or send notifications after the data modification
happens.

Both before and after triggers can be defined to execute for one or more of the following events:

INSERT: Trigger will be fired for each INSERT statement.

UPDATE: Trigger will be fired for each UPDATE statement.
DELETE: Trigger will be fired for each DELETE statement.

-- Create a new database

CREATE DATABASE IF NOT EXISTS mydatabase;
-- Switch to the new database
USE mydatabase;
-- Create a new table for storing customer data
DROP TABLE IF EXISTS customers;
CREATE TABLE customers (
id INT NOT NULL AUTO_INCREMENT,
first_name VARCHAR(50) NOT NULL,
last_name VARCHAR(50) NOT NULL,
email VARCHAR(100) NOT NULL,
phone VARCHAR(20),
PRIMARY KEY (id)
);
-- Create a new table for storing customer log data
DROP TABLE IF EXISTS customers_log;
CREATE TABLE customers_log (
id INT NOT NULL,
action VARCHAR(10) NOT NULL,
timestamp DATETIME NOT NULL
);
-- Create a trigger to log changes to the customers table
DELIMITER $$
DROP TRIGGER IF EXISTS customers_log_changes;
CREATE TRIGGER customers_log_changes
AFTER INSERT ON customers
FOR EACH ROW
BEGIN
INSERT INTO customers_log (id, action, timestamp)
VALUES (NEW.id, 'insert', NOW())
ON DUPLICATE KEY UPDATE timestamp = NOW();
END$$
DELIMITER ;
-- Insert some sample data into the customers table
INSERT INTO customers (first_name, last_name, email, phone)
VALUES
('John', 'Doe', 'johndoe@example.com', '555-1234'),
('Jane', 'Smith', 'janesmith@example.com', '555-5678'),
('Bob', 'Johnson', 'bobjohnson@example.com', '555-9012');
-- View the contents of the customers table
SELECT * FROM customers;
-- View the contents of the customers_log table
SELECT * FROM customers_log;
SQL
Views:
Create View:
CREATE VIEW view_name AS
SELECT column1, column2, ...
FROM table_name
WHERE condition;

Update View:
CREATE OR REPLACE VIEW view_name AS
SELECT column1, column2, ...
FROM table_name
WHERE condition;

Remove View:
DROP VIEW view_name;

– To get floor integer value(lower) of a fraction:

SELECT floor(value);

To get ceiling integer value(higher) of a fraction:

SELECT CEILING(value);

Create function syntax

A user-defined function is a way to extend MySQL with a new function that

works like a native MySQL function.
CREATE [AGGREGATE] FUNCTION function_name
RETURNS {STRING|INTEGER|REAL|DECIMAL}

To create a function, you must have the INSERT privilege for the <mysql>
database.

Split delimited strings

The following example function takes 3 parameters, performs an operation

using an SQL function, and returns the result.

Function

SET GLOBAL log_bin_trust_function_creators = 1;

CREATE FUNCTION SPLIT_STR(
x VARCHAR(255),
SQL
delim VARCHAR(12),
pos INT
)
RETURNS VARCHAR(255)
RETURN REPLACE(SUBSTRING(SUBSTRING_INDEX(x, delim, pos),
LENGTH(SUBSTRING_INDEX(x, delim, pos -1)) + 1),
delim, '');

Usage
SELECT SPLIT_STR(string, delimiter, position)

Example
SELECT SPLIT_STR('a|bb|ccc|dd', '|', 3) as third;

+-------+
| third |
+-------+
| ccc |
+-------+