Introduction to SQL Questions and Answers

Answer: C

Correct answer: DELETE FROM CUSTOMER WHERE .

DELETE FROM removes rows, and the WHERE clause decides which. Omitting the clause is legal and empties the whole table, which is why writing the WHERE first is a habit worth having.

DROP destroys the table itself, structure and all, so it belongs to the data definition language rather than to row manipulation. UPDATE changes values in rows that remain. REMOVE is not SQL. Note that DELETE leaves the empty table in place, ready for new rows.

Answer: A

Correct answer: True

HAVING is the group-level counterpart of WHERE. It runs after GROUP BY has formed the groups and after the aggregates have been computed, so it can test them: HAVING COUNT(*) > 5 keeps only groups with more than five rows.

WHERE runs earlier, deciding which rows enter the groups, and cannot refer to an aggregate because at that point no group exists. Filtering on a plain column therefore belongs in WHERE, where it reduces the rows to be grouped, not in HAVING.

Answer: A

Correct answer: SELECT

SELECT is the query statement, and the only one that reads data. It is also by far the most elaborate, carrying FROM, WHERE, GROUP BY, HAVING and ORDER BY, and able to nest inside itself.

READ and QUERY are not SQL keywords. The choice of word is a historical accident worth noting: SELECT suggests choosing rows, but in relational terms the statement performs projection as well as selection, and after GROUP BY it aggregates too.

Answer: D

Correct answer: SELECT NAME FROM CUSTOMER WHERE STATE IN ('VA');

IN tests membership of a list, and a list with one element is equivalent to an equality test, so STATE IN ('VA') means the same as STATE = 'VA'.

The other three options fail on syntax rather than on logic: they write IN CUSTOMER where the source table must follow FROM. That is the real test here - the clause naming the table is FROM, and IN is a predicate belonging inside WHERE.

Answer: B

Correct answer: DROP TABLE CUSTOMER;

DROP TABLE removes the table itself - its rows, its definition, its indexes and its constraints - leaving no object of that name in the database.

The contrast with DELETE is the point of the question. DELETE FROM CUSTOMER removes rows but keeps the table, ready for new ones. DROP is data definition, DELETE is data manipulation. TRUNCATE TABLE sits between them, emptying the table quickly while keeping its structure. REMOVE TABLE and DELETE TABLE are not SQL.

Answer: A

Correct answer: DML(Data Manipulation Langauge)

Querying, inserting, deleting and modifying tuples are exactly the operations of the Data Manipulation Language: SELECT, INSERT, DELETE and UPDATE.

DDL by contrast defines the structures those tuples live in. Note that the query language is a part of DML rather than a separate thing, which is why "Query" as an option is too narrow - it names one of the four capabilities the question lists. A relational schema is a description, not a language.

Answer: D

Correct answer: table

Every SELECT returns a relation - rows and columns - and that is a table, even though it is not stored. This is the closure property of the relational model: an operation on tables yields a table.

Closure is what makes SQL composable. A query's result can be the input of another query, which is exactly what a subquery, a derived table in the FROM clause, and a view all rely on. Reports, forms and files are how a result may be presented, but they are not what the statement returns.

Answer: A

Correct answer: True

Every SELECT returns a relation - named columns and zero or more rows - and that is a table, even though it is not stored anywhere.

This is the relational model's closure property, and it is what makes SQL composable: because the result of a query is the same kind of thing as its input, a query can feed another query. Subqueries, derived tables in the FROM clause and views all depend on it. Even an aggregate with no GROUP BY returns a table, of one row and one column.

Answer: A

Correct answer: True

SELECT names the columns wanted, FROM names the source, and WHERE filters the rows. Every query is built on that skeleton, with GROUP BY, HAVING and ORDER BY added as needed.

Note that the written order and the logical order differ: the engine resolves FROM first, then WHERE, and reaches SELECT only afterwards. That is why an alias defined in the SELECT list cannot be used in the WHERE clause - at that point it does not yet exist.

Answer: A

Correct answer: LIKE only

Wildcards are meaningful only to LIKE, which performs pattern matching: WHERE name LIKE 'Sm%' finds every name beginning with those two letters.

IN and NOT IN test membership of an explicit list of values, and a wildcard inside such a list is simply a literal character with no special meaning. So WHERE state IN ('V%') matches the two-character string V% and nothing else - a mistake that fails silently, returning no rows rather than an error.