Format a SQL CREATE TABLE Statement

CREATE TABLE statements are the foundation of relational database design, and they deserve the same care and readability as any other piece of code. A well-written CREATE TABLE is self-documenting: it tells you what data the table stores, which fields are required, what constraints enforce data integrity, and how this table relates to others in the schema. The SQL formatter makes this documentation function clear by aligning column definitions and separating constraint declarations. This example creates a users table with patterns common to most production applications: a BIGINT UNSIGNED auto-incrementing primary key, email and name VARCHAR fields with NOT NULL constraints, a role ENUM with allowed values and a default, a nullable foreign key to a teams table, and two automatically managed timestamps for record creation and last modification. Key parts explained in detail: AUTO_INCREMENT generates unique IDs automatically — you don't need to specify an id value in INSERT statements. NOT NULL is a constraint that the database enforces at the storage level, unlike application-level validation which can be bypassed. DEFAULT 'user' means new rows get the "user" role unless explicitly set. The UNIQUE KEY uq_email constraint ensures no two users can share the same email address, which the database enforces even if your application code fails to check. Timestamp automation: DEFAULT CURRENT_TIMESTAMP sets created_at to the current time on INSERT without you specifying it. ON UPDATE CURRENT_TIMESTAMP automatically updates updated_at whenever any other field in the row changes — this is a MySQL-specific feature that PostgreSQL handles differently (requiring a trigger). Foreign key design: the FOREIGN KEY (team_id) REFERENCES teams(id) ON DELETE SET NULL means when a team is deleted, users in that team have their team_id set to NULL rather than being deleted themselves (CASCADE) or blocking the team deletion (RESTRICT). Choosing the right ON DELETE behavior is a critical schema design decision. Real-world scenarios: writing the initial migration file for a new application feature; documenting the current schema in a README by pasting formatted CREATE TABLE statements; reviewing a proposed schema change in a pull request where the formatter makes the diff readable. Tips: always include indexes on columns you'll frequently use in WHERE clauses, JOIN conditions, and ORDER BY clauses. The primary key is indexed automatically, and UNIQUE constraints create indexes, but other columns need explicit INDEX declarations.

CREATE TABLE users (
  id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
  email VARCHAR(255) NOT NULL,
  name VARCHAR(100) NOT NULL,
  role ENUM('admin','user','editor') NOT NULL DEFAULT 'user',
  team_id INT UNSIGNED,
  created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
  updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (id),
  UNIQUE KEY uq_email (email),
  FOREIGN KEY (team_id) REFERENCES teams(id) ON DELETE SET NULL
);