I've been playing Japanese role-playing games for a long time, and I've been writing T-SQL for fifteen years. For a long time, I kept these hobbies distinctly separate. That seemed to change as a junior engineer on my team decided to ask me how to design a flexible permissions table to accommodate roles, individual overrides, inheritance, and historical changes. As I started to draw on the whiteboard, I realized I was almost reproducing the job class system from Final Fantasy V.
There is a similar challenge faced by a database engineer and a designer of JRPGs. Both have to model systems in which an entity can take on a range of different roles, retain certain functionalities from previously held roles, and combine those functionalities in complex ways during active operations. Both require rapid retrieval, sensible defaults, and an exception management system that doesn't involve core model changes. For decades, JRPG job systems have been the subject of a large-scale and long-term test of these principles. Tens of millions of players have noticed when the underlying system is failing to perform.
Final Fantasy V serves as the definitive example. Every character has a main job, a secondary ability slot, and a record of each job they have mastered. The secondary ability slot can draw from any job they have mastered. The switching of jobs is recorded. The game recalculates stats on the fly based on the current job as well as any past jobs that provide passive abilities. From a purely database standpoint, it is a clean example of a many-to-many relationship between characters and skills, linked through job mastery records, with active and inactive records controlled by a single boolean column.
The average production database typically lacks a clear rationale around attribute integration, and this is a place where the game excels. When a character has Knight as their main job and Black Magic as their second, the engine does not carry out a costly computation. Instead, it retrieves a combination that has been resolved in a previous table. Every moment of gameplay demonstrates the value of both indexing and materialized views. For those interested in how these systems are organized across the game, the complete taxonomy is available at
https://icicledisaster.com/best-jrpgs-with-job-class-systems/, which analyzes each franchise's implementation of mastery, inheritance, and stat resolution.
Tactics Ogre: Reborn takes the model a little further by adding class change fees and adding class-specific gear. From a schema level, they are adding a transactional layer. A class change is one simple operation that touches many tables. Compatibility for equipment is done via foreign key constraints instead of runtime checks. The game subtly punishes design choices that circumvent these constraints. If a character could be made to equip a class-locked weapon by some save-load exploit, the entire consistency of the combat system would be compromised. Anyone who has spent a weekend explaining the logic behind a cascading delete to a corrupted production table should get used to Tactics Ogre's strict validation logic.
A different idea that also may be worth borrowing can be found in the Bravely Default games. The asterisk system lets a character have one job active, but provides passive bonuses from other jobs. At the schema level, this is a join across two role tables that creates a new character profile on the fly. The approach is more like a database view than a stored procedure. If the underlying tables are normalized, the game can do this cheaply. Designers who shipped a system with denormalized tables for performance reasons may see the same in Bravely Default. The game opted for normalization and aggressive caching, and the result is that the gameplay is much faster.
JRPG job systems make schema decisions more obvious than most enterprise systems. If a database engineer normalizes incorrectly, a slow query is created, and someone fixes this during a performance review. When a JRPG designer normalizes incorrectly, a player can see within five minutes that their character can't obtain the abilities they want to obtain. The feedback loop is unforgiving and immediate. It forces the designer to come up with more creative solutions that will work well under heavy loads.
Migration has a similar parallel. When a JRPG releases a New Game Plus mode or a balance patch, the team has to change the structure of the saved data to fit the new schema without corrupting the player's history. Strategies such as this, including only additive changes, using default values for new columns, and legacy field isolation, work well during the database migration phase. More than once, I've pointed to the job system overhauls in Final Fantasy XIV, as design examples. The team is able to implement changes to the schema of a live service game that has millions of concurrent players, and they rarely break continuity for characters. Those who enjoy this level of execution will find the broader writing of
Icicle Disaster on high-end games in the medium worthwhile.
In the permissions table design I was making for my colleague, I ended up borrowing four separate ideas from Final Fantasy V. First, separate role definition from role assignment. Second, log each role change with a timestamp. Third, passive role inheritance from roles that are mastered is controlled by a mastery flag. Fourth, determine the permission set ahead of time rather than calculating the set each time a permission is checked. This produced a schema that in a single day could handle 15 million permission lookups with predictable latency, and a query plan that fit on a single screen.
I don't mean to overstate the rigor of this sort of cross-domain pattern matching. Designers of games and designers of databases operate under similar but not the same constraints. When a game is in production, it can rewrite its rules via a patch. On the other hand, a production database has decades worth of historical data and integrations that aren't so easily rewritable, and require many steps of coordinated downtime. While the ideas may be adapted to different environments, the constraints are also different. Anyone who assumes that a JRPG schema is a fully compliant system for production databases is is bound to be disappointed.
The value in examining these games goes beyond superficial entertainment. JRPG teams are forced to converge on repeatable patterns that survive years of stress testing due to the constraints of needing to ship a balanced, performant, and intuitive system to millions of players. Those patterns give database engineers studying them a lexicon for talking about trade-offs that is rooted in tangible instances, as opposed to designed abstractions. The reality that the applicable instances are in video games doesn't lessen their validity; it makes the discourse more enjoyable.