Appropriate data types for each column (no stringly-typed data)

Monetary values stored as FLOAT lose cents through floating-point rounding — a $29.99 price becomes $29.989999... in arithmetic, producing billing discrepancies. Timestamps stored as VARCHAR cannot be range-queried or timezone-converted by the database. Enums stored as unbounded TEXT accept any string value, so typos like 'actve' or 'CANCELED' silently enter the database and bypass all application-level validation. These are not hypothetical: AI-generated schemas routinely default to TEXT for everything and FLOAT for any numeric value. ISO 25010 functional-correctness penalizes these because the database cannot enforce domain constraints it was not given.

Fix type mismatches one column at a time using migration ALTER COLUMN ... TYPE. Monetary columns must use DECIMAL/NUMERIC or integer cents. Enum columns must use a Postgres ENUM type or a CHECK constraint.

-- Monetary: DECIMAL not FLOAT
ALTER TABLE orders
  ALTER COLUMN total TYPE DECIMAL(12, 2);

-- Enum: add CHECK constraint
ALTER TABLE subscriptions
  ADD CONSTRAINT chk_status
  CHECK (status IN ('active', 'canceled', 'past_due', 'trialing'));

-- Timestamp: convert VARCHAR to TIMESTAMPTZ
ALTER TABLE users
  ALTER COLUMN created_at TYPE TIMESTAMPTZ USING created_at::TIMESTAMPTZ;

model Order {
  total  Decimal @db.Decimal(12, 2)  // not Float
  status OrderStatus                 // enum, not String
}
enum OrderStatus { active canceled past_due trialing }