Interface AutoBeDatabaseComponentTableDesign

Concise business concept of this table. One or two sentences maximum. MUST be written in English. State the stored concept, owner, row grain, lifecycle trigger, and concept-level retained fact categories so later review agents can compare this table with similar table concepts.

Do not list columns, indexes, relation definitions, or schema constraints here. If a current/display value is derived from source rows in another table, describe that source relationship instead of implying this table stores the value.

Final table name for this table concept.

Use a plural, snake_case, prefix-aware table name that represents one stored concept. Apply the configured database prefix when one exists and avoid duplicate prefixes. The name must identify the table itself, not a column, field, relation, index, or constraint.

Examples: shopping_sales, shopping_sale_snapshots, shopping_sale_snapshot_units.

Architectural role of this table, guiding API endpoint generation.

• "primary": Core entity users manage independently (full CRUD APIs). Use when users need to create, search, or manage entities outside their parent context.
• "actor": Authenticated user type with its own identity, credentials, and auth flow. Generates auth endpoints.
• "session": Login session table belonging to exactly one actor. Append-only audit trail, managed via auth flows.
• "subsidiary": Supporting entity managed through its parent, rarely needs standalone endpoints.
• "snapshot": Point-in-time versioning record, typically append-only and read-only from user perspective.
• "material": Read-only materialized query projection. The table name must start with mv_, and normal CRUD endpoints are not generated.