Полиморфизм в базах данных

Question

Я хотел бы смоделировать объект базы данных для набора игроков. Каждый игрок должен иметь:

• ряд фиксированных полей (имя, роль, ...)
• ряд переменных полей для уровней квалификации (если роль ATK, навыки должны быть stat1 и stat2; если роль DEF, навык должен быть stat3 и stat4).

Каков наилучший способ реализации такого объекта (как реляционные, так и нереляционные базы данных подходят для меня)?

Наиболее тривиальное решение, конечно, состоит в том, чтобы удерживать таблицу для каждой роли. Я также нашел this ответ, который хорош, но ему 7 лет и, возможно, устарел. Другие идеи?

---

Вот набор выборки данных:

"name": "name1" 
"role": "attack" 
"strength": 10 
"constitution": 5 

"name": "name2" 
"role": "attack" 
"strength": 7 
"constitution": 7 

"name": "name3" 
"role": "defense" 
"health": 8 
"resistence": 8 

"name": "name4" 
"role": "defense" 
"health": 10 
"resistence": 10 

"name": "name5" 
"role": "support" 
"mana": 4 
"willpower": 3 

Answer 1

ОО структура данных

Вы определили несколько классов в вашем Character населения, которые являются производными от абстрактного роли , а именно Attack, Defense и Support. Каждый вид роли имеет разные атрибуты в зависимости от класса.

Таким образом, у вас явно есть проект ООП в вашем уме и вы хотите реализовать его в базе данных. Можно использовать несколько шаблонов проектирования:

• Самый легкий, как представляется, single table inheritance помещает все поля в одну таблицу. Они используются/интерпретируются в зависимости от конкретной роли.
• class table inheritance помещает данные, относящиеся к каждой роли (и самому символу) в отдельной таблице. Для этого требуется соотношение 1: 1 между таблицей производного класса (например, Defense) и таблицей родительского класса (здесь Character). Это кажется излишним здесь
• concrete table inheritance объединяет родительские классы с наиболее производными классами, поэтому вы получите таблицу на роль, каждая из которых имеет свое собственное поле name. Опять же, это кажется излишним здесь.

Занятия или общение?

Существует еще одна дополнительная модель, которую вы могли бы рассмотреть. Это компонент, как дизайн, основанный на композиции (в схеме SQL в отношениях):

• Вы бы одну character таблицы с
• Вы бы иметь таблицу свойств id, name и role с персонажем id , a property-id (или название) и value.

Это можно посоветовать, если вы хотите быть очень гибким и изобретательным и изобретать дополнительные свойства (например, «имеет оружие A», «имеет оружие B», «силу брони» и т. Д.).Однако, если вы намерены придерживаться относительно близких к текущим свойствам, это снова будет излишним.

No-SQL

Если вы хотите, чтобы рассмотреть неофициальный реляционную базу данных, как правило, No-SQL database, то вы могли бы рассмотреть базы данных на основе документов, которые идеально подходят для обработки структуры, подобные одной таблицы наследования.

Если вы выберете, однако, конструкцию компонентов, то также можно выбрать магазины с ключевыми значениями, но вам все равно придется собирать куски. Это стоимость дополнительной гибкости ;-)

Вы сказали, что полиморфизм?

Полиморфизм скорее зависит от поведения, связанного с классом, а не от данных, описывающих объекты. Поскольку здесь нет вопросов о поведении, я предполагаю, что вы имели в виду обработку данных разных типов (так что это больше о классах). Дайте мне знать, если я ошибаюсь в этом вопросе.

Однако вы должны позволить полиморфизм в этом вопросе, потому что это может помочь другим людям, которые менее осведомлены о терминологии ООП найти решения подобных проблем