# Database Schema Layout (`game`)

This project uses multiple PostgreSQL schemas to keep domain data separated and maintainable.

## Search Path

Configured on database level:

```sql
ALTER DATABASE game SET search_path = world, economy, progression, gameplay, resources, system, public;
```

So unqualified table names still resolve in this order.

---

## Schemas

### `world`
Map/world topology and placements.

- `server_maps`
- `server_map_flags`
- `map_portals`
- `map_npcs`
- `map_monsters`
- `map_teleporters`

### `economy`
Shops, drops, and loot containers.

- `shops`
- `shop_items`
- `shop_skills`
- `item_boxes`
- `item_box_items`
- `drops`

### `progression`
Questing and recipe progression data.

- `recipes`
- `recipe_items`
- `quests`
- `quest_objectives`
- `quest_prizes`
- `quest_npcs`
- `tutorials`

### `gameplay`
Combat/gameplay mechanics and event configs.

- `skills`
- `skill_bcards`
- `skill_combos`
- `minigame_config`
- `minigame_scores_holders`
- `global_minigame_config`
- `gameevent_instant_battle_configs`

### `resources`
Raw synced file resources (DB-first support).

- `resource_files`

### `system`
System-level metadata.

- `__EFMigrationsHistory`

---

## Notes

- Keep new feature tables in the matching domain schema, **not** in `public`.
- If you add EF migrations, ensure schema-qualified table mapping is explicit.
- DB-first runtime loaders depend on these tables being present and populated.