Schema Architect Protocol

This skill transforms raw business requirements into a robust, normalized, and scalable database schema. It avoids common anti-patterns like "God Tables" or EAV (Entity-Attribute-Value) abuse.

Core assumption: A good schema must be extensible, maintainable, and explicitly document your design choices.

1. Requirement Analysis & Normalization Phase

Before writing any SQL, analyze the request:

• Identify Entities & Relationships: What are the root domains? (e.g. Users, Orders, Products). What are the cardinalities?
• Normalization Strategy (1NF → 3NF → BCNF):
  • Ensure data is logically divided.
  • Stop at 3NF for most OLTP systems. Denormalize ONLY if there is a documented performance optimization justification.

2. Anti-Pattern Check

Scan your intended design against common pitfalls:

• ❌ God Table: Does one table have >30 columns handling multiple disconnected responsibilities (e.g., Users having billing, shipping, and auth info in one huge table)? → Split them!
• ❌ EAV (Entity-Attribute-Value) Abuse: Are you using EAV patterns instead of JSONB or proper typed tables? → Rework to standard models where possible!