factions

Reference-data table for faction definitions under each race

SQL Core Data Reference

factions

Purpose

Stores faction definitions for each race. Factions are the bridge between top-level race identity and the canonical unit library used by imports, army construction, filtering, and reporting.

Hierarchy position

race
 └── factions
      └── units

Columns

Column	Type	Null	Notes
`id`	int unsigned	No	Primary key
`name`	varchar(200)	No	Faction name
`race_id`	int unsigned	No	Parent race
`created_at`	datetime	No	Creation timestamp
`updated_at`	datetime	No	Last update timestamp
`deleted_at`	datetime	Yes	Soft delete marker

Keys and indexes

PRIMARY KEY (id)
idx_factions_race_id (race_id)
idx_factions_deleted_at (deleted_at)

Foreign keys

fk_factions_race: factions.race_id → race.id

Relationships

Relationship	Type	Notes
`factions.race_id → race.id`	Many-to-one	Faction belongs to one race
`units.faction_id → factions.id`	One-to-many	Faction owns canonical unit definitions
`army_lists.faction_id → factions.id`	One-to-many	Army lists may reference faction directly

Used by

Army creation and update validation
Import commit flows
Meta endpoints that return factions by race
Stats and usage reporting by faction

Design notes

Soft delete is supported
Current schema does not enforce unique faction names within a race
Application logic often assumes faction belongs to exactly one race

Risks

Duplicate faction names can exist unless prevented outside the DB
Changing faction names can affect import expectations and legacy text storage
Soft-deleted factions require consistent filtering in all queries

Recommended future improvements

Add uniqueness constraint such as (race_id, name) if desired
Document soft delete semantics clearly for admin tooling
Consider storing a normalized name if import matching expands