Лучший способ структурировать эту базу данных?

Question

На данный момент я делаю это:

gems(id, name, colour, level, effects, source)

id является первичным ключом и не является автоинкрементом.

Типичная строка данных будет выглядеть так:

id      =>   40153
name    =>   Veiled Ametrine
colour  =>   Orange
level   =>   80
effects =>   +12 sp, +10 hit
source  =>   Ametrine

(Некоторые из вас, геймеры, могут видеть, что я здесь делаю :))

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

Я думал, может быть, 3 таблицы: gem, effects, source. Которые потом имеют отношения друг к другу?

Может кто-нибудь пролить свет на это? Является ли сложный путь, как будто я действительно предлагаю путь, или я должен просто продолжать то, что я делаю?

Приветствие.

Answer 1

Мне случайно знакомо окружение, которое вы описываете (:)) Несмотря на то, что вы сами убедились, то, что вы делаете, не особенно сложно.

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

Если бы вы перешли к трем предложенным вами таблицам, вам также нужно было бы включить таблицы ссылок для объединения таблиц в пригодные для использования данные, тем более чтоне совсем уверен, как ваши различия проявляются) таблица эффектов и источника вовлечена в отношение многие-к-х: каждый драгоценный камень имеет до двух эффектов, и каждый эффект имеет до Y драгоценных камней, где он присутствует // каждый источник имеетдо Z драгоценных камней.

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

Answer 2

Я бы порекомендовал следующее:

1. Переместить все эффекты в их собственную таблицу (например, ID, Имя, Описание, Включено, ...)
2. Переместить источник в егособственная таблица (например, ID, имя, описание, включено, ...)
3. Столбец "Effects" для удаления драгоценных камней (выполняется переход к шагу 5 ниже)
4. Преобразование столбца "source" для драгоценных камнейзначение внешнего ключа, соответствующее PK из таблицы «source»
5. Добавить новую таблицу, чтобы связать один элемент gem с нулем или несколькими объектами эффектаПример: tbl_GemsEffectsLink с двумя столбцами с именами «GemID» и «EffectID», которыесами по себе являются внешними ключами обратно в таблицы сущностей, и, взятые вместе, составляютсоставной первичный ключ.Пример представления этой таблицы ссылок будет следующим: GemID EffectID 1 1 1 2 2 1 2 2 2 3

Итак, в итоге вы получите следующие таблицы:

1. самоцветы
2. эффекты
3. источник
4. gemseffectslink

Каждая таблица имеет следующие столбцы:

1. драгоценные камниid (PK)названиецветуровеньSourceid (FK)

2. эффектыid (PK)названиеописаниевключен...

3. источникid (PK)названиеописаниевключен...

4. gemseffectslinkгемид (ФК)эффект (FK)

Наконец, это предполагает, что каждый драгоценный камень может иметь ноль или более эффектов, один источник (вы можете применить NULL или NOT NULL для этого поля FK gem.sourceid) и что уровень целоезначение - это просто (то есть, не представляющее что-то более устойчивое и исчерпывающее в том смысле, что существует некоторый тип сущности «Уровень», а значение «80» в строке образца данных однозначно идентифицирует одну из этих сущностей «Уровень»).

Надеюсь, это поможет!Michael

Answer 3

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

Теперь для вашего примера яd) предложить два подхода (без синтаксических подробностей)

1) для получения опыта в реляционном проектировании, с некоторыми сложностями и подробными сведениями по каждой сущности

• gem (id, name, color_id, source_id, effect_assoc_id)
• цвет (идентификатор, имя)
• источник (идентификатор, имя)
• эффект (идентификатор, значение, nature_id)
• природа(id, name)
• effect_assoc (id, gem_id, effect_id)

2) прямо в точку, возможно, действует в зависимости от количества элементов ваших отношений

просто продолжай;)

Из твоего описания я бы пошел с # 1.

Answer 4

Вам также следует подумать, понадобится ли вам информация effects для фактического использования или только для отображения.Если это только отображение, нет ничего страшного в том, чтобы иметь его в одном столбце таблицы.Если вы должны использовать его, например, чтобы применить +12 и +10 соответственно, то я думаю, что вы должны поместить каждое вхождение этого в отдельный столбец.Соответственно, у вас должна быть отдельная таблица для effects, а затем отдельная таблица, в которой хранится информация о том, какие драгоценные камни имеют какие эффекты, может быть, gemeffects.Таблица Effects может иметь лучшее описание того, что означает "sp", может быть, минимальный и максимальный диапазоны и т. Д. Таблица GemEffects будет содержать только идентификатор драгоценного камня, значение и сам эффект.Например,

Эффекты

effect  => hit
desc    => How many hit points
minimum => 0
maximum => 100

GemEffects

id     => 40153
effect => sp
value  => 12

и

id     => 40153
effect => hit
value  => 10

Answer 5

Вопросы для себя:

1. Существует ли соотношение 1 к 1 между самоцветом, эффектами и источником?
2. Будете ли вы чаще получать эффекты, не извлекая данные из самоцвета?

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