Esquema canônico da base de dados

O esquema canônico da base de dados define a estrutura oficial usada pelo FootSim para representar o mundo do jogo. Ele inclui tabelas, campos, relações, migrations, índices e regras estruturais que sustentam jogadores, clubes, competições, partidas, contratos, finanças, scouting, táticas, histórico, managers, árbitros e demais sistemas.

O núcleo do schema já sustenta o jogo atual e permite que carreiras funcionem sobre SQLite, migrations versionadas e tabelas de runtime. Porém, este item ainda deve permanecer em desenvolvimento porque há pontos reais de consolidação: migrations precisam estar sempre registradas e aplicadas na ordem correta, a documentação precisa refletir o schema real, e ainda existe desalinhamento entre algumas tabelas do banco, models Rust, queries e docs. Portanto, o schema é funcional, mas ainda não deve ser tratado como totalmente consolidado.

Escopo incluído

• Estrutura principal do banco SQLite
• Tabelas canônicas do jogo
• Migrations versionadas
• Registro e aplicação de migrations
• Índices importantes
• Chaves estrangeiras quando aplicável
• Relações entre entidades principais
• Tabelas de dados base
• Tabelas de runtime da carreira
• Tabelas de histórico
• Tabelas de competições
• Tabelas de jogadores
• Tabelas de clubes
• Tabelas de managers
• Tabelas de árbitros quando aplicável
• Tabelas de partidas
• Tabelas de transferências
• Tabelas de contratos
• Tabelas de tática
• Tabelas de scouting
• Tabelas financeiras
• Tabelas de match engine v2 quando aplicável
• Compatibilidade básica com saves
• Evolução incremental do schema
• Alinhamento progressivo entre schema, models, queries e documentação

Fora de escopo

• Documentação pública completa para modders
• Editor visual de schema
• Alteração livre do schema por mods
• Banco online/multiplayer
• Sincronização em nuvem
• Suporte a múltiplos bancos relacionais
• Migração automática perfeita entre qualquer versão antiga
• Garantia de que todos os models já refletem todos os campos do banco
• Garantia de que toda documentação esteja sempre atualizada no mesmo instante da migration
• Sistema externo de ORM completo
• Permitir que datapacks alterem arbitrariamente o schema
• Considerar o schema totalmente fechado enquanto migrations, docs e models ainda tiverem drift

Critérios de conclusão

• O jogo possui um schema central funcional.
• Entidades principais são representadas no banco.
• Migrations permitem evoluir a base de forma controlada.
• Todas as migrations existentes estão registradas e aplicadas corretamente.
• O schema sustenta saves de carreira.
• O schema sustenta o banco mestre.
• O banco permite relações entre jogadores, clubes, competições e partidas.
• O schema é suficientemente estável para suportar o core do jogo.
• Novos sistemas podem adicionar migrations sem reescrever a base.
• Relações críticas têm integridade adequada quando possível.
• O esquema canônico é usado como base para editor, importação, datapacks e saves.
• A documentação principal do banco deixa de citar tabelas removidas ou caminhos incorretos.
• O alinhamento entre schema, models, queries e docs é bom o bastante para evitar confusão estrutural.