SQLNotesForProfessionals.pdf
SQLNotesForProfessionals.pdf
About ................................................................................................................................................................................... 1
Chapter 1: Getting started with SQL ................................................................................................................... 2
Section 1.1: Overview ...................................................................................................................................................... 2
Chapter 2: Identifier .................................................................................................................................................... 3
Section 2.1: Unquoted identifiers .................................................................................................................................. 3
Chapter 3: Data Types ............................................................................................................................................... 4
Section 3.1: DECIMAL and NUMERIC ............................................................................................................................ 4
Section 3.2: FLOAT and REAL ....................................................................................................................................... 4
Section 3.3: Integers ...................................................................................................................................................... 4
Section 3.4: MONEY and SMALLMONEY ...................................................................................................................... 4
Section 3.5: BINARY and VARBINARY .......................................................................................................................... 4
Section 3.6: CHAR and VARCHAR ................................................................................................................................ 5
Section 3.7: NCHAR and NVARCHAR .......................................................................................................................... 5
Section 3.8: UNIQUEIDENTIFIER ................................................................................................................................... 5
Chapter 4: NULL ............................................................................................................................................................ 6
Section 4.1: Filtering for NULL in queries ..................................................................................................................... 6
Section 4.2: Nullable columns in tables ....................................................................................................................... 6
Section 4.3: Updating fields to NULL ........................................................................................................................... 6
Section 4.4: Inserting rows with NULL fields ............................................................................................................... 7
Chapter 5: Example Databases and Tables .................................................................................................... 8
Section 5.1: Auto Shop Database ................................................................................................................................. 8
Section 5.2: Library Database .................................................................................................................................... 10
Section 5.3: Countries Table ....................................................................................................................................... 13
Chapter 6: SELECT ...................................................................................................................................................... 14
Section 6.1: Using the wildcard character to select all columns in a query .......................................................... 14
Section 6.2: SELECT Using Column Aliases ............................................................................................................... 15
Section 6.3: Select Individual Columns ...................................................................................................................... 18
Section 6.4: Selecting specified number of records ................................................................................................. 19
Section 6.5: Selecting with Condition ......................................................................................................................... 20
Section 6.6: Selecting with CASE ................................................................................................................................ 20
Section 6.7: Select columns which are named after reserved keywords .............................................................. 21
Section 6.8: Selecting with table alias ....................................................................................................................... 21
Section 6.9: Selecting with more than 1 condition .................................................................................................... 22
Section 6.10: Selecting without Locking the table .................................................................................................... 23
Section 6.11: Selecting with Aggregate functions ..................................................................................................... 23
Section 6.12: Select with condition of multiple values from column ....................................................................... 24
Section 6.13: Get aggregated result for row groups ................................................................................................ 24
Section 6.14: Selection with sorted Results ................................................................................................................ 25
Section 6.15: Selecting with null .................................................................................................................................. 25
Section 6.16: Select distinct (unique values only) ..................................................................................................... 25
Section 6.17: Select rows from multiple tables ......................................................................................................... 26
Chapter 7: GROUP BY ............................................................................................................................................... 27
Section 7.1: Basic GROUP BY example ...................................................................................................................... 27
Section 7.2: Filter GROUP BY results using a HAVING clause ................................................................................. 28
Section 7.3: USE GROUP BY to COUNT the number of rows for each unique entry in a given column
................................................................................................................................................................................ 28
Section 7.4: ROLAP aggregation (Data Mining) ....................................................................................................... 29
Chapter 8: ORDER BY ............................................................................................................................................... 31
Section 8.1: Sorting by column number (instead of name) .................................................................................... 31
Section 8.2: Use ORDER BY with TOP to return the top x rows based on a column's value ............................... 31
Section 8.3: Customizeed sorting order .................................................................................................................... 32
Section 8.4: Order by Alias ......................................................................................................................................... 32
Section 8.5: Sorting by multiple columns .................................................................................................................. 33
Chapter 9: AND & OR Operators ......................................................................................................................... 34
Section 9.1: AND OR Example ..................................................................................................................................... 34
Chapter 10: CASE ......................................................................................................................................................... 35
Section 10.1: Use CASE to COUNT the number of rows in a column match a condition ...................................... 35
Section 10.2: Searched CASE in SELECT (Matches a boolean expression) ........................................................... 36
Section 10.3: CASE in a clause ORDER BY ................................................................................................................. 36
Section 10.4: Shorthand CASE in SELECT .................................................................................................................. 36
Section 10.5: Using CASE in UPDATE ......................................................................................................................... 37
Section 10.6: CASE use for NULL values ordered last .............................................................................................. 37
Section 10.7: CASE in ORDER BY clause to sort records by lowest value of 2 columns ...................................... 38
Chapter 11: LIKE operator ....................................................................................................................................... 39
Section 11.1: Match open-ended pattern .................................................................................................................... 39
Section 11.2: Single character match ......................................................................................................................... 40
Section 11.3: ESCAPE statement in the LIKE-query ................................................................................................... 40
Section 11.4: Search for a range of characters ......................................................................................................... 41
Section 11.5: Match by range or set ........................................................................................................................... 41
Section 11.6: Wildcard characters .............................................................................................................................. 41
Chapter 12: IN clause ................................................................................................................................................. 43
Section 12.1: Simple IN clause ..................................................................................................................................... 43
Section 12.2: Using IN clause with a subquery ......................................................................................................... 43
Chapter 13: Filter results using WHERE and HAVING ................................................................................ 44
Section 13.1: Use BETWEEN to Filter Results............................................................................................................. 44
Section 13.2: Use HAVING with Aggregate Functions .............................................................................................. 45
Section 13.3: WHERE clause with NULL/NOT NULL values ..................................................................................... 45
Section 13.4: Equality ................................................................................................................................................... 46
Section 13.5: The WHERE clause only returns rows that match its criteria ........................................................... 46
Section 13.6: AND and OR ........................................................................................................................................... 46
Section 13.7: Use IN to return rows with a value contained in a list ....................................................................... 47
Section 13.8: Use LIKE to find matching strings and substrings ............................................................................. 47
Section 13.9: Where EXISTS ......................................................................................................................................... 48
Section 13.10: Use HAVING to check for multiple conditions in a group ................................................................ 48
Chapter 14: SKIP TAKE (Pagination) .................................................................................................................. 50
Section 14.1: Limiting amount of results .................................................................................................................... 50
Section 14.2: Skipping then taking some results (Pagination) ................................................................................ 50
Section 14.3: Skipping some rows from result .......................................................................................................... 51
Chapter 15: EXCEPT .................................................................................................................................................... 52
Section 15.1: Select dataset except where values are in this other dataset .......................................................... 52
Chapter 16: EXPLAIN and DESCRIBE .................................................................................................................. 53
Section 16.1: EXPLAIN Select query ............................................................................................................................ 53
Section 16.2: DESCRIBE tablename; ........................................................................................................................... 53
Chapter 17: EXISTS CLAUSE ................................................................................................................................... 54
Section 17.1: EXISTS CLAUSE ....................................................................................................................................... 54
Chapter 18: JOIN .......................................................................................................................................................... 55
Section 18.1: Self Join ................................................................................................................................................... 55
Section 18.2: Dierences between inner/outer joins ............................................................................................... 56
Section 18.3: JOIN Terminology: Inner, Outer, Semi, Anti.. ....................................................................................... 59
Section 18.4: Left Outer Join ....................................................................................................................................... 69
Section 18.5: Implicit Join ............................................................................................................................................ 70
Section 18.6: CROSS JOIN ........................................................................................................................................... 71
Section 18.7: CROSS APPLY & LATERAL JOIN .......................................................................................................... 72
Section 18.8: FULL JOIN .............................................................................................................................................. 73
Section 18.9: Recursive JOINs .................................................................................................................................... 74
Section 18.10: Basic explicit inner join ........................................................................................................................ 74
Section 18.11: Joining on a Subquery ......................................................................................................................... 75
Chapter 19: UPDATE ................................................................................................................................................... 76
Section 19.1: UPDATE with data from another table ................................................................................................ 76
Section 19.2: Modifying existing values ..................................................................................................................... 77
Section 19.3: Updating Specified Rows ...................................................................................................................... 77
Section 19.4: Updating All Rows ................................................................................................................................. 77
Section 19.5: Capturing Updated records ................................................................................................................. 77
Chapter 20: CREATE Database ............................................................................................................................ 78
Section 20.1: CREATE Database ................................................................................................................................. 78
Chapter 21: CREATE TABLE .................................................................................................................................... 79
Section 21.1: Create Table From Select ..................................................................................................................... 79
Section 21.2: Create a New Table .............................................................................................................................. 79
Section 21.3: CREATE TABLE With FOREIGN KEY ..................................................................................................... 79
Section 21.4: Duplicate a table ................................................................................................................................... 80
Section 21.5: Create a Temporary or In-Memory Table .......................................................................................... 80
Chapter 22: CREATE FUNCTION ........................................................................................................................... 82
Section 22.1: Create a new Function .......................................................................................................................... 82
Chapter 23: TRY/CATCH .......................................................................................................................................... 83
Section 23.1: Transaction In a TRY/CATCH .............................................................................................................. 83
Chapter 24: UNION / UNION ALL ....................................................................................................................... 84
Section 24.1: Basic UNION ALL query ........................................................................................................................ 84
Section 24.2: Simple explanation and Example ....................................................................................................... 85
Chapter 25: ALTER TABLE ...................................................................................................................................... 86
Section 25.1: Add Column(s) ....................................................................................................................................... 86
Section 25.2: Drop Column ......................................................................................................................................... 86
Section 25.3: Add Primary Key .................................................................................................................................. 86
Section 25.4: Alter Column ......................................................................................................................................... 86
Section 25.5: Drop Constraint .................................................................................................................................... 86
Chapter 26: INSERT .................................................................................................................................................... 87
Section 26.1: INSERT data from another table using SELECT ................................................................................. 87
Section 26.2: Insert New Row ..................................................................................................................................... 87
Section 26.3: Insert Only Specified Columns ............................................................................................................ 87
Section 26.4: Insert multiple rows at once ................................................................................................................ 87
Chapter 27: MERGE .................................................................................................................................................... 88
Section 27.1: MERGE to make Target match Source ............................................................................................... 88
Section 27.2: MySQL: counting users by name ........................................................................................................ 88
Section 27.3: PostgreSQL: counting users by name ................................................................................................ 88
Chapter 28: cross apply, outer apply .............................................................................................................. 90
Section 28.1: CROSS APPLY and OUTER APPLY basics ........................................................................................... 90
Chapter 29: DELETE ................................................................................................................................................... 92
Section 29.1: DELETE all rows ..................................................................................................................................... 92
Section 29.2: DELETE certain rows with WHERE ...................................................................................................... 92
Section 29.3: TRUNCATE clause ................................................................................................................................ 92
Section 29.4: DELETE certain rows based upon comparisons with other tables ................................................. 92
Chapter 30: TRUNCATE ............................................................................................................................................ 94
Section 30.1: Removing all rows from the Employee table ..................................................................................... 94
Chapter 31: DROP Table .......................................................................................................................................... 95
Section 31.1: Check for existence before dropping ................................................................................................... 95
Section 31.2: Simple drop ............................................................................................................................................ 95
Chapter 32: DROP or DELETE Database ......................................................................................................... 96
Section 32.1: DROP Database .................................................................................................................................... 96
Chapter 33: Cascading Delete .............................................................................................................................. 97
Section 33.1: ON DELETE CASCADE ........................................................................................................................... 97
Chapter 34: GRANT and REVOKE ....................................................................................................................... 99
Section 34.1: Grant/revoke privileges ........................................................................................................................ 99
Chapter 35: XML ........................................................................................................................................................ 100
Section 35.1: Query from XML Data Type ............................................................................................................... 100
Chapter 36: Primary Keys .................................................................................................................................... 101
Section 36.1: Creating a Primary Key ...................................................................................................................... 101
Section 36.2: Using Auto Increment ........................................................................................................................ 101
Chapter 37: Indexes ................................................................................................................................................. 102
Section 37.1: Sorted Index ......................................................................................................................................... 102
Section 37.2: Partial or Filtered Index ...................................................................................................................... 102
Section 37.3: Creating an Index ............................................................................................................................... 102
Section 37.4: Dropping an Index, or Disabling and Rebuilding it ......................................................................... 103
Section 37.5: Clustered, Unique, and Sorted Indexes ............................................................................................. 103
Section 37.6: Rebuild index ....................................................................................................................................... 104
Section 37.7: Inserting with a Unique Index ............................................................................................................ 104
Chapter 38: Row number ...................................................................................................................................... 105
Section 38.1: Delete All But Last Record (1 to Many Table) .................................................................................. 105
Section 38.2: Row numbers without partitions ....................................................................................................... 105
Section 38.3: Row numbers with partitions ............................................................................................................. 105
Chapter 39: SQL Group By vs Distinct ............................................................................................................ 106
Section 39.1: Dierence between GROUP BY and DISTINCT ................................................................................ 106
Chapter 40: Finding Duplicates on a Column Subset with Detail .................................................... 107
Section 40.1: Students with same name and date of birth ................................................................................... 107
Chapter 41: String Functions .............................................................................................................................. 108
Section 41.1: Concatenate ......................................................................................................................................... 108
Section 41.2: Length .................................................................................................................................................. 108
Section 41.3: Trim empty spaces ............................................................................................................................. 109
Section 41.4: Upper & lower case ............................................................................................................................. 109
Section 41.5: Split ....................................................................................................................................................... 109
Section 41.6: Replace ................................................................................................................................................. 110
Section 41.7: REGEXP ................................................................................................................................................. 110
Section 41.8: Substring .............................................................................................................................................. 110
Section 41.9: Stu ...................................................................................................................................................... 110
Section 41.10: LEFT - RIGHT ...................................................................................................................................... 110
Section 41.11: REVERSE .............................................................................................................................................. 111
Section 41.12: REPLICATE .......................................................................................................................................... 111
Section 41.13: Replace function in sql Select and Update query .......................................................................... 111
Section 41.14: INSTR ................................................................................................................................................... 112
Section 41.15: PARSENAME ....................................................................................................................................... 112
Chapter 42: Functions (Aggregate) ................................................................................................................ 114
Section 42.1: Conditional aggregation .................................................................................................................... 114
Section 42.2: List Concatenation ............................................................................................................................. 114
Section 42.3: SUM ...................................................................................................................................................... 116
Section 42.4: AVG() ................................................................................................................................................... 116
Section 42.5: Count ................................................................................................................................................... 116
Section 42.6: Min ........................................................................................................................................................ 117
Section 42.7: Max ....................................................................................................................................................... 118
Chapter 43: Functions (Scalar/Single Row) ............................................................................................... 119
Section 43.1: Date And Time ..................................................................................................................................... 119
Section 43.2: Character modifications .................................................................................................................... 120
Section 43.3: Configuration and Conversion Function .......................................................................................... 120
Section 43.4: Logical and Mathmetical Function ................................................................................................... 121
Chapter 44: Functions (Analytic) ..................................................................................................................... 123
Section 44.1: LAG and LEAD ..................................................................................................................................... 123
Section 44.2: PERCENTILE_DISC and PERCENTILE_CONT .................................................................................. 123
Section 44.3: FIRST_VALUE ...................................................................................................................................... 124
Section 44.4: LAST_VALUE ....................................................................................................................................... 125
Section 44.5: PERCENT_RANK and CUME_DIST ................................................................................................... 125
Chapter 45: Window Functions ......................................................................................................................... 127
Section 45.1: Setting up a flag if other rows have a common property .............................................................. 127
Section 45.2: Finding "out-of-sequence" records using the LAG() function ....................................................... 127
Section 45.3: Getting a running total ....................................................................................................................... 128
Section 45.4: Adding the total rows selected to every row .................................................................................. 128
Section 45.5: Getting the N most recent rows over multiple grouping ............................................................... 129
Chapter 46: Common Table Expressions ..................................................................................................... 130
Section 46.1: generating values ............................................................................................................................... 130
Section 46.2: recursively enumerating a subtree .................................................................................................. 130
Section 46.3: Temporary query ............................................................................................................................... 131
Section 46.4: recursively going up in a tree ........................................................................................................... 131
Section 46.5: Recursively generate dates, extended to include team rostering as example ........................... 132
Section 46.6: Oracle CONNECT BY functionality with recursive CTEs ................................................................. 132
Chapter 47: Views .................................................................................................................................................... 134
Section 47.1: Simple views ......................................................................................................................................... 134
Section 47.2: Complex views .................................................................................................................................... 134
Chapter 48: Materialized Views ........................................................................................................................ 135
Section 48.1: PostgreSQL example .......................................................................................................................... 135
Chapter 49: Comments ......................................................................................................................................... 136
Section 49.1: Single-line comments ......................................................................................................................... 136
Section 49.2: Multi-line comments ........................................................................................................................... 136
Chapter 50: Foreign Keys ..................................................................................................................................... 137
Section 50.1: Foreign Keys explained ...................................................................................................................... 137
Section 50.2: Creating a table with a foreign key .................................................................................................. 137
Chapter 51: Sequence ............................................................................................................................................. 139
Section 51.1: Create Sequence .................................................................................................................................. 139
Section 51.2: Using Sequences................................................................................................................................. 139
Chapter 52: Subqueries ......................................................................................................................................... 140
Section 52.1: Subquery in FROM clause .................................................................................................................. 140
Section 52.2: Subquery in SELECT clause ............................................................................................................... 140
Section 52.3: Subquery in WHERE clause ............................................................................................................... 140
Section 52.4: Correlated Subqueries ....................................................................................................................... 140
Section 52.5: Filter query results using query on dierent table ......................................................................... 140
Section 52.6: Subqueries in FROM clause ............................................................................................................... 141
Section 52.7: Subqueries in WHERE clause ............................................................................................................ 141
Chapter 53: Execution blocks ............................................................................................................................. 142
Section 53.1: Using BEGIN ... END ............................................................................................................................. 142
Chapter 54: Stored Procedures ........................................................................................................................ 143
Section 54.1: Create and call a stored procedure .................................................................................................. 143
Chapter 55: Triggers ............................................................................................................................................... 144
Section 55.1: CREATE TRIGGER ................................................................................................................................ 144
Section 55.2: Use Trigger to manage a "Recycle Bin" for deleted items ............................................................ 144
Chapter 56: Transactions ..................................................................................................................................... 145
Section 56.1: Simple Transaction ............................................................................................................................. 145
Section 56.2: Rollback Transaction ......................................................................................................................... 145
Chapter 57: Table Design ..................................................................................................................................... 146
Section 57.1: Properties of a well designed table ................................................................................................... 146
Chapter 58: Synonyms .......................................................................................................................................... 147
Section 58.1: Create Synonym ................................................................................................................................. 147
Chapter 59: Information Schema ..................................................................................................................... 148
Section 59.1: Basic Information Schema Search .................................................................................................... 148
Chapter 60: Order of Execution ........................................................................................................................ 149
Section 60.1: Logical Order of Query Processing in SQL ....................................................................................... 149
Chapter 61: Clean Code in SQL ........................................................................................................................... 150
Section 61.1: Formatting and Spelling of Keywords and Names .......................................................................... 150
Section 61.2: Indenting .............................................................................................................................................. 150
Section 61.3: SELECT * ............................................................................................................................................... 151
Section 61.4: Joins ..................................................................................................................................................... 152
Chapter 62: SQL Injection ..................................................................................................................................... 153
Section 62.1: SQL injection sample .......................................................................................................................... 153
Section 62.2: simple injection sample ..................................................................................................................... 154
Credits ............................................................................................................................................................................ 155
You may also like ...................................................................................................................................................... 159
Chapter 1: Getting started with SQL
VersionShort Name Release DateStandard
1986-01-01
1986 SQL-86 ANSI X3.135-1986,
X3.135-1989, ISO 9075:1987
ISO/IEC 9075:19891989-01-01
1989 SQL-89
1992 SQL-92 ISO/IEC 9075:1992 1992-01-01
1999 SQL:1999 ISO/IEC 9075:1999 1999-12-16
2003 SQL:2003 ISO/IEC 9075:2003 2003-12-15
2006 SQL:2006 ISO/IEC 9075:2006 2006-06-01
2008 SQL:2008 ISO/IEC 9075:2008 2008-07-15
2011 SQL:2011 ISO/IEC 9075:2011 2011-12-15
2016 SQL:2016 ISO/IEC 9075:2016 2016-12-01
1.Data Definition Language (DDL): to create and modify the structure of the database;
2.Data Manipulation Language (DML): to perform Read, Insert, Update and Delete operations on the data of
the database;
3.Data Control Language (DCL): to control the access of the data stored in the database.
The core DML operations are Create, Read, Update and Delete (CRUD for short) which are performed by the
statements INSERT, SELECT, UPDATE and DELETE.
There is also a (recently added) MERGE statement which can perform all 3 write operations (INSERT, UPDATE,
DELETE).
CRUD article on Wikipedia
Many SQL databases are implemented as client/server systems; the term "SQL server" describes such a database.
At the same time, Microsoft makes a database that is named "SQL Server". While that database speaks a dialect of
SQL, information specific to that database is not on topic in this tag but belongs into the SQL Server documentation.
Where appropriate, the examples should cover variations used by different SQL implementations, or identify the
SQL implementation of the example.
Section 2.1: Unquoted identifiers
Unquoted identifiers can use letters (a-z), digits (0-9), and underscore (_), and must start with a letter.
Depending on SQL implementation, and/or database settings, other characters may be allowed, some even as the
first character, e.g.
Unquoted identifiers are case-insensitive. How this is handled depends greatly on SQL implementation:
MySQL: Case-preserving, sensitivity depends on database setting and underlying file system.
Syntax:
Examples:
Syntax:
BINARY [ ( n_bytes ) ]
VARBINARY [ ( n_bytes | max ) ]
n_bytes can be any number from 1 to 8000 bytes. max indicates that the maximum storage space is 2^31-1.
Syntax:
CHAR [ ( n_chars ) ]
VARCHAR [ ( n_chars ) ]
Examples:
SELECT CAST('ABC' AS CHAR(10)) -- 'ABC ' (padded with spaces on the right)
SELECT CAST('ABC' AS VARCHAR(10)) -- 'ABC' (no padding due to variable character)
SELECT CAST('ABCDEFGHIJKLMNOPQRSTUVWXYZ' AS CHAR(10)) -- 'ABCDEFGHIJ' (truncated to 10 characters)
Syntax:
NCHAR [ ( n_chars ) ]
NVARCHAR [ ( n_chars | MAX ) ]
Use MAX for very long strings that may exceed 8000 characters.
Chapter 4: NULL
NULL in SQL, as well as programming in general, means literally "nothing". In SQL, it is easier to understand as "the
absence of any value".
It is important to distinguish it from seemingly empty values, such as the empty string '' or the number 0, neither
of which are actually NULL.
It is also important to be careful not to enclose NULL in quotes, like 'NULL', which is allowed in columns that accept
text, but is not NULL and can cause errors and incorrect data sets.
Note that because NULL is not equal to anything, not even to itself, using equality operators = NULL or<> NULL (or
!= NULL) will always yield the truth value of UNKNOWN which will be rejected by WHERE.
WHERE filters all rows that the condition is FALSE or UKNOWN and keeps only rows that the condition is
TRUE.
By default every column (except those in primary key constraint) is nullable unless we explicitly set NOT NULL
constraint.
Attempting to assign NULL to a non-nullable column will result in an error.
INSERT INTO MyTable (MyCol1, MyCol2) VALUES (1, NULL) ; -- works fine
UPDATE Employees
SET ManagerId = NULL
WHERE Id = 4
Departments
Id Name
1HR
2 Sales
3 Tech
Employees
IdFName LName PhoneNumberManagerIdDepartmentIdSalaryHireDate
1 James Smith 1234567890 NULL 1 1000 01-01-2002
2 John Johnson 2468101214 1 1 400 23-03-2005
3 Michael Williams 1357911131 1 2 600 12-05-2009
4 Johnathon 1212121212
Smith 2 1 500 24-07-2016
Customers
IdFName LNameEmail PhoneNumberPreferredContact
1 William Jones [email protected] 3347927472 PHONE
2 David Miller [email protected] 2137921892 EMAIL
3 Richard Davis [email protected] NULL EMAIL
);
Cars
IdCustomerIdEmployeeIdModel
Total Cost 230Status
11 2 Ford F-150
200 READY
21 2 Ford F-150 READY
MustangWAITING100
32 1
43 3 Toyota Prius WORKING1254
Authors and Books are known as base tables, since they contain column definition and data for the actual entities in
the relational model. BooksAuthors is known as the relationship table, since this table defines the relationship
between the Books and Authors table.
Authors
(view table)
IdName
Country
1J.D.
USA Salinger
2F. Scott. FitzgeraldUSA
3Jane Austen UK
4Scott HanselmanUSA
5Jason N. Gaylord USA
6Pranav Rastogi India
7Todd Miranda USA
8Christian Wenz USA
Books
(view table)
Id Title
1The Catcher in the Rye
2Nine Stories
3Franny and Zooey
4The Great Gatsby
5Tender id the Night
6Pride and Prejudice
7Professional ASP.NET 4.5 in C# and VB
BooksAuthors
(view table)
BookId AuthorId
1 1
2 1
3 1
4 2
5 2
Examples
SELECT
ba.AuthorId,
a.Name AuthorName,
ba.BookId,
b.Title BookTitle
FROM BooksAuthors ba
INNER JOIN Authors a ON a.id = ba.authorid
INNER JOIN Books b ON b.id = ba.bookid
;
Some Market data software applications like Bloomberg and Reuters require you to give their API either a 2 or 3
character country code along with the currency code. Hence this example table has both the 2-character ISO code
column and the 3 character ISO3 code columns.
Countries
(view table)
IdISOISO3ISONumericCountryNameCapital ContinentCodeCurrencyCode
1 AU AUS 36 Australia Canberra OC AUD
2 DE DEU 276 Germany Berlin EU EUR
2IN IND356 India New Delhi AS INR
3 LA LAO 418 Laos Vientiane AS LAK
4USUSA840 United States WashingtonNA USD
5 ZW ZWE 716 Zimbabwe Harare AF ZWL
Employees table:
1 James Smith 3
2 John Johnson 4
Departments table:
Id Name
1 Sales
2 Marketing
3 Finance
4 IT
Simple select statement
* is the wildcard character used to select all available columns in a table.
When used as a substitute for explicit column names, it returns all columns in all tables that a query is selecting
FROM. This effect applies to all tables the query accesses through its JOIN clauses.
Consider the following query:
Dot notation
To select all values from a specific table, the wildcard character can be applied to the table with dot notation.
SELECT
Employees.*,
Departments.Name
FROM
Employees
JOIN
This will return a data set with all fields on the Employee table, followed by just the Name field in the Departments
table:
It is generally advised that using * is avoided in production code where possible, as it can cause a number of
potential problems including:
1.Excess IO, network load, memory use, and so on, due to the database engine reading data that is not needed
and transmitting it to the front-end code. This is particularly a concern where there might be large fields such
as those used to store long notes or attached files.
2.Further excess IO load if the database needs to spool internal results to disk as part of the processing for a
query more complex than SELECT <columns> FROM <table>.
3.Extra processing (and/or even more IO) if some of the unneeded columns are:
computed columns in databases that support them
in the case of selecting from a view, columns from a table/view that the query optimiser could
otherwise optimise out
4.The potential for unexpected errors if columns are added to tables and views later that results ambiguous
column names. For example SELECT * FROM orders JOIN people ON people.id = orders.personid
BY displayname - if a column column called displayname is added to the orders table to allow users to give
their orders meaningful names for future reference then the column name will appear twice in the output so
the ORDER BY clause will be ambiguous which may cause errors ("ambiguous column name" in recent MS SQL
Server versions), and if not in this example your application code might start displaying the order name
where the person name is intended because the new column is the first of that name returned, and so on.
While best avoided in production code, using * is fine as a shorthand when performing manual queries against the
database for investigation or prototype work.
Sometimes design decisions in your application make it unavoidable (in such circumstances, prefer tablealias.*
over just * where possible).
When using EXISTS, such as SELECT A.col1, A.Col2 FROM A WHERE EXISTS (SELECT * FROM B where A.I
B.A_ID), we are not returning any data from B. Thus a join is unnecessary, and the engine knows no values from B
are to be returned, thus no performance hit for using *. Similarly COUNT(*) is fine as it also doesn't actually return
any of the columns, so only needs to read and process those that are used for filtering purposes.
Section 6.2: SELECT Using Column Aliases
Column aliases are used mainly to shorten code and make column names more readable.
Code becomes shorter as long table names and unnecessary identification of columns (e.g., there may be 2 IDs in the
table, but only one is used in the statement) can be avoided. Along with table aliases this allows you to use longer
descriptive names in your database structure while keeping queries upon that structure concise.
Furthermore they are sometimes required, for instance in views, in order to name computed outputs.
Aliases can be created in all versions of SQL using double quotes (" ).
SELECT
FName AS "First Name",
MName AS "Middle Name",
LName AS "Last Name"
FROM Employees
Different Versions of SQL
You can use single quotes ('), double quotes (" ) and square brackets ([]) to create an alias in Microsoft SQL Server.
SELECT
FName AS "First Name",
MName AS 'Middle Name',
LName AS [Last Name]
FROM Employees
This statement will return FName and LName columns with a given name (an alias). This is achieved using the AS
operator followed by the alias, or simply writing alias directly after the column name. This means that the following
query has the same outcome as the above.
SELECT
FName "First Name",
MName "Middle Name",
LName "Last Name"
FROM Employees
First NameMiddle NameLast Name
James John Smith
John James Johnson
Michael Marcus Williams
However, the explicit version (i.e., using the AS operator) is more readable.
If the alias has a single word that is not a reserved word, we can write it without single quotes, double quotes or
brackets:
SELECT
FName AS FirstName,
LName AS LastName
FROM Employees
FirstNameLastName
James Smith
John Johnson
Michael Williams
Some find using = instead of As easier to read, though many recommend against this format, mainly because it is
not standard so not widely supported by all databases. It may cause confusion with other uses of the = character.
All Versions of SQL
Also, if you need to use reserved words, you can use brackets or quotes to escape:
SELECT
FName as "SELECT",
MName as "FROM",
LName as "WHERE"
FROM Employees
Likewise, you can escape keywords in MSSQL with all different approaches:
SELECT
FName AS "SELECT",
MName AS 'FROM',
LName AS [WHERE]
FROM Employees
SELECT FROM WHERE
James John Smith
John James Johnson
Michael Marcus Williams
Also, a column alias may be used any of the final clauses of the same query, such as an ORDER BY:
SELECT
FName AS FirstName,
LName AS LastName
FROM
SELECT
FName AS SELECT,
LName AS FROM
FROM
Employees
ORDER BY
LastName DESC
This statement will return the columns PhoneNumber, Email, and PreferredContact from all rows of the Customers
table. Also the columns will be returned in the sequence in which they appear in the SELECT clause.
The result will be:
If multiple tables are joined together, you can select columns from specific tables by specifying the table name
before the column name: [table_name].[column_name]
SELECT
Customers.PhoneNumber,
Customers.Email,
Customers.PreferredContact,
Orders.Id AS OrderId
FROM
Customers
LEFT JOIN
Orders ON Orders.CustomerId = Customers.Id
*AS OrderId means that the Id field of Orders table will be returned as a column named OrderId. See selecting
with column alias for further information.
To avoid using long table names, you can use table aliases. This mitigates the pain of writing long table names for
each field that you select in the joins. If you are performing a self join (a join between two instances of the same
table), then you must use table aliases to distinguish your tables. We can write a table alias like Customers c or
Customers AS c. Here c works as an alias for Customers and we can select let's say Email like this: c.Email.
This standard is only supported in recent versions of some RDMSs. Vendor-specific non-standard syntax is provided
in other systems. Progress OpenEdge 11.x also supports the FETCH FIRST <n> ROWS ONLY syntax.
Additionally, OFFSET <m> ROWS before FETCH FIRST <n> ROWS ONLY allows skipping rows before fetching rows.
Results: 10 records.
Vendor Nuances:
It is important to note that the TOP in Microsoft SQL operates after the WHERE clause and will return the specified
number of results if they exist anywhere in the table, while ROWNUM works as part of the WHERE clause so if other
conditions do not exist in the specified number of rows at the beginning of the table, you will get zero results when
there could be others to be found.
Section 6.5: Selecting with Condition
The [condition] can be any SQL expression, specified using comparison or logical operators like >, <, =, <>, >=, <=,
LIKE, NOT, IN, BETWEEN etc.
The following statement returns all columns from the table 'Cars' where the status column is 'READY':
SELECT CASE WHEN Col1 < 50 THEN 'under' ELSE 'over' END threshold
FROM TableName
SELECT
CASE WHEN Col1 < 50 THEN 'under'
WHEN Col1 > 50 AND Col1 <100 THEN 'between'
ELSE 'over'
END threshold
FROM TableName
SELECT
CASE WHEN Col1 < 50 THEN 'under'
ELSE
CASE WHEN Col1 > 50 AND Col1 <100 THEN Col1
ELSE 'over' END
END threshold
SELECT
"ORDER",
ID
FROM ORDERS
Some DBMSes have proprietary ways of quoting names. For example, SQL Server uses square brackets for this
purpose:
SELECT
[Order],
ID
FROM ORDERS
SELECT
`Order`,
id
FROM orders
The Employees table is given the alias 'e' directly after the table name. This helps remove ambiguity in scenarios
where multiple tables have the same field name and you need to be specific as to which table you want to return
data from.
Note that once you define an alias, you can't use the canonical table name anymore. i.e.,
It is worth noting table aliases -- more formally 'range variables' -- were introduced into the SQL language to solve
the problem of duplicate columns caused by INNER JOIN. The 1992 SQL standard corrected this earlier design flaw
by introducing NATURAL JOIN (implemented in mySQL, PostgreSQL and Oracle but not yet in SQL Server), the result
of which never has duplicate column names. The above example is interesting in that the tables are joined on
Note that although an alias/range variable must be declared for the dervied table (otherwise SQL will throw an
error), it never makes sense to actually use it in the query.
Name
John
Bob
using OR keyword
SELECT name FROM persons WHERE gender = 'M' OR age < 20;
name
Sam
John
Bob
These keywords can be combined to allow for more complex criteria combinations:
SELECT name
FROM persons
WHERE (gender = 'M' AND age < 20)
OR (gender = 'F' AND age > 20);
name
Sam
Mary
MySQL
Oracle
DB2
If used on table that has record modifications going on might have unpredictable results.
The AVG() aggregate function will return the average of values selected.
SELECT AVG(Salary) FROM Employees
Aggregate functions can also be combined with the where clause.
SELECT AVG(Salary) FROM Employees where DepartmentId = 1
Aggregate functions can also be combined with group by clause.
If employee is categorized with multiple department and we want to find avg salary for every department then we
can use following query.
Minimum
The MIN() aggregate function will return the minimum of values selected.
SELECT MIN(Salary) FROM Employees
Maximum
The MAX() aggregate function will return the maximum of values selected.
SELECT MAX(Salary) FROM Employees
Count
The COUNT() aggregate function will return the count of values selected.
SELECT Count(*) FROM Employees
It can also be combined with where conditions to get the count of rows that satisfy specific conditions.
Sum
The SUM() aggregate function returns the sum of the values selected for all rows.
SELECT SUM(Salary) FROM Employees
The important thing is to select only columns specified in the GROUP BY clause or used with aggregate functions.
There WHERE clause can also be used with GROUP BY, but WHERE filters out records before any grouping is done:
If you need to filter the results after the grouping has been done, e.g, to see only departments whose average
income is larger than 1000, you need to use the HAVING clause:
This statement will return all the columns from the table Employees.
Or
FName. This
This example will sort the results first by LName and then, for records that have the same LName, sort by
will give you a result similar to what you would find in a telephone book.
In order to save retyping the column name in the ORDER BY clause, it is possible to use instead the column's
number. Note that column numbers start from 1.
SELECT Id, FName, LName, PhoneNumber FROM Employees ORDER BY CASE WHEN LName='Jones' THEN 0 ELSE 1
END ASC
This will sort your results to have all records with the LName of "Jones" at the top.
Selection with nulls take a different syntax. Don't use =, use IS NULL or IS NOT NULL instead.
This query will return all DISTINCT (unique, different) values from ContinentCode column from Countries table
ContinentCode
OC
EU
SQLFiddle Demo
SELECT
table1.column1,
table1.column2,
table2.column1
FROM
table1,
table2
These statements return the selected columns from multiple tables in one query.
There is no specific relationship between the columns returned from each table.
is saying:
+-----+-------------+
|EmpID|MonthlySalary|
+-----+-------------+ |1 |200
| +-----+-------------+ |2
|300 | +-----+-------------+
Result:
+-+---+
|1|200|
+-+---+
|2|300|
+-+---+
Sum wouldn't appear to do anything because the sum of one number is that number. On the other hand if it looked
like this:
+-----+-------------+
|EmpID|MonthlySalary|
+-----+-------------+ |1 |200
| +-----+-------------+ |1
|300 | +-----+-------------+
|2 |300 | +-----+-------------
+
Result:
Then it would because there are two EmpID 1's to sum together.
Return all authors that wrote more than one book (live example).
SELECT
a.Id,
a.Name,
COUNT(*) BooksWritten
FROM BooksAuthors ba
INNER JOIN Authors a ON a.id = ba.authorid
GROUP BY
a.Id,
a.Name
HAVING COUNT(*) > 1 -- equals to HAVING BooksWritten > 1
;
Return all books that have more than three authors (live example).
SELECT
b.Id,
b.Title,
COUNT(*) NumberOfAuthors
FROM BooksAuthors ba
INNER JOIN Books b ON b.id = ba.bookid
GROUP BY
b.Id,
b.Title
HAVING COUNT(*) > 3 -- equals to HAVING NumberOfAuthors > 3
;
Name GreatHouseAllegience
Arya
Stark
Lannister
Cercei
Myrcella Lannister
Yara Greyjoy
Catelyn Stark
Without GROUP BY, COUNT will simply return a total number of rows:
returns...
Number_of_Westerosians
6
But by adding GROUP BY, we can COUNT the users for each value in a given column, to return the number of
people in a given Great House, say:
returns...
House Number_of_Westerosians
Stark 3
Greyjoy 1
Lannister 2
It's common to combine GROUP BY with ORDER BY to sort results by largest or smallest category:
returns...
House Number_of_Westerosians
Stark 3
Lannister 2
Greyjoy 1
The SQL standard provides two additional aggregate operators. These use the polymorphic value "ALL" to denote
the set of all values that an attribute can take. The two operators are:
with data cube that it provides all possible combinations than the argument attributes of the clause.
with roll up that it provides the aggregates obtained by considering the attributes in order from left to
right compared how they are listed in the argument of the clause.
Examples
With cube
select Food,Brand,Total_amount
from Table
group by Food,Brand,Total_amount with cube
Food Brand Total_amount
Pasta Brand1 100
Pasta Brand2 250
Pasta ALL 350
Pizza Brand2 300
Pizza ALL 300
ALL Brand1 100
ALL Brand2 550
ALL ALL 650
With roll up
select Food,Brand,Total_amount
from Table
group by Food,Brand,Total_amount with roll up
Food Brand Total_amount
Pasta Brand1 100
Pasta Brand2 250
Pizza Brand2 300
Pasta ALL 350
Pizza ALL 300
ALL ALL 650
Con: This will generally reduce readability of the query (It's instantly clear what 'ORDER BY Reputation' means, while
'ORDER BY 14' requires some counting, probably with a finger on the screen.)
This query sorts result by the info in relative column position 3 from select statement instead of column name
Reputation.
SELECT DisplayName, JoinDate, Reputation FROM Users ORDER BY 3
DisplayName JoinDate Reputation
Community 2008-09-15 1
Jarrod Dixon 2008-10-0311739
Geoff Dalgas 2008-10-0312567
Joel Spolsky 2008-09-1625784
Jeff Atwood 2008-09-1637628
Section 8.2: Use ORDER BY with TOP to return the top x rows
based on a column's value
In this example, we can use GROUP BY not only determined the sort of the rows returned, but also what rows are
returned, since we're using TOP to limit the result set.
Let's say we want to return the top 5 highest reputation users from an unnamed popular Q&A site.
Without ORDER BY
This query returns the Top 5 rows ordered by the default, which in this case is "Id", the first column in the table
(even though it's not a column shown in the results).
returns...
DisplayName Reputation
Community 1
Geoff Dalgas 12567
Jarrod Dixon 11739
Jeff Atwood 37628
Joel Spolsky 25784
With ORDER BY
returns...
DisplayName Reputation
JonSkeet 865023
Darin Dimitrov661741
BalusC 650237
Hans Passant 625870
Marc Gravell 601636
Remarks
Some versions of SQL (such as MySQL) use a LIMIT clause at the end of a SELECT, instead of TOP at the beginning,
for example:
Name Department
Hasan IT
Yusuf HR
Hillary HR
Joe IT
Merry HR
Ken Accountant
SELECT *
FROM Employee
ORDER BY CASE Department
WHEN 'HR' THEN 1
WHEN 'Accountant' THEN 2
ELSE 3
END;
Name Department
Yusuf HR
Hillary HR
Merry HR
Ken Accountant
Hasan IT
Joe IT
And can use relative order of the columns in the select statement .Consider the same example as above and
instead of using alias use the relative order like for display name it is 1 , for Jd it is 2 and so on
NameAge City
Bob 10 Paris
Mat 20 Berlin
Mary 24 Prague
select Name from table where Age>10 AND City='Prague'
Gives
Name
Mary
Gives
Name
Bob
Mary
CASE can be used in conjunction with SUM to return a count of only those items matching a pre-defined condition.
(This is similar to COUNTIF in Excel.)
The trick is to return binary results indicating matches, so the "1"s returned for matching entries can be summed
for a count of the total number of matches.
Given this table ItemSales, let's say you want to learn the total number of items that have been categorized as
"Expensive":
IdItemIdPrice PriceRating
Query
SELECT
COUNT(Id) AS ItemsCount,
SUM ( CASE
WHEN PriceRating = 'Expensive' THEN 1
ELSE 0
END
) AS ExpensiveItemsCount
FROM ItemSales
Results:
ItemsCountExpensiveItemsCount
5 3
Alternative:
SELECT
COUNT(Id) as ItemsCount,
SUM (
CASE PriceRating
WHEN 'Expensive' THEN 1
ELSE 0
END
) AS ExpensiveItemsCount
FROM ItemSales
(This differs from the simple case, which can only check for equivalency with an input.)
A word of caution. It's important to realize that when using the short variant the entire statement is evaluated at
each WHEN. Therefore the following statement:
SELECT
CASE ABS(CHECKSUM(NEWID())) % 4
WHEN 0 THEN 'Dr'
WHEN 1 THEN 'Master'
WHEN 2 THEN 'Mr'
WHEN 3 THEN 'Mrs'
END
may produce a NULL result. That is because at each WHEN NEWID()is being called again with a new result. Equivalent
to:
SELECT
CASE
WHEN ABS(CHECKSUM(NEWID())) % 4 = 0 THEN 'Dr'
WHEN ABS(CHECKSUM(NEWID())) % 4 = 1 THEN 'Master'
WHEN ABS(CHECKSUM(NEWID())) % 4 = 2 THEN 'Mr'
WHEN ABS(CHECKSUM(NEWID())) % 4 = 3 THEN 'Mrs'
END
Therefore it can miss all the WHEN cases and result as NULL.
UPDATE ItemPrice
SET Price = Price *
CASE ItemId
WHEN 1 THEN 1.05
WHEN 2 THEN 1.10
WHEN 3 THEN 1.15
ELSE 1.00
END
SELECT ID
,REGION
,CITY
,DEPARTMENT
,EMPLOYEES_NUMBER
FROM DEPT
ORDER BY
CASE WHEN REGION IS NULL THEN 1
ELSE 0
END,
REGION
Id Date1 Date2
1 2017-01-01 2017-01-31
2 2017-01-31 2017-01-03
3 2017-01-31 2017-01-02
4 2017-01-06 2017-01-31
5 2017-01-31 2017-01-05
6 2017-01-04 2017-01-31
Query
So we have sorted records from 2017-01-01 to 2017-01-06 ascending and no care on which one column Date1 or
Date2 are those values.
Following statement matches for all records having FName containing string 'on' from Employees Table.
Following statement matches all records having PhoneNumber starting with string '246' from Employees.
Following statement matches all records having PhoneNumber ending with string '11' from Employees.
Find all employees whose Fname start with 'j' and end with 'n' and has exactly 3 characters in Fname.
_ (underscore) character can also be used more than once as a wild card to match patterns.
For example, this pattern would match "jon", "jan", "jen", etc.
These names will not be shown "jn","john","jordan", "justin", "jason", "julian", "jillian", "joann" because in our query
one underscore is used and it can skip exactly one character, so result must be of 3 character Fname.
For example, this pattern would match "LaSt", "LoSt", "HaLt", etc.
SELECT *
FROM T_Whatever
WHERE SomeField LIKE CONCAT('%', @in_SearchText, '%')
However, (apart from the fact that you shouldn't necessarely use LIKE when you can use fulltext-search) this
creates a problem when somebody inputs text like "50%" or "a_b".
So (instead of switching to fulltext-search), you can solve that problem using the LIKE-escape statement:
SELECT *
FROM T_Whatever
WHERE SomeField LIKE CONCAT('%', @in_SearchText, '%') ESCAPE '\'
That means \ will now be treated as ESCAPE character. This means, you can now just prepend \ to every character
in the string you search, and the results will start to be correct, even when the user enters a special character like %
or _.
e.g.
Note: The above algorithm is for demonstration purposes only. It will not work in cases where 1 grapheme consists
out of several characters (utf-8). e.g. string stringToSearch = "Les Mise\u0301rables"; You'll need to do this
The range or set can also be negated by appending the ^ caret before the range or set:
This range pattern would not match "gary" but will match "mary":
This set pattern would not match "mary" but will match"gary":
Eg://selects all customers with a City starting with any character, followed by "erlin"
SELECT * FROM Customers
Eg://selects all customers with a City starting with "a", "d", or "l"
SELECT * FROM Customers
WHERE City LIKE '[adl]%';
//selects all customers with a City starting with "a", "d", or "l"
SELECT * FROM Customers
WHERE City LIKE '[a-c]%';
Eg://selects all customers with a City starting with a character that is not "a", "p", or "l"
SELECT * FROM Customers
WHERE City LIKE '[^apl]%';
or
select *
from products
where id in (1,8,3)
select *
from products
where id = 1
or id = 8
or id = 3
The above will give you all the customers that have orders in the system.
This query will return all ItemSales records that have a quantity that is greater or equal to 10 and less than or equal
to 17. The results will look like:
Id SaleDate ItemIdQuantityPrice
This query will return all ItemSales records with a SaleDate that is greater than or equal to July 11, 2013 and less
than or equal to May 24, 2013.
Id SaleDate ItemIdQuantityPrice
3 2013-07-11 100 20 34.5
4 2013-07-23 100 15 34.5
5 2013-07-24 145 10 34.5
When comparing datetime values instead of dates, you may need to convert the datetime values into a
date values, or add or subtract 24 hours to get the correct results.
This query will return all customers whose name alphabetically falls between the letters 'D' and 'L'. In this case,
Customer #1 and #3 will be returned. Customer #2, whose name begins with a 'M' will not be included.
Id FName LName
An aggregate function is a function where the values of multiple rows are grouped together as input on
certain criteria to form a single value of more significant meaning or measurement (Wikipedia).
This example uses the Car Table from the Example Databases.
This query will return the CustomerId and Number of Cars count of any customer who has more than one car. In
this case, the only customer who has more than one car is Customer #1.
The results will look like:
CustomerIdNumber of Cars
1 2
This statement will return all Employee records where the value of the ManagerId column is NULL.
SELECT *
FROM Employees
WHERE ManagerId IS NOT NULL
This statement will return all Employee records where the value of the ManagerId is not NULL.
This statement will return all the rows from the table Employees.
Using a WHERE at the end of your SELECT statement allows you to limit the returned rows to a condition. In this case,
where there is an exact match using the = sign:
Section 13.5: The WHERE clause only returns rows that match
its criteria
Steam has a games under $10 section of their store page. Somewhere deep in the heart of their systems, there's
probably a query that looks something like:
SELECT *
FROM Items
WHERE Price < 10
AND
Will return:
OR
Will return:
SELECT *
FROM Cars
WHERE TotalCost IN (100, 200, 300)
This query will return Car #2 which costs 200 and Car #3 which costs 100. Note that this is equivalent to using
multiple clauses with OR, e.g.:
SELECT *
FROM Cars
WHERE TotalCost = 100 OR TotalCost = 200 OR TotalCost = 300
SELECT *
FROM Employees
WHERE FName LIKE 'John'
This query will only return Employee #1 whose first name matches 'John' exactly.
SELECT *
FROM Employees
WHERE FName like 'John%'
John% - will return any Employee whose name begins with 'John', followed by any amount of characters
%John - will return any Employee whose name ends with 'John', proceeded by any amount of characters
%John% - will return any Employee whose name contains 'John' anywhere within the value
In this case, the query will return Employee #2 whose name is 'John' as well as Employee #4 whose name is
'Johnathon'.
Section 13.9: Where EXISTS
To check for customers who have ordered both - ProductID 2 and 3, HAVING can be used
select customerId
from orders
where productID in (2,3)
group by customerId
having count(distinct productID) = 2
Return value:
customerId
1
The query selects only records with the productIDs in questions and with the HAVING clause checks for groups
select customerId
from orders
group by customerId
having sum(case when productID = 2 then 1 else 0 end) > 0
and sum(case when productID = 3 then 1 else 0 end) > 0
This query selects only groups having at least one record with productID 2 and at least one with productID 3.
Oracle:
SELECT Id,
Col1
FROM (SELECT Id,
Col1,
row_number() over (order by Id) RowNumber
FROM TableName)
WHERE RowNumber <= 20
SQL Server:
SELECT TOP 20 *
FROM dbo.[Sale]
MySQL:
SELECT Id,
Col1
FROM (SELECT Id,
Col1,
row_number() over (order by Id) RowNumber
FROM TableName)
WHERE RowNumber BETWEEN 21 AND 40
PostgreSQL; SQLite:
MySQL:
Oracle:
SELECT Id,
Col1
FROM (SELECT Id,
Col1,
row_number() over (order by Id) RowNumber
FROM TableName)
WHERE RowNumber > 20
PostgreSQL:
SQLite:
Example result:
on type you see if an index was used. In the column possible_keys you see if the execution plan can choose from
different indexes of if none exists. key tells you the acutal used index. key_len shows you the size in bytes for one
index item. The lower this value is the more index items fit into the same memory size an they can be faster
processed. rows shows you the expected number of rows the query needs to scan, the lower the better.
DESCRIBE tablename;
Exmple Result:
Here you see the column names, followed by the columns type. It shows if null is allowed in the column and if the
column uses an Index. the default value is also displayed and if the table contains any special behavior like an
auto_increment.
Id FirstName LastName
1 Ozgur Ozturk
2 Youssef Medi
3 Henry Tai
Order Table
IdCustomerIdAmount
12 123.50
23 14.80
Get all customers with a least one order
SELECT * FROM Customer WHERE EXISTS (
SELECT * FROM Order WHERE Order.CustomerId=Customer.Id
)
Result
Id FirstName LastName
2 Youssef Medi
3 Henry Tai
Get all customers with no order
SELECT * FROM Customer WHERE NOT EXISTS (
SELECT * FROM Order WHERE Order.CustomerId = Customer.Id
)
Result
Id FirstName LastName
1 Ozgur Ozturk
Purpose
EXISTS, IN and JOIN could sometime be used for the same result, however, they are not equals :
SELECT
e.FName AS "Employee",
m.FName AS "Manager"
FROM
Employees e
JOIN
Employees m
ON e.ManagerId = m.Id
Employee Manager
John James
Michael James
Johnathon John
The first action is to create a Cartesian product of all records in the tables used in the FROM clause. In this case it's
the Employees table twice, so the intermediate table will look like this (I've removed any fields not used in this
example):
The next action is to only keep the records that meet the JOIN criteria, so any records where the aliased e table
ManagerId equals the aliased m table Id:
e.Ide.FName e.ManagerIdm.Idm.FNamem.ManagerId
2 John 1 1 James NULL
3 Michael 1 1 James NULL
4 Johnathon 2 2 John 1
Then, each expression used within the SELECT clause is evaluated to return this table:
e.FName m.FName
John James
Michael James
Johnathon John
Finally, column names e.FName and m.FName are replaced by their alias column names, assigned with the AS
operator:
Employee Manager
John James
Michael James
Johnathon John
Note that (1,2) are unique to A, (3,4) are common, and (5,6) are unique to B.
Inner Join
An inner join using either of the equivalent queries gives the intersection of the two tables, i.e. the two rows they
have in common:
a|b-
-+-- 3
| 3 4 |
4
A left outer join will give all rows in A, plus any common rows in B:
a | b --+--
--- 1 | null
2 | null
3 | 4 3
| 4
Similarly, a right outer join will give all rows in B, plus any common rows in A:
a |b
-----+----
3 |3
4 |4
null | 5
null | 6
A full outer join will give you the union of A and B, i.e., all the rows in A and all the rows in B. If something in A
doesn't have a corresponding datum in B, then the B portion is null, and vice versa.
a |b
-----+-----
CREATE TABLE A (
X varchar(255) PRIMARY KEY
);
CREATE TABLE B (
Y varchar(255) PRIMARY KEY
);
Inner Join
Sometimes abbreviated to "left join". Combines left and right rows that match, and includes non-matching left
rows.
X Y
----- -----
Amy NULL
John NULL
Lisa Lisa
Marco Marco
Phil Phil
Sometimes abbreviated to "right join". Combines left and right rows that match, and includes non-matching right
rows.
X Y
----- -------
Lisa Lisa
Marco Marco
Phil Phil
NULL Tim
NULL Vincent
Sometimes abbreviated to "full join". Union of left and right outer join.
X Y
----- -------
Amy NULL
John NULL
Lisa Lisa
Marco Marco
Phil Phil
NULL Tim
NULL Vincent
X
-----
Lisa
Marco
Phil
Y
-----
Lisa
Marco
Phil
X
----
Amy
John
WARNING: Be careful if you happen to be using NOT IN on a NULL-able column! More details here.
Y
-------
Tim
Vincent
As you can see, there is no dedicated NOT IN syntax for left vs. right anti semi join - we achieve the effect simply by
switching the table positions within SQL text.
Cross Join
X Y
----- -------
Amy Lisa
John Lisa
Lisa Lisa
Marco Lisa
Phil Lisa
Amy Marco
John Marco
Lisa Marco
Marco Marco
Phil Marco
Amy Phil
John Phil
Lisa Phil
Marco Phil
Phil Phil
Amy Tim
Cross join is equivalent to an inner join with join condition which always matches, so the following query would
have returned the same result:
Self-Join
This simply denotes a table joining with itself. A self-join can be any of the join types discussed above. For example,
this is a an inner self-join:
X X
---- -----
Amy John
Amy Lisa
Amy Marco
John Marco
Lisa Marco
Phil Marco
Amy Phil
Departments.NameEmployees.FName
HR James
HR John
HR Johnathon
Sales Michael
Tech NULL
IdFName LNamePhoneNumberManagerIdDepartmentIdSalaryHireDate
1 James Smith 1234567890 NULL 1 1000 01-01-2002
2 John Johnson 2468101214 1 1 400 23-03-2005
3 Michael Williams 1357911131 1 2 600 12-05-2009
4 Johnathon 1212121212
Smith 2 1 500 24-07-2016
and
Id Name
1HR
2 Sales
3 Tech
First a Cartesian product is created from the two tables giving an intermediate table.
The records that meet the join criteria (Departments.Id = Employees.DepartmentId) are highlighted in bold; these are
passed to the next stage of the query.
As this is a LEFT OUTER JOIN all records are returned from the LEFT side of the join (Departments), while any
records on the RIGHT side are given a NULL marker if they do not match the join criteria. In the table below this will
return Tech with NULL
Finally each expression used within the SELECT clause is evaluated to return our final table:
Departments.Name Employees.FName
HR James
HR John
Sales Richard
Tech NULL
It is possible to get accidental cross joins which then return incorrect results, especially if you have a lot of
joins in the query.
If you intended a cross join, then it is not clear from the syntax (write out CROSS JOIN instead), and someone
is likely to change it during maintenance.
The following example will select employee's first names and the name of the departments they work for:
e.FName d.Name
James HR
John HR
Richard Sales
Which returns:
d.Name e.FName
HR James
HR John
HR Michael
HR Johnathon
Sales James
Sales John
Sales Michael
Sales Johnathon
Tech James
Tech John
Tech Michael
Tech Johnathon
It is recommended to write an explicit CROSS JOIN if you want to do a cartesian join, to highlight that this is what
you want.
This makes it possible to, for example, only join the first matching entry in another table.
The difference between a normal and a lateral join lies in the fact that you can use a column that you previously
joined in the subquery that you "CROSS APPLY".
Syntax:
PostgreSQL 9.3+
SQL-Server:
/*
AND
(
(__in_DateFrom <= T_MAP_Contacts_Ref_OrganisationalUnit.MAP_KTKOE_DateTo)
AND
(__in_DateTo >= T_MAP_Contacts_Ref_OrganisationalUnit.MAP_KTKOE_DateFrom)
)
* /
ORDER BY MAP_CTCOU_DateFrom
LIMIT 1
/*
AND
(
(@in_DateFrom <= T_MAP_Contacts_Ref_OrganisationalUnit.MAP_KTKOE_DateTo)
AND
(@in_DateTo >= T_MAP_Contacts_Ref_OrganisationalUnit.MAP_KTKOE_DateFrom)
)
* /
ORDER BY MAP_CTCOU_DateFrom
) AS FirstOE
If there are rows in the left table that do not have matches in the right table, or if there are rows in right table that
do not have matches in the left table, then those rows will be listed, too.
Example 1 :
Example 2:
SELECT
COALESCE(T_Budget.Year, tYear.Year) AS RPT_BudgetInYear
,COALESCE(T_Budget.Value, 0.0) AS RPT_Value
FROM T_Budget
Note that if you're using soft-deletes, you'll have to check the soft-delete status again in the WHERE-clause (because
FULL JOIN behaves kind-of like a UNION);
It's easy to overlook this little fact, since you put AP_SoftDeleteStatus = 1 in the join clause.
Also, if you are doing a FULL JOIN, you'll usually have to allow NULL in the WHERE-clause; forgetting to allow NULL
on a value will have the same effects as an INNER join, which is something you don't want if you're doing a FULL
JOIN.
Example:
SELECT
T_AccountPlan.AP_UID
,T_AccountPlan.AP_Code
,T_AccountPlan.AP_Lang_EN
,T_BudgetPositions.BUP_Budget
,T_BudgetPositions.BUP_UID
,T_BudgetPositions.BUP_Jahr
FROM T_BudgetPositions
WHERE (1=1)
AND (T_BudgetPositions.BUP_SoftDeleteStatus = 1 OR T_BudgetPositions.BUP_SoftDeleteStatus IS NULL)
AND (T_AccountPlan.AP_SoftDeleteStatus = 1 OR T_AccountPlan.AP_SoftDeleteStatus IS NULL)
UNION ALL
SELECT People.Name
FROM People
JOIN MyDescendants ON People.Name = MyDescendants.Parent
) SELECT * FROM
MyDescendants;
The following example will select employees' first names (FName) from the Employees table and the name of the
department they work for (Name) from the Departments table:
Employees.FName Departments.Name
James HR
John HR
Richard Sales
Standard SQL
MERGE INTO
Employees e
USING
Customers c
ON
e.FName = c.Fname
AND e.LName = c.LName
AND e.PhoneNumber IS NULL
WHEN MATCHED THEN
UPDATE
SET PhoneNumber = c.PhoneNumber
SQL Server
UPDATE
Employees
SET
PhoneNumber = c.PhoneNumber
FROM
Employees e
INNER JOIN Customers c
ON e.FName = c.FName
AND e.LName = c.LName
WHERE
PhoneNumber IS NULL
UPDATE Cars
SET TotalCost = TotalCost + 100
WHERE Id = 3 or Id = 4
Update operations can include current values in the updated row. In this simple example the TotalCost is
incremented by 100 for two rows:
A column's new value may be derived from its previous value or from any other column's value in the same table or
a joined table.
UPDATE
Cars
SET
Status = 'READY'
WHERE
Id = 4
WHERE clause contains a logical expression which is evaluated for each row. If a row fulfills the criteria, its value is
updated. Otherwise, a row remains unchanged.
UPDATE Cars
SET Status = 'READY'
This statement will set the 'status' column of all rows of the 'Cars' table to "READY" because it does not have a
clause to filter the set of rows.
This would create an empty database named myDatabase where you can create tables. WHERE
You can use any of the other features of a SELECT statement to modify the data before passing it to the new table.
The columns of the new table are automatically created according to the selected rows.
CREATE TABLE creates a new table in the database, followed by the table name,Employees
This is then followed by the list of column names and their properties, such as the ID
primary key states that all values in this column will have unique values
not null states that this column cannot have null values
The column CityID of table Employees will reference to the column CityID of table Cities. Below you could find
the syntax to make this.
Important: You couldn't make a reference to a table that not exists in the database. Be source to make first the
table Cities and second the table Employees. If you do it vise versa, it will throw an error.
Section 21.4: Duplicate a table
RETURN @output
END
This example creates a function named FirstWord, that accepts a varchar parameter and returns another varchar
value.
BEGIN TRANSACTION
BEGIN TRY
INSERT INTO dbo.Sale(Price, SaleDate, Quantity)
VALUES (5.2, GETDATE(), 1)
INSERT INTO dbo.Sale(Price, SaleDate, Quantity)
VALUES (5.2, 'not a date', 1)
COMMIT TRANSACTION
END TRY
BEGIN CATCH
THROW
ROLLBACK TRANSACTION
END CATCH
BEGIN TRANSACTION
BEGIN TRY
INSERT INTO dbo.Sale(Price, SaleDate, Quantity)
VALUES (5.2, GETDATE(), 1)
INSERT INTO dbo.Sale(Price, SaleDate, Quantity)
VALUES (5.2, GETDATE(), 1)
COMMIT TRANSACTION
END TRY
BEGIN CATCH
THROW
ROLLBACK TRANSACTION
END CATCH
Let's say we want to extract the names of all the managers from our departments.
Using a UNION we can get all the employees from both HR and Finance departments, which hold the position of a
manager
SELECT
FirstName, LastName
FROM
HR_EMPLOYEES
WHERE
Position = 'manager'
UNION ALL
SELECT
FirstName, LastName
FROM
FINANCE_EMPLOYEES
WHERE
Position = 'manager'
The UNION statement removes duplicate rows from the query results. Since it is possible to have people having the
same Name and position in both departments we are using UNION ALL, in order not to remove duplicates.
If you want to use an alias for each output column, you can just put them in the first select statement, as follows:
SELECT
FirstName as 'First Name', LastName as 'Last Name'
FROM
HR_EMPLOYEES
WHERE
Position = 'manager'
UNION ALL
SELECT
FirstName, LastName
FROM
UNION joins 2 result sets while removing duplicates from the result set
UNION ALL joins 2 result sets without attempting to remove duplicates
One mistake many people make is to use a UNION when they do not need to have the duplicates removed.
The additional performance cost against large results sets can be very significant.
Suppose you need to filter a table against 2 different attributes, and you have created separate non-clustered
indexes for each column. A UNION enables you to leverage both indexes while still preventing duplicates.
This simplifies your performance tuning since only simple indexes are needed to perform these queries optimally.
You may even be able to get by with quite a bit fewer non-clustered indexes improving overall write performance
against the source table as well.
When you might need UNION ALL
Suppose you still need to filter a table against 2 attributes, but you do not need to filter duplicate records (either
because it doesn't matter or your data wouldn't produce any duplicates during the union due to your data model
design).
This is especially useful when creating Views that join data that is designed to be physically partitioned across
multiple tables (maybe for performance reasons, but still wants to roll-up records). Since the data is already split,
having the database engine remove duplicates adds no value and just adds additional processing time to the
queries.
The above statement would add columns named StartingDate which cannot be NULL with default value as current
date and DateOfBirth which can be NULL in Employees table.
This will not only delete information from that column, but will drop the column salary from table employees(the
column will no more exist).
This will add a Primary key to the table Employees on the field ID. Including more than one column name in the
parentheses along with ID will create a Composite Primary Key. When adding more than one column, the column
names must be separated by commas.
This query will alter the column datatype of StartingDate and change it from simple date to datetime and set
default to current date.
This Drops a constraint called DefaultSalary from the employees table definition.
Note: Ensure that constraints of the column are dropped before dropping a column.
This example will insert all Employees into the Customers table. Since the two tables have different fields and you
don't want to move all the fields over, you need to set which fields to insert into and which fields to select. The
correlating field names don't need to be called the same thing, but then need to be the same data type. This
example is assuming that the Id field has an Identity Specification set and will auto increment.
If you have two tables that have exactly the same field names and just want to move all the records over you can
use:
This statement will insert a new row into the Customers table. Note that a value was not specified for the Id column,
as it will be added automatically. However, all other column values must be specified.
This statement will insert a new row into the Customers table. Data will only be inserted into the columns specified -
note that no value was provided for the PhoneNumber column. Note, however, that all columns marked as not null
must be included.
For inserting large quantities of data (bulk insert) at the same time, DBMS-specific features and recommendations
exist.
MySQL - LOAD DATA INFILE
Note: The AND NOT EXISTS portion prevents updating records that haven't changed. Using the INTERSECT construct
allows nullable columns to be compared without special handling.
Now, we just discovered a new user named Joe and would like to take him into account. To achieve that, we need to
determine whether there is an existing row with his name, and if so, update it to increment count; on the other
hand, if there is no existing row, we should create it.
MySQL uses the following syntax : insert … on duplicate key update …. In this case:
Now, we just discovered a new user named Joe and would like to take him into account. To achieve that, we need to
determine whether there is an existing row with his name, and if so, update it to increment count; on the other
hand, if there is no existing row, we should create it.
PostgreSQL uses the following syntax : insert … on conflict … do update …. In this case:
create a Department table to hold information about departments. Then create an Employee table which hold
information about the employees. Please note, each employee belongs to a department, hence the Employee table
has referential integrity with the Department table.
First query selects data from Department table and uses CROSS APPLY to evaluate the Employee table for each
record of the Department table. Second query simply joins the Department table with the Employee table and all
the matching records are produced.
SELECT *
FROM Department D
CROSS APPLY (
SELECT *
FROM Employee E
WHERE E.DepartmentID = D.DepartmentID
) A GO SELECT * FROM Department D
INNER JOIN Employee E ON
D.DepartmentID = E.DepartmentID
If you look at the results they produced, it is the exact same result-set; How does it differ from a JOIN and how does
it help in writing more efficient queries.
The first query in Script #2 selects data from Department table and uses OUTER APPLY to evaluate the Employee
table for each record of the Department table. For those rows for which there is not a match in Employee table,
those rows contains NULL values as you can see in case of row 5 and 6. The second query simply uses a LEFT
OUTER JOIN between the Department table and the Employee table. As expected the query returns all rows from
Department table; even for those rows for which there is no match in the Employee table.
SELECT *
FROM Department D
OUTER APPLY (
SELECT *
FROM Employee E
WHERE E.DepartmentID = D.DepartmentID
) A GO SELECT * FROM Department D
LEFT OUTER JOIN Employee E ON
D.DepartmentID = E.DepartmentID GO
Even though the above two queries return the same information, the execution plan will be bit different. But cost
wise there will be not much difference.
Now comes the time to see where the APPLY operator is really required. In Script #3, I am creating a table-valued
function which accepts DepartmentID as its parameter and returns all the employees who belong to this
department. The next query selects data from Department table and uses CROSS APPLY to join with the function
So now if you are wondering, can we use a simple join in place of the above queries? Then the answer is NO, if you
replace CROSS/OUTER APPLY in the above queries with INNER JOIN/LEFT OUTER JOIN, specify ON clause (something
as 1=1) and run the query, you will get "The multi-part identifier "D.DepartmentID" could not be bound." error. This
is because with JOINs the execution context of outer query is different from the execution context of the function
(or a derived table), and you can not bind a value/variable from the outer query to the function as a parameter.
Hence the APPLY operator is required for such queries.
See TRUNCATE documentation for details on how TRUNCATE performance can be better because it ignores triggers
and indexes and logs to just delete the data.
Let's assume we want to DELETEdata from Source once its loaded into Target.
Most common RDBMS implementations (e.g. MySQL, Oracle, PostgresSQL, Teradata) allow tables to be joined
during DELETE allowing more complex comparison in a compact syntax.
Adding complexity to original scenario, let's assume Aggregate is built from Target once a day and does not contain
the same ID but contains the same date. Let us also assume that we want to delete data from Source only after the
aggregate is populated for the day.
In PostgreSQL use:
This essentially results in INNER JOINs between Source, Target and Aggregate. The deletion is performed on Source
when the same IDs exist in Target AND date present in Target for those IDs also exists in Aggregate.
Same query may also be written (on MySQL, Oracle, Teradata) as:
DELETE Source
FROM Source, TargetSchema.Target, AggregateSchema.Aggregate
WHERE Source.ID = TargetSchema.Target.ID
AND TargetSchema.Target.DataDate = AggregateSchema.Aggregate.AggDate
Explicit joins may be mentioned in Delete statements on some RDBMS implementations (e.g. Oracle, MySQL) but
not supported on all platforms (e.g. Teradata does not support them)
Comparisons can be designed to check mismatch scenarios instead of matching ones with all syntax styles (observe
NOT EXISTS below)
Using truncate table is often better then using DELETE TABLE as it ignores all the indexes and triggers and just
removes everything.
Delete table is a row based operation this means that each row is deleted. Truncate table is a data page operation
the entire data page is reallocated. If you have a table with a million rows it will be much faster to truncate the table
than it would be to use a delete table statement.
Though we can delete specific Rows with DELETE, we cannot TRUNCATE specific rows, we can only TRUNCATE all
the records at once. Deleting All rows and then inserting a new record will continue to add the Auto incremented
Primary key value from the previously inserted value, where as in Truncate, the Auto Incremental primary key value
will also get reset and starts from 1.
Note that when truncating table, no foreign keys must be present, otherwise you will get an error.
This should mean that you have a foreign key on your room table, referencing the client table.
ALTER TABLE dbo.T_Room WITH CHECK ADD CONSTRAINT FK_T_Room_T_Client FOREIGN KEY(RM_CLI_ID)
REFERENCES dbo.T_Client (CLI_ID)
GO
Assuming a client moves on to some other software, you'll have to delete his data in your software. But if you do
Then you'll get a foreign key violation, because you can't delete the client when he still has rooms.
Now you'd have write code in your application that deletes the client's rooms before it deletes the client. Assume
further that in the future, many more foreign key dependencies will be added in your database, because your
application's functionality expands. Horrible. For every modification in your database, you'll have to adapt your
application's code in N places. Possibly you'll have to adapt code in other applications as well (e.g. interfaces to
other systems).
ALTER TABLE dbo.T_Room -- WITH CHECK -- SQL-Server can specify WITH CHECK/WITH NOCHECK
ADD CONSTRAINT FK_T_Room_T_Client FOREIGN KEY(RM_CLI_ID)
REFERENCES dbo.T_Client (CLI_ID)
ON DELETE CASCADE
and the rooms are automagically deleted when the client is deleted.
Problem solved - with no application code changes.
One word of caution: In Microsoft SQL-Server, this won't work if you have a table that references itselfs. So if you try
to define a delete cascade on a recursive tree structure, like this:
it won't work, because Microsoft-SQL-server doesn't allow you to set a foreign key with ON DELETE CASCADE on a
recursive tree structure. One reason for this is, that the tree is possibly cyclic, and that would possibly lead to a
deadlock.
PostgreSQL on the other hand can do this;
the requirement is that the tree is non-cyclic.
If the tree is cyclic, you'll get a runtime error.
In that case, you'll just have to implement the delete function yourselfs.
A word of caution:
This means you can't simply delete and re-insert the client table anymore, because if you do this, it will delete all
entries in "T_Room"... (no non-delta updates anymore)
Grant User1 and User2 permission to perform SELECT and UPDATE operations on table Employees.
Revoke from User1 and User2 the permission to perform SELECT and UPDATE operations on table Employees.
Results
This will create the Employees table with 'Id' as its primary key. The primary key can be used to uniquely identify the
rows of a table. Only one primary key is allowed per table.
A key can also be composed by one or more fields, so called composite key, with the following syntax:
PostgreSQL
SQL Server
SQLite
The database system would not do additional sorting, since it can do an index-lookup in that order.
Consider a constant growing amount of orders with order_state_id equal to finished (2), and a stable amount of
orders with order_state_id equal to started (1).
If your business make use of queries like this:
Partial indexing allows you to limit the index, including only the unfinished orders:
This index will be smaller than an unfiltered index, which saves space and reduces the cost of updating the index.
This will create an index for the column EmployeeId in the table Cars. This index will improve the speed of queries
asking the server to sort or select by values in EmployeeId, such as the following:
In this case, the index would be useful for queries asking to sort or select by all included columns, if the set of
conditions is ordered in the same way. That means that when retrieving the data, it can find the rows to retrieve
using the index, instead of looking through the full table.
For example, the following case would utilize the second index;
If the order differs, however, the index does not have the same advantages, as in the following;
The index is not as helpful because the database must retrieve the entire index, across all values of EmployeeId and
CarID, in order to find which items have OwnerId = 17.
(The index may still be used; it may be the case that the query optimizer finds that retrieving the index and filtering
on the OwnerId, then retrieving only the needed rows is faster than retrieving the full table, especially if the table is
large.)
We can use command DROP to delete our index. In this example we will DROP the index called ix_cars_employee_id on
the table Cars.
This deletes the index entirely, and if the index is clustered, will remove any clustering. It cannot be rebuilt without
recreating the index, which can be slow and computationally expensive. As an alternative, the index can be
disabled:
This allows the table to retain the structure, along with the metadata about the index.
Critically, this retains the index statistics, so that it is possible to easily evaluate the change. If warranted, the index
can then later be rebuilt, instead of being recreated completely;
The above SQL statement creates a new clustered index on Employees. Clustered indexes are indexes that dictate
the actual structure of the table; the table itself is sorted to match the structure of the index. That means there can
be at most one clustered index on a table. If a clustered index already exists on the table, the above statement will
This will create an unique index for the column Email in the table Customers. This index, along with speeding up
queries like a normal index, will also force every email address in that column to be unique. If a row is inserted or
updated with a non-unique Email value, the insertion or update will, by default, fail.
This creates an index on Customers which also creates a table constraint that the EmployeeID must be unique.
(This will fail if the column is not currently unique - in this case, if there are employees who share an ID.)
This creates an index that is sorted in descending order. By default, indexes (in MSSQL server, at least) are
ascending, but that can be changed.
By default rebuilding index is offline operation which locks the table and prevents DML against it , but many RDBMS
allow online rebuilding. Also, some DB vendors offer alternatives to index rebuilding such as REORGANIZE
(SQLServer) or COALESCE/SHRINK SPACE(Oracle).
This will fail if an unique index is set on the Email column of Customers. However, alternate behavior can be defined
for this case:
SELECT
ROW_NUMBER() OVER(ORDER BY Fname ASC) AS RowNumber,
Fname,
LName
FROM Employees
SELECT
ROW_NUMBER() OVER(PARTITION BY DepartmentId ORDER BY DepartmentId ASC) AS RowNumber,
DepartmentId, Fname, LName
FROM Employees
1 43 Store A 25 20-03-2016
2 57 Store B 50 22-03-2016
3 43 Store A 30 25-03-2016
4 82 Store C 10 26-03-2016
5 21 Store A 45 29-03-2016
SELECT
storeName,
COUNT(*) AS total_nr_orders,
COUNT(DISTINCT userId) AS nr_unique_customers,
AVG(orderValue) AS average_order_value,
MIN(orderDate) AS first_order,
MAX(orderDate) AS lastOrder
FROM
orders
GROUP BY
storeName;
While DISTINCT is used to list a unique combination of distinct values for the specified columns.
SELECT DISTINCT
storeName,
userId
FROM
orders;
storeName userId
Store A 43
Store B 57
Store C 82
Store A 21
This example uses a Common Table Expression and a Window Function to show all duplicate rows (on a subset of
columns) side by side.
Using string functions, you can, for example, combine data, extract a substring, compare strings, or convert a string
to all uppercase or lowercase characters.
Section 41.1: Concatenate
In (standard ANSI/ISO) SQL, the operator for string concatenation is
Some databases support using CONCAT to join more than two strings (Oracle does not):
Some databases (e.g., Oracle) perform implicit lossless conversions. For example, a CONCAT on a CLOB and NCLOB
yields a NCLOB. A CONCAT on a number and a varchar2 results in a varchar2, etc.:
Some databases can use the non-standard + operator (but in most, + works only for numbers):
On SQL Server < 2012, where CONCAT is not supported, + is the only way to join strings.
DECLARE @str varchar(100) = 'Hello ' --varchar is usually an ASCII string, occupying 1 byte per
char
SELECT DATALENGTH(@str) -- returns 6
DECLARE @nstr nvarchar(100) = 'Hello ' --nvarchar is a unicode string, occupying 2 bytes per char
SELECT DATALENGTH(@nstr) -- returns 12
Oracle
Examples:
SELECT value FROM STRING_SPLIT('Lorem ipsum dolor sit amet.', ' ');
Result:
value
-----
Lore
m
ipsu
m
dolor
sit
GoalKicker.com – SQL Notes for Professionals 109
amet.
SELECT REPLACE( 'Peter Steve Tom', 'Steve', 'Billy' ) --Return Values: Peter Billy Tom
This is often used in conjunction with the LEN() function to get the last n characters of a string of unknown length.
Syntax:
Example:
Oracle SQL doesn't have LEFT and RIGHT functions. They can be emulated with SUBSTR and LENGTH.
SUBSTR ( string-expression, 1, integer )
SUBSTR ( string-expression, length(string-expression)-integer+1, integer)
The following example replaces occurrences of South with Southern in Employees table:
FirstName Address
James South New York
John South Boston
Michael South San Diego
Select Statement :
SELECT
FirstName,
REPLACE (Address, 'South', 'Southern') Address
FROM Employees
ORDER BY FirstName
Result:
Update Statement :
We can use a replace function to make permanent changes in our table through following approach.
Update Employees
Set city = (Address, 'South', 'Southern');
A more common approach is to use this in conjunction with a WHERE clause like this:
Update Employees
Set Address = (Address, 'South', 'Southern')
Where Address LIKE 'South%';
PARSENAME function returns the specific part of given string(object name). object name may contains string like
object name,owner name, database name and server name.
More details MSDN:PARSENAME
Syntax
PARSENAME('NameOfStringToParse',PartIndex)
Example
PARSENAME will returns null is specified part is not present in given object name string
CustomerPayment_typeAmount
select customer,
sum(case when payment_type = 'credit' then amount else 0 end) as credit,
sum(case when payment_type = 'debit' then amount else 0 end) as debit
from payments
group by customer
Result:
CustomerCreditDebit
Peter 400 0
John 1000 500
select customer,
sum(case when payment_type = 'credit' then 1 else 0 end) as credit_transaction_count,
sum(case when payment_type = 'debit' then 1 else 0 end) as debit_transaction_count
from payments
group by customer
Result:
Customercredit_transaction_countdebit_transaction_count
Peter 2 0
John 1 1
List Concatenation aggregates a column or expression by combining the values into a single string for each group. A
string to delimit each value (either blank or a comma when omitted) and the order of the values in the result can be
specified. While it is not part of the SQL standard, every major relational database vendor supports it in their own
way.
MySQL
SELECT ColumnA
, GROUP_CONCAT(ColumnB ORDER BY ColumnB SEPARATOR ',') AS ColumnBs
FROM TableName
GROUP BY ColumnA
ORDER BY ColumnA;
PostgreSQL
SELECT ColumnA
, STRING_AGG(ColumnB, ',' ORDER BY ColumnB) AS ColumnBs
FROM TableName
GROUP BY ColumnA
ORDER BY ColumnA;
SQL Server
SQL Server 2016 and earlier
(CTE included to encourage the DRY principle)
WITH CTE_TableName AS (
SELECT ColumnA, ColumnB
FROM TableName)
SELECT t0.ColumnA
, STUFF((
SELECT ',' + t1.ColumnB
FROM CTE_TableName t1
WHERE t1.ColumnA = t0.ColumnA
ORDER BY t1.ColumnB
FOR XML PATH('')), 1, 1, '') AS ColumnBs
FROM CTE_TableName t0
GROUP BY t0.ColumnA
ORDER BY ColumnA;
SQLite
without ordering:
SELECT ColumnA
, GROUP_CONCAT(ColumnB, ',') AS ColumnBs
FROM TableName
GROUP BY ColumnA
ORDER BY ColumnA;
WITH CTE_TableName AS (
SELECT ColumnA, ColumnB
FROM TableName
ORDER BY ColumnA, ColumnB)
SELECT ColumnA
, GROUP_CONCAT(ColumnB, ',') AS ColumnBs
FROM CTE_TableName
GROUP BY ColumnA
ORDER BY ColumnA;
To select the average population of the New York City, USA from a table containing city names, population
measurements, and measurement years for last ten years:
QUERY
Notice how measurement year is absent from the query since population is being averaged over time.
RESULTS
city_name avg_population
New York City8,250,754
Note: The AVG() function will convert values to numeric types. This is especially important to keep in mind
when working with dates.
You can count over a column/expression with the effect that will not count the NULL values:
You can also use DISTINCT inside of another function such as COUNT to only find the DISTINCT members of the
set to perform the operation on.
For example:
Will return different values. The SingleCount will only Count individual Continents once, while the AllCount will
include duplicates.
ContinentCode
OC
EU
AS
NA
NA
AF
AF
AllCount: 7 SingleCount: 5
Above example will return smallest value for column age of employee table.
Syntax:
Above example will return largest value for column age of employee table.
Syntax:
The DATENAME function returns the name or value of a specific part of the date.
You use the GETDATE function to determine the current date and time of the computer running the current SQL
instance. This function doesn't include the time zone difference.
In the syntax, datepart is the parameter that specifies which part of the date you want to use to calculate
difference. The datepart can be year, month, week, day, hour, minute, second, or millisecond. You then specify the
start date in the startdate parameter and the end date in the enddate parameter for which you want to find the
difference.
The DATEADD function enables you to add an interval to part of a specific date.
would return the customer's last name changed from "SMITH" to "smith".
An example of a configuration function in SQL is the @@SERVERNAME function. This function provides the name of the
local server that's running SQL.
In SQL, most data conversions occur implicitly, without any user intervention.
To perform any conversions that can't be completed implicitly, you can use the CAST or CONVERT functions.
The CAST function syntax is simpler than the CONVERT function syntax, but is limited in what it can do.
In here, we use both the CAST and CONVERT functions to convert the datetime data type to the varchar data type.
The CAST function always uses the default style setting. For example, it will represent dates and times using the
format YYYY-MM-DD.
The CONVERT function uses the date and time style you specify. In this case, 3 specifies the date format dd/mm/yy.
USE AdventureWorks2012
GO
SELECT FirstName + ' ' + LastName + ' was hired on ' +
CAST(HireDate AS varchar(20)) AS 'Cast',
FirstName + ' ' + LastName + ' was hired on ' +
CONVERT(varchar, HireDate, 3) AS 'Convert'
FROM Person.Person AS p
JOIN HumanResources.Employee AS e
ON p.BusinessEntityID = e.BusinessEntityID
GO
Cast Convert
David Hamiltion was hired on 2003-02-04David Hamiltion was hired on 04/02/03
Another example of a conversion function is the PARSE function. This function converts a string to a specified data
type.
In the syntax for the function, you specify the string that must be converted, the AS keyword, and then the required
Date in English
2012-08-13 00:00:00.0000000
The CHOOSE function returns an item from a list of values, based on its position in the list. This position is specified
by the index.
In the syntax, the index parameter specifies the item and is a whole number, or integer. The val_1 … val_n
parameter identifies the list of values.
Result
Sales
In this example, you use the CHOOSE function to return the second entry in a list of departments.
The IIF function returns one of two values, based on a particular condition. If the condition is true, it will return
true value. Otherwise it will return a false value.
In the syntax, the boolean_expression parameter specifies the Boolean expression. The true_value parameter
specifies the value that should be returned if the boolean_expression evaluates to true and the false_value
parameter specifies the value that should be returned if the boolean_expression evaluates to false.
In this example, you use the IIF function to return one of two values. If a sales person's year-to-date sales are above
200,000, this person will be eligible for a bonus. Values below 200,000 mean that employees don't qualify for
bonuses.
SQL includes several mathematical functions that you can use to perform calculations on input values and
return numeric results.
One example is the SIGN function, which returns a value indicating the sign of an expression. The value of -1
indicates a negative expression, the value of +1 indicates a positive expression, and 0 indicates zero.
Sign
-1
In the example, the input is a negative number, so the Results pane lists the result -1.
Another mathematical function is the POWER function. This function provides the value of an expression raised to a
specified power.
In the syntax, the float_expression parameter specifies the expression, and the y parameter specifies the power to
which you want to raise the expression.
Result
125000
The default parameter specifies the value that should be returned when the expression at offset has a NULL value. If
you don't specify a value, a value of NULL is returned.
The LEAD function provides data on rows after the current row in the row set. For example, in a SELECT statement,
you can compare values in the current row with values in the following row.
You specify the values that should be compared using a scalar expression. The offset parameter is the number of
rows after the current row that will be used in the comparison.
You specify the value that should be returned when the expression at offset has a NULL value using the default
parameter. If you don't specify these parameters, the default of one row is used and a value of NULL is returned.
This example uses the LEAD and LAG functions to compare the sales values for each employee to date with those of
the employees listed above and below, with records ordered based on the BusinessEntityID column.
The PERCENTILE_CONT function is similar to the PERCENTILE_DISC function, but returns the average of the sum of
the first matching entry and the next entry.
To find the exact value from the row that matches or exceeds the 0.5 percentile, you pass the percentile as the
numeric literal in the PERCENTILE_DISC function. The Percentile Discreet column in a result set lists the value of the
row at which the cumulative distribution is higher than the specified percentile.
To base the calculation on a set of values, you use the PERCENTILE_CONT function. The "Percentile Continuous"
column in the results lists the average value of the sum of the result value and the next highest matching value.
In this example, the FIRST_VALUE function is used to return the ID of the state or province with the lowest tax rate.
The OVER clause is used to order the tax rates to obtain the lowest rate.
This example uses the LAST_VALUE function to return the last value for each rowset in the ordered values.
In this example, you use an ORDER clause to partition – or group – the rows retrieved by the SELECT statement based
on employees' job titles, with the results in each group sorted based on the numbers of sick leave hours that
employees have used.
The PERCENT_RANK function ranks the entries within each group. For each entry, it returns the percentage of entries
in the same group that have lower values.
The CUME_DIST function is similar, except that it returns the percentage of values less than or equal to the current
value.
Table items
name
id tag
1 example unique_tag
2 foo simple
42 bar simple
3 baz hello
51 quux world
I'd like to get all those lines and know if a tag is used by other lines
SELECT id, name, tag, COUNT(*) OVER (PARTITION BY tag) > 1 AS flag FROM items
In case your database doesn't have OVER and PARTITION you can use this to produce the same result:
SELECT id, name, tag, (SELECT COUNT(tag) FROM items B WHERE tag = A.tag) > 1 AS flag FROM items A
Items identified by ID values must move from STATUS 'ONE' to 'TWO' to 'THREE' in sequence, without skipping
statuses. The problem is to find users (STATUS_BY) values who violate the rule and move from 'ONE' immediately to
'THREE'.
The LAG() analytical function helps to solve the problem by returning for each row the value in the preceding row:
In case your database doesn't have LAG() you can use this to produce the same result:
date amount
2016-03-12 200
2016-03-11 -50
2016-03-14 100
2016-03-15 100
2016-03-10 -250
date amountrunning
2016-03-10 -250 -250
2016-03-11 -50 -300
2016-03-12 200 -100
2016-03-14 100 0
2016-03-15 100 -100
Instead of using two queries to get a count then the line, you can use an aggregate as a window function and use
the full result set as the window.
User_ID Completion_Date
1 2016-07-20
1 2016-07-21
2 2016-07-20
2 2016-07-21
2 2016-07-22
;with CTE as
(SELECT *,
ROW_NUMBER() OVER (PARTITION BY User_ID
ORDER BY Completion_Date DESC) Row_Num
FROM Data)
SELECT * FORM CTE WHERE Row_Num <= n
Using n=1, you'll get the one most recent row per user_id:
--Give a table name `Numbers" and a column `i` to hold the numbers
WITH Numbers(i) AS (
--Starting number/index
SELECT 1
--Top-level UNION ALL operator required for recursion
UNION ALL
--Iteration expression:
SELECT i + 1
--Table expression we first declared used as source for recursion
FROM Numbers
--Clause to define the end of the recursion
WHERE i < 5
) --Use the generated table expression like a regular
table SELECT i FROM Numbers;
i
1
2
3
4
5
This method can be used with any number interval, as well as other types of data.
UNION ALL
-- get employees that have any of the previously selected rows as manager
SELECT ManagedByJames.Level + 1,
Employees.ID,
Employees.FName,
Employees.LName
FROM Employees
JOIN ManagedByJames
ON Employees.ManagerID = ManagedByJames.ID
WITH ReadyCars AS (
SELECT *
FROM Cars
WHERE Status = 'READY'
)
SELECT ID, Model, TotalCost
FROM ReadyCars
ORDER BY TotalCost;
ID Model TotalCost
1 Ford F-150200
2 Ford F-150230
UNION ALL
-- Transition Sequence = Rest & Relax into Day Shift into Night Shift
-- RR (Rest & Relax) = 1
-- DS (Day Shift) = 2
-- NS (Night Shift) = 3
;WITH roster AS
(
SELECT @DateFrom AS RosterStart, 1 AS TeamA, 2 AS TeamB, 3 AS TeamC
UNION ALL
SELECT DATEADD(d, @IntervalDays, RosterStart),
CASE TeamA WHEN 1 THEN 2 WHEN 2 THEN 3 WHEN 3 THEN 1 END AS TeamA,
CASE TeamB WHEN 1 THEN 2 WHEN 2 THEN 3 WHEN 3 THEN 1 END AS TeamB,
CASE TeamC WHEN 1 THEN 2 WHEN 2 THEN 3 WHEN 3 THEN 1 END AS TeamC
FROM roster WHERE RosterStart < DATEADD(d, -@IntervalDays, @DateTo)
)
SELECT RosterStart,
ISNULL(LEAD(RosterStart) OVER (ORDER BY RosterStart), RosterStart + @IntervalDays) AS
RosterEnd,
CASE TeamA WHEN 1 THEN 'RR' WHEN 2 THEN 'DS' WHEN 3 THEN 'NS' END AS TeamA,
CASE TeamB WHEN 1 THEN 'RR' WHEN 2 THEN 'DS' WHEN 3 THEN 'NS' END AS TeamB,
CASE TeamC WHEN 1 THEN 'RR' WHEN 2 THEN 'DS' WHEN 3 THEN 'NS' END AS TeamC
FROM roster
Result
I.e. For Week 1 TeamA is on R&R, TeamB is on Day Shift and TeamC is on Night Shift.
WITH tbl AS (
SELECT id, name, parent_id
FROM mytable)
, tbl_hierarchy AS (
/* Anchor */
Clauses
CONNECT BY: Specifies the relationship that defines the hierarchy.
START WITH: Specifies the root nodes.
ORDER SIBLINGS BY: Orders results properly.
Parameters
NOCYCLE: Stops processing a branch when a loop is detected. Valid hierarchies are Directed Acyclic
Graphs, and circular references violate this construct.
Operators
PRIOR: Obtains data from the node's parent.
CONNECT_BY_ROOT: Obtains data from the node's root.
Pseudocolumns
LEVEL: Indicates the node's distance from its root.
CONNECT_BY_ISLEAF: Indicates a node without children.
CONNECT_BY_ISCYCLE: Indicates a node with a circular reference.
Functions
SYS_CONNECT_BY_PATH: Returns a flattened/concatenated representation of the path to the node
from its root.
SELECT *
FROM dept_income;
DepartmentName TotalSalary
HR 1900
Sales 600
number
--------
1
(1 row)
number
--------
1
(1 row)
number -
------- 1 2
(2 rows)
SELECT *
FROM Employees -- this is a comment
WHERE FName = 'John'
/* This query
returns all employees */
SELECT *
FROM Employees
The following table will contain the information of the subjects offered by the Computer science branch:
(The data type of the Foreign Key must match the datatype of the referenced key.)
The Foreign Key constraint on the column Dept_Code allows values only if they already exist in the referenced table,
Department. This means that if you try to insert the following values:
the database will raise a Foreign Key violation error, because CS300 does not exist in the Department table. But
when you try a key value that exists:
A Foreign Key must reference a UNIQUE (or PRIMARY) key in the parent table.
Entering a NULL value in a Foreign Key column does not raise an error.
Foreign Key constraints can reference tables within the same database.
Foreign Key constraints can refer to another column in the same table (self-reference).
We will add a new table in order to store the powers of each super hero:
UPDATE Orders
SET Order_UID = orders_seq.NEXTVAL
WHERE Customer = 581;
SELECT *
FROM Employees
WHERE Salary = (SELECT MAX(Salary) FROM Employees)
SELECT EmployeeId
FROM Employee AS eOuter
WHERE Salary > (
SELECT AVG(Salary)
FROM Employee eInner
WHERE eInner.DepartmentId = eOuter.DepartmentId
)
Subquery SELECT AVG(Salary) ... is correlated because it refers to Employee row eOuter from its outer query.
SELECT *
SELECT *
FROM Employees AS e
LEFT JOIN Supervisors AS s ON s.EmployeeID=e.EmployeeID
WHERE s.EmployeeID is NULL
The above finds cities from the weather table whose daily temperature variation is greater than 20. The result is:
city temp_var
ST LOUIS 21
LOS ANGELES31
LOS ANGELES23
LOS ANGELES31
LOS ANGELES27
LOS ANGELES28
LOS ANGELES28
LOS ANGELES32
Here: the subquery (SELECT avg(pop2000) FROM cities) is used to specify conditions in the WHERE clause. The result
is:
name pop2000
San Francisco776733
ST LOUIS 348189
Kansas City 146866
-- Or
EXEC Northwind.getEmployee @LastName = N'Ackerman', @FirstName = N'Pilar';
GO
-- Or
EXECUTE Northwind.getEmployee @FirstName = N'Pilar', @LastName = N'Ackerman';
GO
AS
BEGIN
-- insert audit record to MyAudit table
INSERT INTO MyAudit(MyTableId, User)
(SELECT MyTableId, CURRENT_USER FROM inserted)
END
BEGIN TRY
BEGIN TRANSACTION
INSERT INTO Users(ID, Name, Age)
VALUES(1, 'Bob', 24)
1.Each value is atomic; the value in each field in each row must be a single value.
2.Each field contains values that are of the same data type.
3.Each field heading has a unique name.
4.Each row in the table must have at least one value that makes it unique amongst the other records in the
table.
5.The order of the rows and columns has no significance.
Rule 1: Each value is atomic. Id, Name, DOB and Manager only contain a single value.
Rule 2: Id contains only integers, Name contains text (we could add that it's text of four characters or less), DOB
contains dates of a valid type and Manager contains integers (we could add that corresponds to a Primary Key
field in a managers table).
Rule 3: Id, Name, DOB and Manager are unique heading names within the table.
Rule 4: The inclusion of the Id field ensures that each record is distinct from any other record within the
table.
Such a query allows users to rapidly find database tables containing columns of interest, such as when attempting
to relate data from 2 tables indirectly through a third table, without existing knowledge of which tables may contain
keys or other useful columns in common with the target tables.
Using T-SQL for this example, a database's information schema may be searched as follows:
SELECT *
FROM INFORMATION_SCHEMA.COLUMNS
WHERE COLUMN_NAME LIKE '%Institution%'
The result contains a list of matching columns, their tables' names, and other useful information.
VT stands for 'Virtual Table' and shows how various data is produced as the query is processed
1.FROM: A Cartesian product (cross join) is performed between the first two tables in the FROM clause, and as
a result, virtual table VT1 is generated.
2.ON: The ON filter is applied to VT1. Only rows for which the is TRUE are inserted to VT2.
3.OUTER (join): If an OUTER JOIN is specified (as opposed to a CROSS JOIN or an INNER JOIN), rows from the
preserved table or tables for which a match was not found are added to the rows from VT2 as outer rows,
generating VT3. If more than two tables appear in the FROM clause, steps 1 through 3 are applied repeatedly
between the result of the last join and the next table in the FROM clause until all tables are processed.
4.WHERE: The WHERE filter is applied to VT3. Only rows for which the is TRUE are inserted to VT4.
5.GROUP BY: The rows from VT4 are arranged in groups based on the column list specified in the GROUP BY
clause. VT5 is generated.
6.CUBE | ROLLUP: Supergroups (groups of groups) are added to the rows from VT5, generating VT6.
7.HAVING: The HAVING filter is applied to VT6. Only groups for which the is TRUE are inserted to VT7.
10.ORDER BY: The rows from VT9 are sorted according to the column list specified in the ORDER BY clause. A
cursor is generated (VC10).
11.TOP: The specified number or percentage of rows is selected from the beginning of VC10. Table VT11 is
generated and returned to the caller. LIMIT has the same functionality as TOP in some SQL dialects such as
Postgres and Netezza.
Names should describe what is stored in their object. This implies that column names usually should be singular.
Whether table names should use singular or plural is a heavily discussed question, but in practice, it is more
common to use plural table names.
Adding prefixes or suffixes like tbl or col reduces readability, so avoid them. However, they are sometimes used to
avoid conflicts with SQL keywords, and often used with triggers and indexes (whose names are usually not
mentioned in queries).
Keywords
SQL keywords are not case sensitive. However, it is common practice to write them in upper case.
There is no widely accepted standard. What everyone agrees on is that squeezing everything into a single line is
bad:
At the minimum, put every clause into a new line, and split lines if they would become too long otherwise:
SELECT d.Name,
COUNT(*) AS Employees
FROM Departments AS d JOIN Employees AS e ON
d.ID = e.DepartmentID WHERE d.Name != 'HR'
HAVING COUNT(*) > 10 ORDER BY COUNT(*) DESC;
Sometimes, everything after the SQL keyword introducing a clause is indented to the same column:
SELECT d.Name,
COUNT(*) AS Employees
FROM Departments AS d
JOIN Employees AS e ON d.ID = e.DepartmentID
WHERE d.Name != 'HR'
HAVING COUNT(*) > 10
(This can also be done while aligning the SQL keywords right.)
SELECT
d.Name,
COUNT(*) AS Employees
FROM
Departments AS d
JOIN
Employees AS e
ON d.ID = e.DepartmentID
WHERE
d.Name != 'HR'
HAVING
COUNT(*) > 10
ORDER BY
COUNT(*) DESC;
SELECT Model,
EmployeeID
FROM Cars
WHERE CustomerID = 42
AND Status = 'READY';
Using multiple lines makes it harder to embed SQL commands into other programming languages. However, many
languages have a mechanism for multi-line strings, e.g., @"..." in C#, """...""" in Python, or R"(...)" in C++.
When using SELECT *, the data returned by a query can change whenever the table definition changes. This
increases the risk that different versions of your application or your database are incompatible with each other.
Furthermore, reading more columns than necessary can increase the amount of disk and network I/O.
So you should always explicitly specify the column(s) you actually want to retrieve:
--SELECT * don't
SELECT ID, FName, LName, PhoneNumber -- do
FROM Emplopees;
However, SELECT * does not hurt in the subquery of an EXISTS operator, because EXISTS ignores the actual data
anyway (it checks only if at least one row has been found). For the same reason, it is not meaningful to list any
specific column(s) for EXISTS, so SELECT * actually makes more sense:
The join condition is somewhere in the WHERE clause, mixed up with any other filter conditions. This makes
it harder to see which tables are joined, and how.
Due to the above, there is a higher risk of mistakes, and it is more likely that they are found later.
In standard SQL, explicit joins are the only way to use outer joins:
SELECT d.Name,
e.Fname || e.LName AS EmpName
FROM Departments AS d
LEFT JOIN Employees AS e ON d.ID = e.DepartmentID;
SELECT RecipeID,
Recipes.Name,
COUNT(*) AS NumberOfIngredients
FROM Recipes
LEFT JOIN Ingredients USING (RecipeID);
(This requires that both tables use the same column name.
USING automatically removes the duplicate column from the result, e.g., the join in this query returns a
single RecipeID column.)
https://somepage.com/ajax/login.ashx?username=admin&password=123
strUserName = getHttpsRequestParameterString("username");
strPassword = getHttpsRequestParameterString("password");
and query your database to determine whether a user with that password exists.
txtSQL = "SELECT * FROM Users WHERE username = '" + strUserName + "' AND password = '"+ strPassword
+"'";
This will work if the username and password do not contain a quote.
However, if one of the parameters does contain a quote, the SQL that gets sent to the database will look like this:
-- strUserName = "d'Alambert";
txtSQL = "SELECT * FROM Users WHERE username = 'd'Alambert' AND password = '123'";
This will result in a syntax error, because the quote after the d in d'Alambert ends the SQL string.
You could correct this by escaping quotes in username and password, e.g.:
cmd.CommandText = "SELECT * FROM Users WHERE username = @username AND password = @password";
cmd.Parameters.Add("@username", strUserName);
cmd.Parameters.Add("@password", strPassword);
If you do not use parameters, and forget to replace quote in even one of the values, then a malicious user (aka
hacker) can use this to execute SQL commands on your database.
For example, if an attacker is evil, he/she will set the password to
Unfortunately for you, this is valid SQL, and the DB will execute this!
There are many other things a malicious user could do, such as stealing every user's email address, steal everyone's
password, steal credit card numbers, steal any amount of data in your database, etc.
This is why you always need to escape your strings.
And the fact that you'll invariably forget to do so sooner or later is exactly why you should use parameters. Because
if you use parameters, then your programming language framework will do any necessary escaping for you.
SQL = "SELECT * FROM Users WHERE username = '" + user + "' AND password ='" + pw + "'";
db.execute(SQL);
Then a hacker could retrieve your data by giving a password like pw' or '1'='1; the resulting SQL statement will
be:
SELECT * FROM Users WHERE username = 'somebody' AND password ='pw' or '1'='1'
This one will pass the password check for all rows in the Users table because '1'='1' is always true.