entity framework - Modelling deterministic and nondeterministic data separately -

I'm working with Microsoft ADO.NET Entity Framework for a game project. After consulting the other posters on the SO, I am considering modeling and ethical data separately. The idea for this came from discussions on multiplayer games, but it was also understood in a single-player scenario.

Determination (things not changing during gameplay)

Properties and their descriptions and requirements

< Li>

Base attribute / skill / device loadout for monsters

Surety (Things that will be very much during gameplay Something will change)

• Beings' current attribute modifiers (current condition = 10 power), current health and mind, etc.

• Player inventory, cash, experience, level

• Player quests states

• < P> Player FactionRelationships

... and so on.

My deterministic model will work as a set of constants. My ethical model will provide my on-the-fly operational data and will be sorted in a saved file to maintain the game state between game sessions. The data store will be an embedded SQL compact database.

So I want to create a relationship between my property table (deterministic model) and the person who made me (for example), but how can I set it up in all models?

 Det model / db docket model / db ____________ ________________________ | Features | | PlayerAttributeModifiers | | ------------ | | ------------------------ | | ID | | ID | | Name | | AttributeId | | Details | | | SourceID | ------------ | Price | ------------------------ 

Should I use two different models (ADMX) with a database Behaves in which both deterministic-type and ethical-type tables? Or can I use two separate databases in a single model? Or two models each with their database?

With different models / DBS it seems that this will really be complicated and I will do much damage to the EF, roll my transaction code, and generally have many advantages of the structure.

I know that these are unclear questions, I am just looking for a prudent inquiry before proceeding any further.

The easiest solution today: an EDMX, a database, several tables in that database.

Yes, your ADMX may be big, but hopefully in the future Microsoft will provide the route to better manage things better.