SQL Essentials

1. A Python programmer says: “A SQL table is just like a Python list of dictionaries.” What is the most important difference they are missing?

• SQL tables are stored on disk; Python lists live in memory

  Disk vs. memory is incidental — modern Python streams from disk and SQL can run in-memory. The deeper gap is that SQL rows have no positional access at all.

• SQL tables enforce a rigid schema; rows have no guaranteed order
• Rows are accessed by 1-based index instead of 0-based

  There’s no students[0] in SQL. Rows aren’t indexed by position — you identify them by content (WHERE). 1-based vs 0-based isn’t the issue; no positional access is.

• Python lists can hold more data than SQL tables

  Capacity isn’t the difference. Both can hold large data. The conceptual gap is that a SQL table is a set (no order, schema-enforced), not a list.

2. Without an ORDER BY clause, in what order does SQL return rows?

• In insertion order — the order rows were added

  Insertion order isn’t guaranteed. Small tables may happen to come back that way, but the engine is free to return rows in any order it likes.

• In primary key order — ascending by id

  The primary key uniquely identifies rows; it doesn’t dictate result-set order. SQLite, Postgres, MySQL — none guarantee PK order without ORDER BY.

• Alphabetically by the first column

  There’s no default-alphabetical rule. Result order depends on storage layout, indexes, and the query planner — not on column types or names.

• In no guaranteed order — depends on storage and query plan

3. In Python you write students[0] to get the first student. What is the SQL equivalent?

• SELECT * FROM students WHERE id = 0

  id = 0 references a value, not a position. Even if a row had id 0, that’s content-based lookup — not the same as Python’s students[0], which asks for position 0.

• SELECT * FROM students[0]

  Not valid SQL — tables aren’t subscriptable. SQL doesn’t expose row position.

• There is no equivalent — SQL rows have no position
• SELECT FIRST FROM students

  No FIRST keyword in standard SQL. Some dialects have LIMIT 1 paired with ORDER BY, but that’s still content-based — picking ‘first’ requires defining an ordering.

4. Arrange the fragments to write a query that retrieves only the name and gpa columns from the students table. (arrange in order)

1. SELECT
2. name, gpa
3. FROM
4. students;

• WHERE
• *

5. The students table has 9 rows but only 4 distinct majors. What does SELECT major FROM students return?

• 4 rows — duplicates are removed by default

  Set theory wants {CS, CS, Math} to collapse to {CS, Math}. SQL is a multiset — duplicates stick around unless you ask for them to be removed with DISTINCT.

• 9 rows — one for each student, with duplicate majors included
• 9 rows, but pre-deduplicated by the query optimizer when storage allows

  Optimizers don’t silently change the row count. SELECT major always returns one row per source row; deduplication requires explicit DISTINCT.

• An error — projecting only major is ambiguous when multiple students share one

  No ambiguity — every row contributes its own major value to the projection. The grouping rule (Step 4) only applies once GROUP BY enters the picture.

6. Two teammates need every column from students for a debugging session. Alice writes:

SELECT * FROM students;

SELECT id, name, year, major, gpa FROM students;

• Alice’s — SELECT * automatically adapts to schema changes

  That’s the bug, not the feature. Alice’s code starts returning phone_number and later ssn to every caller. If any caller wasn’t expecting them — log files, JSON exports, downstream services — Alice has just created a privacy incident.

• Bob’s — explicit columns isolate his code from accidental data leaks (PII like ssn) and from breaking when downstream code expects exactly 5 columns
• Tie — both forms are equivalent; SQL’s optimizer flattens any difference

  Optimizers can’t read your intent. Both queries have identical execution plans today, but they have very different consequences when the schema evolves. Choose explicit columns at write time.

• Alice’s — fewer characters means smaller network payloads and faster execution

  Network payload differences are negligible compared to the maintenance and security cost. Production codebases ban SELECT * from non-exploratory code precisely because of the schema-evolution risk.

1. You write SELECT * FROM students s, majors m; with no WHERE or ON. What do you get?

• An error — SQL requires an ON clause

  SQL is happy to silently produce a Cartesian product — the comma syntax is a valid join (a CROSS JOIN), just rarely the one you wanted. The DBMS has no way to know your intent, so it gives you what you literally asked for.

• Only rows where students.major = majors.code

  Plain SQL never infers a join condition; you must spell out ON s.major = m.code (or WHERE s.major = m.code). ORMs that auto-join on declared relationships add this convenience on top — but the SQL standard itself does no such inference.

• Every student paired with every major (36 rows)
• An empty result set

  Cross-product is the algebraic default, not an empty set. An empty result would require all rows to fail some predicate — but here there is no predicate to fail.

2. A JOIN ... ON s.major = m.code between students (9 rows) and majors (4 rows) returns 8 rows. Why not 9?

• JOIN always drops one row

  JOINs don’t have a fixed-cost arithmetic; they keep every pair where ON is TRUE. The number of rows lost depends on the data, not on a constant rule.

• One student has a NULL major, which matches nothing
• One major has no students — and that row drops

  An inner JOIN is symmetric — a major with zero students does drop, but that doesn’t change the student count on the left side. The 9 students you started with stay unless their predicate fails.

• Aliases hide one row from the output

  Aliases (AS s, AS m) are syntactic shorthand only — they rename tables for the rest of the query, but never filter rows. They do not affect cardinality.

3. Arrange the fragments to list each student’s name and their department. (arrange in order)

1. SELECT s.name, m.department
2. FROM students AS s
3. JOIN majors AS m
4. ON s.major = m.code;

• FROM students, majors
• WHERE s.major = m.code

4. Why are table aliases (AS s, AS m) strongly recommended even in simple two-table joins?

• SQL refuses to run without them

  Aliases are optional in SQL — the query runs fine without them when no column names collide. They become required when you self-join a table to itself.

• They disambiguate same-named columns across tables
• They improve query performance

  Aliases are pure syntax; the query planner ignores them. Performance comes from indexes, joins, and predicates.

• They prevent NULL values in the result

  NULLs come from the data (or from outer joins), not from how you name tables. Aliases don’t filter.

5. For an INNER JOIN, do these two queries return the same rows? Query A: SELECT * FROM students s JOIN majors m ON s.major = m.code AND s.year > 1; Query B: SELECT * FROM students s JOIN majors m ON s.major = m.code WHERE s.year > 1;

• Yes — the result is identical for an INNER JOIN
• No — predicate placement always changes the result

  For an outer join, placement absolutely matters. For inner joins specifically, both forms produce the same row set — the join keeps a row only when both predicates are TRUE.

• Yes, but only if year has no NULLs

  NULL handling is identical here — NULL > 1 is UNKNOWN, and both queries drop the row. The 3VL behavior doesn’t differ between ON-clause filters and WHERE filters.

• No — Query A pre-filters and is therefore always faster

  Modern optimizers reorder predicates regardless of where you wrote them. A query planner sees both forms and produces the same plan.

1. A student writes:

WHERE status != 'Active'

• They are included — NULL is not equal to ‘Active’

  Intuitively true, but SQL doesn’t agree. NULL means ‘unknown’ — comparing it to anything (even with !=) yields UNKNOWN, and WHERE keeps only TRUE rows.

• They are excluded — NULL != 'Active' is UNKNOWN, not TRUE
• They cause a runtime error

  No error. WHERE silently drops UNKNOWN-evaluating rows; that silent drop is exactly the bug to watch for.

• They are included only if NULL is listed as a valid status

  There’s no ‘list of valid statuses’ anywhere. NULL handling is governed by 3VL, not by a list.

2. Which expression correctly tests whether a column value is missing (NULL)?

• WHERE credits = NULL

  = NULL evaluates to UNKNOWN — never TRUE. SQL has a special operator for this case precisely because = doesn’t work on NULL.

• WHERE credits == NULL

  == is not valid SQL — it borrows from C-family languages. SQL uses single = for equality, and even then IS NULL for NULL tests.

• WHERE credits IS NULL
• WHERE ISNULL(credits) = 1

  Some dialects offer ISNULL() (and Oracle has NVL()), but they’re non-standard extensions. IS NULL is the portable answer.

3. In SQL’s logical execution order, the SELECT clause is written first. When is it actually evaluated?

• First — it defines what data to retrieve

  Reading order is misleading. SELECT is written first but logically runs after the row-filtering and grouping clauses.

• Second — immediately after FROM determines the source table

  FROM identifies the source, but WHERE filters before SELECT projects. Otherwise, an alias used in SELECT couldn’t reference filtered-out rows.

• Fifth — after FROM, WHERE, GROUP BY, and HAVING
• Last — after ORDER BY and LIMIT

  ORDER BY runs after SELECT (so it can refer to SELECT’s aliases). LIMIT is the absolute last step.

4. What does SELECT name, gpa FROM students do?

• It filters the table to only include rows that have a name and a gpa

  That’s row filtering — the job of WHERE. SELECT picks columns, not rows.

• It returns all rows but only the name and gpa columns
• It creates new columns called name and gpa

  Those columns must already exist on the table. SELECT doesn’t create columns; it projects existing ones (or computes expressions over them).

• It sorts the table by name and then by gpa

  Sorting is ORDER BY name, gpa. SELECT alone has no implicit ordering — that’s why you saw the first quiz warn about row order.

5. Arrange the clauses to find CS students with GPA above 3.5, sorted highest first. (arrange in order)

1. SELECT name, gpa
2. FROM students
3. WHERE major = 'CS' AND gpa > 3.5
4. ORDER BY gpa DESC;

• HAVING gpa > 3.5
• SORT BY gpa DESC;

6. A student writes two queries. Which one is more likely to produce unexpected results in production, and why? Query A: SELECT * FROM users WHERE role != 'admin' Query B: SELECT id, name FROM users WHERE role != 'admin' OR role IS NULL

• Query A — silently drops NULL roles, plus uses SELECT *
• Query B — the extra OR clause makes it slower

  The extra OR is constant cost — and on indexed columns, both queries optimize similarly. Correctness beats microseconds anyway.

• Both are equally safe in production

  They differ on both projection (* vs explicit columns) and on how NULL roles are treated. They are not equally safe.

• Query A — SELECT * causes a syntax error

  SELECT * is valid SQL — that’s part of the trap. It compiles fine; it’s just brittle as columns get added/dropped.

1. A student writes:

SELECT major, name, COUNT(*) AS n
FROM students
GROUP BY major;

• COUNT(*) is not a valid aggregate function

  COUNT(*) is the canonical row-count aggregate — it appears in every SQL textbook and is the most widely-supported function in SQL. The problem isn’t that aggregate; it’s the bare column next to it.

• name is in SELECT but not in GROUP BY or any aggregate
• GROUP BY must appear before SELECT in the written query

  Clauses appear in a fixed order in the written query (SELECT → FROM → WHERE → GROUP BY), but they are evaluated in a different order: FROM → WHERE → GROUP BY → SELECT. This question is about a semantic violation, not a syntactic one.

• Non-aggregate columns and aggregates cannot mix in one SELECT

  Aggregates and non-aggregates can mix — that’s the whole point of GROUP BY. The rule is: every non-aggregate column must appear in GROUP BY so the database knows it has one value per group. Here name doesn’t, so the database has multiple names per major and no rule for which to pick.

2. Which clause filters groups based on an aggregate condition?

• WHERE

  WHERE filters rows before grouping — at WHERE-time, the aggregates don’t exist yet. WHERE COUNT(*) > 5 is always an error.

• HAVING
• FILTER

  FILTER exists in some dialects (SQL:2003 introduced FILTER (WHERE ...) for inline aggregate filtering), but it’s per-aggregate. Group-level filtering is HAVING’s job.

• SELECT ... WHERE

  There’s no SELECT ... WHERE clause structure for groups — SELECT projects, WHERE filters rows, HAVING filters groups. Three different jobs, three different keywords.

3. If 3 out of 10 students have a NULL value in the gpa column, what does each of these return? COUNT(*) vs COUNT(gpa)

• Both return 10 — COUNT always includes every row

  COUNT(*) does count every row, but COUNT(column) is a different aggregate that filters NULLs. The two forms exist precisely to give you a choice between “how many rows in the group?” and “how many known values in this column?”

• Both return 7 — COUNT skips NULL rows

  This collapses the two forms into one. The distinction is intentional: when the column is the answer (“how many students have a known GPA?”) use COUNT(column); when you want the group’s size regardless of nullness use COUNT(*).

• COUNT(*) returns 10; COUNT(gpa) returns 7
• COUNT(*) returns 7; COUNT(gpa) returns 10

  Backwards. COUNT(*) always sees the row even if every column is NULL — only the row’s existence matters. COUNT(gpa) is the one that drops the NULLs.

4. A query uses WHERE year > 2 to filter rows before grouping. If a student has year set to NULL, are they included in the grouped results?

• Yes — NULL is treated as 0, which is not greater than 2

  SQL treats NULL as unknown, not zero: NULL > 2, NULL = 0, NULL = NULL all evaluate to UNKNOWN — never TRUE, never FALSE. Spreadsheets coerce blank cells to 0, which sets up the wrong intuition for SQL.

• Yes — WHERE passes all rows to GROUP BY by default

  WHERE applies its predicate to every row, including NULL ones. There is no “pass-through” rule; the predicate just gets a NULL operand and produces UNKNOWN, which WHERE then drops.

• No — NULL > 2 is UNKNOWN, and WHERE discards UNKNOWN rows
• It depends on the database engine

  NULL handling in WHERE is one of the most consistent parts of SQL across engines — three-valued logic (TRUE/FALSE/UNKNOWN) is in the ANSI standard and every major database implements it the same way. Other things vary; this doesn’t.

5. Arrange the clauses to count students per major, but only show majors with more than 2 students. (arrange in order)

1. SELECT major, COUNT(*) AS n
2. FROM students
3. GROUP BY major
4. HAVING COUNT(*) > 2;

• WHERE COUNT(*) > 2;
• ORDER BY major

6. Arrange the steps in the order the database actually executes them, for this query:

SELECT major, COUNT(*) AS n FROM students
WHERE year > 1 GROUP BY major HAVING COUNT(*) >= 2 ORDER BY n DESC;

1. FROM students — read the source rows
2. WHERE year > 1 — drop rows where year is 1 or NULL
3. GROUP BY major — partition surviving rows into groups
4. HAVING COUNT(*) >= 2 — drop groups smaller than 2
5. SELECT major, COUNT(*) AS n — project the final columns
6. ORDER BY n DESC — sort groups by count

• SELECT first, then filter rows in WHERE
• ORDER BY runs before HAVING

7. [Review from Step 3] A table has a nullable status column. Which query correctly finds all rows where status is either 'inactive' or unknown?

• WHERE status = 'inactive' OR status = NULL

  The first half is fine, but status = NULL always evaluates to UNKNOWN — it never matches. SQL has IS NULL precisely because = doesn’t work on NULL.

• WHERE status = 'inactive' OR status IS NULL
• WHERE status IN ('inactive', NULL)

  IN (a, b) desugars to status = a OR status = b. The NULL inside expands to status = NULL, which is UNKNOWN, so it silently misses NULL rows.

• WHERE status != 'active'

  != 'active' drops NULL rows the same way = 'inactive' does — three-valued logic strikes again. You’d need OR status IS NULL regardless.

1. What does PRIMARY KEY guarantee about a column’s values?

• Values are sorted in ascending order

  Storage may happen to keep PK rows ordered (B-tree indexes do this), but logically there’s no sort guarantee. Result-set order still requires ORDER BY.

• The column cannot contain text

  PRIMARY KEY can be on any type — INTEGER, TEXT, BLOB. The constraint is uniqueness, not the column type.

• Each value is unique and non-null across all rows
• The column is indexed for faster lookups only

  An implicit index is created, but that’s a side effect. The defining contract is uniqueness + non-null, which is what ‘identifying every row’ requires.

2. What happens if you INSERT INTO a row but omit a column declared NOT NULL with no default?

• The column is automatically set to 0 or an empty string

  There’s no implicit default of 0 or '' unless you declared one. Without DEFAULT, the column has no fallback.

• The row is inserted with NULL in that column

  That’d defeat the purpose of NOT NULL. The constraint says the column may never be NULL — including at insert time.

• The database raises an error and the row is not inserted
• The row is inserted but flagged as incomplete

  There’s no ‘incomplete’ state. A row either satisfies all constraints or the insert is rejected outright.

3. A student writes:

SELECT full_name FROM students WHERE full_name = 'Mango';

• Logical error — the query runs but returns wrong rows

  A logical error runs successfully but produces the wrong result. Here the query never runs — the column lookup fails before execution.

• Semantic error — valid grammar, but references something that does not exist
• Syntax error — the SQL grammar rules are violated

  Syntax errors are about grammar (missing parentheses, misplaced clauses). The grammar is fine here; the meaning is broken.

• Constraint violation — a NOT NULL or PRIMARY KEY rule was broken

  Constraints are about row-level data validity (NOT NULL, PRIMARY KEY, FOREIGN KEY). This is a naming problem at parse time.

4. You need to store a library’s book collection. Each book has a title, author, year published, and an optional page count. Which schema is best?

• CREATE TABLE books (title TEXT, author TEXT, year INTEGER, pages INTEGER)

  Missing a PRIMARY KEY — without one there’s no guaranteed way to uniquely identify each book, making updates and deletes ambiguous.

• CREATE TABLE books (id INTEGER PRIMARY KEY, title TEXT NOT NULL, author TEXT NOT NULL, year INTEGER, pages INTEGER)
• CREATE TABLE books (id INTEGER, title TEXT, author TEXT, year TEXT, pages TEXT)

  Storing year as TEXT instead of INTEGER loses type safety — you can’t sort or range-query correctly, and the column accepts non-year strings.

• CREATE TABLE books (book_data TEXT)

  Storing all data in a single TEXT column gives up all schema enforcement: no types, no NOT NULL constraints, and no ability to query individual fields.

5. Arrange the lines to create a songs table with a primary key and a required title. (arrange in order)

1. CREATE TABLE songs (
2. id INTEGER PRIMARY KEY,
3. title TEXT NOT NULL,
4. artist TEXT,
5. plays INTEGER
6. );

• id INTEGER UNIQUE,
• title TEXT NULL,

6. [Review] What is the correct logical execution order of these SQL clauses? (arrange in order)

1. FROM
2. WHERE
3. GROUP BY
4. HAVING
5. SELECT
6. ORDER BY

• SORT BY
• FILTER

1. A developer runs:

DELETE FROM orders;

• The orders table is removed from the database

  DELETE removes rows, not the table itself. To remove the schema too, use DROP TABLE.

• All rows are deleted but the table structure remains
• An error — DELETE requires a WHERE clause

  SQL doesn’t require WHERE on DELETE — that’s exactly what makes this footgun dangerous. The query runs cleanly and empties the table.

• Only rows matching the implicit WHERE TRUE condition are deleted

  There’s no implicit WHERE TRUE concept — DELETE without WHERE just deletes everything by design. The framing in this option implies a safety net that doesn’t exist.

2. What is the safest way to remove a table that may or may not exist, without causing an error?

• REMOVE TABLE IF EXISTS courses;

  There’s no REMOVE TABLE keyword in SQL. The keyword is DROP.

• DELETE TABLE courses;

  DELETE TABLE is invalid syntax. DELETE FROM removes rows; DROP TABLE removes the table itself.

• DROP TABLE IF EXISTS courses;
• TRUNCATE TABLE IF EXISTS courses;

  TRUNCATE removes rows (like DELETE without WHERE) but keeps the schema. Also, SQLite doesn’t support TRUNCATE at all — and TRUNCATE TABLE IF EXISTS isn’t standard.

3. Before running an UPDATE on a production table, what should you do first?

• Run the UPDATE and check the result in the UI

  By the time you check the UI, the change is committed. The whole point is to preview before the destructive action.

• Run a SELECT with the same WHERE clause to preview affected rows
• Add ORDER BY to the UPDATE so the order is deterministic

  ORDER BY on UPDATE doesn’t preview anything — and it’s not even standard. The point is to verify which rows are affected, not what order they’re processed in.

• Change WHERE to WHERE TRUE so every row is visible

  WHERE TRUE matches every row — the opposite of safe. You want to verify the specific rows the UPDATE will hit.

4. After running DROP TABLE courses, what happens if you run SELECT * FROM courses?

• It returns an empty result set (no rows, but the columns are shown)

  Empty result requires the schema to still exist (so columns are known). DROP removes the schema too — there’s nothing to project.

• The database raises an error — the table no longer exists
• It returns NULL for every column

  NULL implies columns existing but values being unknown. After DROP, the columns themselves don’t exist.

• It returns the data that was in the table before the DROP

  DROP doesn’t soft-delete or version data. The table is gone; old data isn’t recoverable from SQL alone.

5. Arrange the steps for safely updating Kiwi’s GPA. The professional workflow: preview first, then modify. (arrange in order)

1. -- Preview the rows you're about to change
2. SELECT * FROM students WHERE name = 'Kiwi';
3. -- Then apply the change
4. UPDATE students SET gpa = 3.6 WHERE name = 'Kiwi';

• UPDATE students SET gpa = 3.6;
• DELETE FROM students WHERE name = 'Kiwi';

6. [Review from Step 4] What is the difference between COUNT(*) and COUNT(email)?

• COUNT(*) counts all rows; COUNT(email) counts only rows where email is not NULL
• COUNT(*) is slower; COUNT(email) is optimized

  Performance is roughly identical for both — engines optimize them similarly. The semantic difference (NULL handling) is what matters.

• They are equivalent — both count all rows

  They differ on rows where the named column is NULL. If email is nullable and some rows are NULL, the two return different counts.

• COUNT(*) counts columns; COUNT(email) counts rows

  Both count rows. * is a special form meaning ‘count any row’; COUNT(column) filters rows where the column is non-NULL.

7. [Review from Step 3] Which statement correctly removes every student whose major is NULL?

• DELETE FROM students WHERE major = NULL

  = NULL evaluates to UNKNOWN, never TRUE. The DELETE would run but match no rows — silently doing nothing, exactly the trap that motivates IS NULL.

• DELETE FROM students WHERE major IS NULL
• DELETE FROM students WHERE major != 'CS'

  != 'CS' would also drop NULL rows by 3VL — but it would also delete every non-CS student with a known major. Way too broad.

• DELETE FROM students WHERE major

  Bare WHERE major (without an operator) treats major as a boolean — implicit conversion that’s not portable. It’s not what you want for NULL semantics.

1. Two engineers debate. Engineer A writes:

SELECT major, AVG(gpa) FROM students GROUP BY major HAVING COUNT(*) >= 2;

SELECT major, AVG(gpa) FROM students WHERE COUNT(*) >= 2 GROUP BY major;

• A — WHERE cannot reference an aggregate; that condition belongs in HAVING
• B — WHERE runs first, so it filters faster than HAVING

  WHERE does run before grouping — and that’s exactly why it can’t reference COUNT(*). The count doesn’t exist yet at WHERE time.

• Both run; SQLite is permissive about this

  SQLite is more permissive than other engines on some things (e.g., the GROUP BY rule), but it still rejects aggregates in WHERE. Both rejections are universal.

• Neither — both need a JOIN

  Neither query needs a JOIN — students alone holds enough data. The bug is the placement of COUNT(*), not the absence of a JOIN.

2. [Review from Step 3] In your capstone query, you wrote WHERE year >= 2. If a future student has year set to NULL, are they included in the result?

• Yes — NULL is treated as 0

  SQL treats NULL as unknown, not zero. Spreadsheet intuition (blank → 0) doesn’t carry over.

• No — NULL >= 2 is UNKNOWN, and WHERE discards UNKNOWN rows
• Yes — WHERE includes NULL by default

  There’s no NULL-pass-through default. WHERE applies its predicate to every row, and NULL operands always produce UNKNOWN.

• It depends on the database engine

  3VL is in the ANSI SQL standard. Every major engine treats NULL comparisons identically — it’s one of the most consistent parts of SQL.

3. [Review from Step 4] The grouping rule states that every column in SELECT must either appear in GROUP BY or be wrapped in an aggregate. Why?

• It’s a stylistic convention to keep queries readable

  It’s a semantic requirement, not stylistic. Standard-compliant engines reject violations; SQLite silently picks an arbitrary value, which is worse.

• Without it, multiple values map to one group with no defined choice — the result is undefined
• GROUP BY only supports indexed columns

  GROUP BY works on any column type. Indexes affect performance, not whether grouping is allowed.

• The SQL standard prohibits mixing aggregates and non-aggregates in the same SELECT

  The standard does allow mixing — that’s the entire point of GROUP BY. The constraint is that non-aggregate columns must be in GROUP BY too.

4. Arrange the clauses of your capstone query in the order the database actually executes them. (arrange in order)

1. FROM students JOIN majors
2. WHERE year >= 2
3. GROUP BY major
4. HAVING COUNT(*) >= 2
5. SELECT major, AVG(gpa), COUNT(*)
6. ORDER BY avg_gpa DESC

• WHERE year >= 2 AND COUNT(*) >= 2
• SORT BY avg_gpa DESC