Modelling deterministic and nondeterministic data separately

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 re开发者_如何学JAVAquirements

• 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.

Easiest solution today: One EDMX, one database, multiple tables in that database.

Yes your EDMX can become huge but there's hope that in the future Microsoft will provide ways to manage things better.

In my humble opinion, trying to put all of the useful data into only two tables is a recipe for pain.

The way it's worked most successfully for me in the past is to have a separate table per type of "thing." E.g. there was a weapons table with information about weapon visual representation and (visual and game) effects, another table with all of the static enemy data (this you're calling deterministic) and yet another table with all of the dynamic enemy data (which you call non-deterministic). So on and so forth.

While I had a strong motivation to treat all of the enemies "polymorphically," I didn't have any need or desire to handle weapons and enemies together; there was no overlap in functionality so it made sense to me to keep their data separate. Jamming their static bits together and jamming their dynamic bits together would just lead to a lot of useless/unimportant/error-causing data. Enemies had references into the weapons table, and weapons had references into the VFX and sound tables, each containing vastly different data from the others.

I can't authoritatively speak to your database model, but if I were to implement such a thing my first motivation would be to keep these "tables" as I'm calling them (as they were static data in some cases compiled and others loaded into my program) separate and not try to pick and choose the appropriate fields when accessing elements; that seems like a waste of energy to be honest. It's likely that the various sets of data will change, too, and it seems like things could get really hairy if you wanted to remove a field from one of the datasets that the other dataset was still using.