SELECT, aliases and readable outputs

Projection describes the columns produced by a query. It usually changes the output shape without changing how many input rows qualify. Our consumer needs a role identity, title and country, so the worked query names those columns explicitly rather than exposing the entire row.

Explicit projection forms a small contract. A future internal column should not accidentally become part of a public response. It also makes code review easier: readers can see exactly which data crosses the boundary before considering filters or joins.

AS assigns an output label to an expression. It does not rename the underlying column, write data or create a new table. The worked query calls title role_title so a later join with another title column can remain understandable.

Use simple unquoted aliases when possible and qualify ambiguous input columns after joins. Here the single table has no ambiguity. ORDER BY id preserves the output sequence while the selected alias describes the result column that the caller receives.

SELECT star is convenient for exploration but fragile as a maintained interface. Column additions change output shape; joined tables may contribute duplicate column names. A test that reads columns by position can then silently consume the wrong value.

The counterexample returns every stored column instead of the requested small contract. This is not a universal ban on star: an interactive inspection can use it deliberately. The mistake is allowing an exploratory shortcut to define a long-lived API without an explicit review.

Return company id as company_id and name as company_name, ordered by identity. The task needs no computed values and no new SQL mechanism. Concentrate on keeping source column names and output aliases distinct in your explanation.

Predict both the four rows and the two output labels. If your driver maps rows into objects, those labels become object keys. A value-only comparison cannot detect an accidentally renamed key, so inspect the schema as well as the displayed values.

Step 1: Select id and name. Step 2: Add two descriptive aliases.

The solution exposes exactly two company columns. Aliases clarify the data meaning without modifying setup.sql. Adding a role join would change the exercise and could repeat companies; keeping the input table small is part of the reasoning.

The acceptance rows are A Atlas Cloud, B Beacon Data, C Cedar Labs and D Drift Studio. A complete client test should also expect company_id and company_name labels. The lab verifies values; inspect result fields when checking a driver-specific object mapping.

Interviewers often ask why a query selects particular columns. Tie the answer to the consumer contract, readability and data boundaries rather than claiming that fewer columns automatically make every query fast. Actual performance also depends on row counts, access paths and storage.

Distinguish a column alias from a table alias and a durable schema change. A projection can remain stable while internal storage grows. In the next lesson, filtering changes which rows qualify while this explicit output shape remains understandable.

Optional stretch — after the core task works: Explain how a joined SELECT star can produce confusing duplicate column labels.

Computer practice: https://applydjinn.com/typorithm/sql-lab-20261105.zip. Load the shared setup.sql fixture before running a snippet. The local verifier compares exact ordered row arrays in SQLite and PostgreSQL, keeps SQL values separate from driver bindings and never connects to the production website database.