Моделирование детерминированных и недетерминированных данных отдельно

Question

Я работаю с Microsoft ADO.NET Entity Framework для игрового проекта. Следуя советам других авторов по SO, я рассматриваю моделирование детерминированных и недетерминированных данных отдельно. Идея для этого возникла из обсуждения многопользовательских игр, но, похоже, это имело смысл и в сценарии с одним игроком.

Детерминированный (вещи, которые не изменятся во время игры)

• Атрибуты (Сила, Ловкость и т. Д.) и их описания

• Навыки и их описания и Требования

• Расы, фракции, снаряжение и т. Д.

• Базовый Атрибут / Умение / Оборудование разгрузка для монстров

Недетерминированный (вещи, которые сильно изменятся во время игры)

• Текущие атрибуты существа (Зелье могущества = +10 к силе), текущее здоровье и мана и т. Д.

• Инвентарь игрока, деньги, опыт, уровень

• Состояния квестов игрока

• Фракция игрокаОтношения

... и так далее.

Моя детерминированная модель будет служить набором констант. Моя недетерминированная модель предоставляла бы мои оперативные данные на лету и была бы сериализована в файл сохраненной игры, чтобы поддерживать состояние игры между сеансами игры. Хранилище данных будет встроенной базой данных SQL Compact.

Так что я мог бы захотеть создать отношения между моей таблицей Attributes (детерминированная модель) и моей таблицей BeingAttributeModifiers (недетерминированная модель), но как мне установить это для разных моделей?

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

Должен ли я использовать две отдельные модели (edmx), которые работают с одной базой данных, содержащей таблицы как детерминированного, так и недетерминированного типа? Или я должен / могу использовать две отдельные базы данных в одной модели? Или две модели, каждая со своей базой данных?

С отдельными моделями / базами данных кажется, что это будет действительно сложно, и я в конечном итоге буду много бороться с EF, раскручивая свой собственный код транзакции и вообще теряя многие преимущества инфраструктуры.

Я знаю, что это смутные вопросы, я просто ищу проверку работоспособности, прежде чем двигаться дальше.

Answer 1

Самое простое решение на сегодняшний день: одна EDMX, одна база данных, несколько таблиц в этой базе данных.

Да, ваш EDMX может стать огромным, но есть надежда, что в будущем Microsoft предоставит способы лучше управлять всем.

Answer 2

По моему скромному мнению, попытка поместить все полезные данные только в две таблицы - это рецепт боли.

Способ, которым я работал наиболее успешно в прошлом, - это иметь отдельную таблицу для каждого.тип "вещь".Например, была таблица оружия с информацией о визуальном представлении оружия и (визуальных и игровых) эффектах, другая таблица со всеми статическими данными противника (это вы называете детерминированными) и еще одна таблица со всеми динамическими данными противника (которыеты называешь недетерминированным).И так далее, и так далее.

Хотя у меня была сильная мотивация относиться ко всем врагам «полиморфно», у меня не было никакой необходимости или желания обращаться с оружием и врагами вместе;в функциональности не было совпадений, поэтому для меня имело смысл хранить их данные отдельно.Сжатие их статических битов вместе и слияние динамических битов просто приведет к большому количеству бесполезных / неважных / вызывающих ошибки данных.У врагов были ссылки на таблицу оружия, а на оружие - ссылки на VFX и звуковые таблицы, каждая из которых содержала данные, совершенно отличные от других.

Я не могу достоверно говорить с вашей моделью базы данных, но если бы яреализовать такую ​​вещь, моей первой мотивацией было бы сохранить эти «таблицы», как я их называю (так как в некоторых случаях они были статическими данными, скомпилированными, а другие загружены в мою программу), и не пытаться выбирать и выбирать соответствующие поля, когдадоступ к элементам;честно говоря, это пустая трата энергии.Вполне вероятно, что различные наборы данных также изменятся, и кажется, что все может стать очень проблематичным, если вы захотите удалить поле из одного из наборов данных, которые другой набор данных все еще использовал.