Tables, Columns, Comments

Announce at start: "Using pythia-table — reading the table and its neighbours before designing DDL."

Phase: Learn → Ask → Do — the table as it is, the decisions that are the developer's, then one ordered script

A table outlives every program that reads it. Its columns are a contract with every report, interface and procedure in the schema, and structural DDL has almost no undo:

DROP COLUMN

is permanent, a renamed column breaks every caller at once. Five minutes of design is the cheapest step there is.

The Iron Law

NO TABLE OR COLUMN WITHOUT ITS COMMENT, ITS CONSTRAINTS AND ITS IMPACT KNOWN

The Workflow

Learn the table and its neighbours.
- ```
pythia cols T
```
  ·
```
pythia comments T
```
  ·
```
pythia stats T
```
  — what exists, what is documented, which foreign keys lack an index.
- ```
pythia impact T
```
  before any ALTER — every program that recompiles.
- ```
pythia similar T_<NAME>
```
  and
```
pythia ddl TABLE <NEIGHBOUR>
```
  — how this house already builds tables: PK style, audit columns, tablespace, naming. Read
```
.pythia/conventions.md
```
  and
```
pythia conventions
```
  .
Ask what is the developer's (through
```
pythia-spec
```
): what is kept or deleted, nullability of existing rows and the backfill value, retention, who writes the table (an API package, a trigger, an interface), identity column vs sequence when the house has no rule. Never invent a business default for a NOT NULL column.
Write one ordered script —
```
reference/ddl-standards.md
```
has the template and the datatype rules:
- name every constraint (
```
PK_
```
  ,
```
FK_
```
  ,
```
UK_
```
  ,
```
CK_
```
  unless the house says otherwise); a primary key on every table; an index on every FK column;
- text as
```
VARCHAR2(n CHAR)
```
  — a Vietnamese character can take 3 bytes; money as
```
NUMBER(p,s)
```
  , never FLOAT;
```
DATE
```
  or
```
TIMESTAMP
```
  by need;
- ```
COMMENT ON TABLE
```
  and
```
COMMENT ON COLUMN
```
  for every new table and column: meaning, unit, allowed values, source. Vietnamese is fine here —
```
COMMENT ... IS
```
  takes a literal only (no
```
unistr
```
  ), and pythia sends UTF-8 exactly;
```
pythia doctor --db
```
  warns if the character set cannot hold it.
Lint it:
```
pythia lint script.sql comments.sql
```
(one run, so the comments file counts) — missing comments, unnamed constraints, unindexed FKs,
```
ADD ... NOT NULL
```
without a default, byte-semantics text, missing house columns. Errors are fixed, not argued.
Land it with
```
pythia-deploy
```
(
```
pythia deploy script.sql
```
): every statement previewed, one approval, run in order, stopped at the first failure. A single statement can go through
```
pythia apply
```
as usual.
```
structural
```
is
```
deny
```
by default — relay the refusal; the developer decides (
```
pythia policy set structural confirm
```
, or an autopilot lease naming
```
structural
```
).

Verify (

pythia-verify

pythia cols T

pythia comments T

(0 missing),

pythia invalid

against the baseline.

Changing a live table — expand, then contract

Change	Safe shape
New mandatory column	`ADD (c ... DEFAULT <agreed> NOT NULL)` — one step, metadata-only on 12c+. No agreed default → add nullable, backfill ( `data_dml` ), then `MODIFY c NOT NULL` .
Rename	Never in place on a shared schema: add the new column, copy, move the callers, drop the old one later — a separate, destructive approval.
Type change	Widening ( `VARCHAR2(50)` → `(100)` ) is in place; anything narrowing or converting: new column, copy, swap.
New FK on existing data	`ENABLE NOVALIDATE` first, clean the rows, then `VALIDATE` — and the index before the constraint.
Drop	Destructive: its own preview, its own approval, never inside an autopilot lease unless the card said so. Check the Recycle Bin is on and never add `PURGE` without being asked.

Big tables (millions of rows):

ALTER TABLE ... ADD

with a default is metadata-only, but

MODIFY

, index builds and backfills are not — ask about a window, and

ONLINE

index builds need Enterprise Edition. Partitioning and compression are separately licensed options: name that before proposing them.

Is rollback real?

Statement	Undo
`COMMENT ON`	Yes — the previous comment is snapshotted; `pythia journal restore <entry>` .
`CREATE TABLE / INDEX / SEQUENCE`	A `DROP` — structural, written by hand, approved like any write.
`ALTER TABLE ADD`	`ALTER TABLE ... DROP COLUMN` — the data written since is lost.
`DROP` , `TRUNCATE` , `SET UNUSED`	No. Flashback is a DBA's job, if retention allows it.

Red Flags — STOP if you catch yourself thinking

Thought	Reality
"Comments later, once it works"	Later never comes; the dictionary is the only documentation that survives. Same script.
"The FK index is an optimisation"	Without it, deleting a parent locks the whole child table. It is correctness under load.
"VARCHAR2(100) is plenty"	100 bytes is ~33 Vietnamese characters in AL32UTF8. Say `CHAR` .
"I'll default the NOT NULL column to 0"	That is a business decision made silently. Ask.
"Rename is one statement"	And one broken caller per reference. Expand, then contract.
"The table is new, impact is zero"	Say so with `pythia impact` as evidence — then it is a fact, not a guess.

When NOT to use this skill

Changing code that reads the table →
```
pythia-write
```
/
```
pythia-package
```
.
A slow query on an existing table →
```
pythia-tune
```
(an index is still designed here once tuning asks for it).
Data fixes (
```
UPDATE
```
/
```
DELETE
```
) →
```
pythia-apply
```
; they are
```
data_dml
```
.

pythia-table

NPX Install

Tags

SKILL.md Content