Editing SQL (section)

== <span style="color: #FFFFFF;">Evaluating</span> ==
Signs of a well-designed SQL schema and query set:

* Tables are normalized to at least 3NF � no repeating groups, no partial dependencies, no transitive dependencies � unless denormalization is a deliberate performance trade-off with documented justification.
* Queries use indexes effectively; EXPLAIN / EXPLAIN ANALYZE shows index scans rather than sequential scans on large tables.
* Transactions wrap related mutations so partial failures leave the database in a consistent state (ACID guarantees).
* Migrations are versioned, reviewed, and applied non-destructively (add columns before removing old ones; never rename a column in one atomic step in a live system).
* Sensitive data (passwords, PII) is never stored in plaintext.

Expert-level judgment calls:

* '''When to denormalize''': OLAP (analytics) workloads often benefit from wide, flat tables (star/snowflake schema) to avoid expensive runtime joins over billions of rows.
* '''When to use a window function over GROUP BY''': window functions (RANK(), LAG(), running SUM OVER PARTITION BY) let you compute aggregates without collapsing rows � critical for ranking, time-series analysis, and cohort comparisons.
* '''When NOT to use a relational database''': high write throughput with flexible schema (use a document store), graph traversal queries (use a graph database), time-series data at scale (use a purpose-built TSDB).
</div>

<div style="background-color: #2F4F4F; color: #FFFFFF; padding: 20px; border-radius: 8px; margin-bottom: 15px;">