I'm working with the Microsoft ADO.NET Entity Framework for a game project. Following the advice of other posters on SO, I'm considering modelling deterministic and nondeterministic data separately. The idea for this came from a discussion on multiplayer games, but it seemed to make sense in a single-player scenario as well.

Deterministic (things that aren't going to change during gameplay)

• Attributes (Strength, Agility, etc.) and their descriptions

• Skills and their descriptions and requirements

• Races, Factions, Equipment, etc.

• Base Attribute/Skill/Equipment loadouts for monsters

Nondeterministic (things that will change a lot during gameplay)

• Beings' current AttributeModifers (Potion of Might = +10 Strength), current health and mana, etc.

• Player inventory, cash, experience, level

• Player quests states

• Player FactionRelationships

...and so on.

My deterministic model would serve as a set of constants. My nondeterministic model would provide my on-the-fly operable data and would be serialized to a savegame file to maintain game state between play sessions. The data store will be an embedded SQL Compact database.

So I might want to create relations between my Attributes table (deterministic model) and my BeingAttributeModifiers table (nondeterministic model), but how do I set that up across models?

 Det model/db       Nondet model/db
 ____________       ________________________
|Attributes  |     |PlayerAttributeModifiers|
|------------|     |------------------------|
|Id          |     |Id                      |
|Name        |     |AttributeId             |
|Description |     |SourceId                |
 ------------      |Value                   |
                    ------------------------

Should I use two separate models (edmx) that transact with a single database containing both deterministic-type and nondeterministic-type tables? Or should/can I use two separate databases in one model? Or two models each with their own database?

With distinct models/dbs it seems like this will get really complicated and I'll end up fighting EF a lot, rolling my own transaction code, and generally losing out on a lot of the advantages of the framework.

I know these are vague questions, I'm just looking for a sanity check before I forge ahead any further.