Структура базы данных Направление и Ссылочный идентификатор относятся к другой таблице в зависимости от другого столбца - PullRequest
1 голос
/ 03 мая 2019

Работаю над небольшим доказательством концепции проекта для меня и моих друзей DnD-игры и не уверен, что мое руководство по организации базы данных является наилучшим способом.Основная идея состоит в том, чтобы собрать наборы персонажей (всю статистику для наших игроков для тех, кто не играет в dnd) для всех различных игр.Вопрос в том, что у нас есть несколько разных типов игр.Поэтому я подумал о двух способах справиться с тем фактом, что разные типы таблиц символов будут иметь разные поля.

  1. Иметь одну таблицу символов, которая в конечном итоге будет содержать дерьмовую колонку для всех различных типов.характера.(не фанат этого метода, поскольку кажется, что он загроможден)
  2. Иметь таблицу персонажей, которая имеет базовую информацию, такую ​​как владелец, имя персонажа и т. д., но также имеет game_type_id и sheet_id.Затем создайте разные таблицы (которые в конечном итоге будут группами таблиц для таких вещей, как экипировка, заклинания и т. Д., Имеют свои таблицы для каждой игры) для каждой игры, которая состоит из фактических данных персонажа.Таким образом, game_type_id будет использоваться для определения набора таблиц, на который ссылается sheet_id

Вариант 1 кажется неорганизованным при добавлении большего количества типов игр, но затем вариант 2, похоже, приведет к созданию большого количестваразные таблицы, так как добавляется больше игр, потому что на каждом листе будет базовая информационная таблица, а затем все связанные таблицы для вещей, которые кратны.

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

Ответы [ 2 ]

1 голос
/ 03 мая 2019

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

Character
CharacterId
CharacterName
Gender
-- other fields common to all characters

GanmeType
GameTypeId
GameTypeName
--other relevant fields

GameTypeAttributes
GameTypeAttributesId
GameTypeid
AttributeName

CharacterSheet
CharacterSheetId
CharacterId
GameTypeAttributesId
AttributeValueInt
AttributeValueVARCHAR
-- column for every data type you would use

В качестве примера следующий код создаст символ с именемАрья, которая связана с игрой «Большая война»

В игре «Большая война» персонаж должен иметь атрибуты Сила, выносливость и обаяние.

Затем мы устанавливаем значения Арьи для этих атрибутов

INSERT INTO Character VALUES (1,'Arya','F');
INSERT INTO GameType VALUES (1,'Big War');
INSERT INTO GameTypeAttributes VALUES (1,1,'Strength'),(2,1,'Stamina'),(3,1,'Charisma');
INSERT INTO CharacterSheet VALUES (1,1,1,10,NULL),(2,1,2,4,NULL),(3,1,3,NULL,'None whatsoever');

Затем мы можем добавить Арью в другую игру, если захотим:

INSERT INTO GameType VALUES (2,'Fuzzy Duck');
INSERT INTO GameTypeAttributes VALUES (4,2,'Stomach Strength'),(5,2,'Fearlessness'),(6,2,'Bravery');
INSERT INTO CharacterSheet VALUES (4,1,4,10,NULL),(5,1,5,4,NULL),(6,1,6,NULL,'Enourmous amounts');
0 голосов
/ 04 мая 2019

Вы должны разделить их, то есть следовать решению № 2.

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

Возможно, вы бы предпочли базу данных NoSQL, например, MongoDB (ориентированная на документы) или Neo4j (ориентированную на граф), которая позволяет представлять ваши данные по-другому. Это может упростить моделирование и поддержание информации. Но даже в этом случае вам необходимо концептуально отделить игрока от игр.

...