как правильнее спроектировать таблицу ?

[Forever]

Есть таблица для навыков героев из игры.

id | hero_id | name | .....

У каждого навыка есть метод использования.

Он может быть , допустим, направляемым на точку, направляемым на другого героя, ненаправленным, переключаемым, пассивным и тд. Но также может быть и одновременно нескольких типов, например
переключаемым/ ненаправленным /пассивным. Максимум три метода у одного навыка.

Мне пришло в голову только сделать три поля, типа method_1 , method_2...,
И в итоге будет что-то вроде

id 1
hero_id 153
name fireball
method_1 ненаправленный
method_2 пассивный
method_3 переключаемый

проблема в том, что если у навыка всего один метод, то два остальных поля будут пустовать.
Плюс избыточность, т.к. данные будут повторяться у разных строк

Собственно, два вопроса:

1) наличие избыточностиь и пустых полей - это очень плохо?

2) как быть, если очень плохо?

 

[WMix]

решений множество, "метод" может быть поле типа set если набор ограниченый, может быть таблицей описаний если набор не ограниченый, твое решение также не лишено смысла, таким же способом каждый из типов может быть отдельным столбиком со значением да/нет 1/0 или null/not null, а сила этого метода к примеру.

 

[Вурдалак]

Если ты пишешь, что у каждого героя есть набор навыков и для каждого героя ты описываешь свойства этих навыков, то возникает вопрос: а что, у одного героя может быть направленный fireball, а у другого — нет? Если нет, то это проблема. В системе могут появляться противоречия, когда fireball ведёт себя по-разному, хотя обязан одинаково. Тут можно погуглить на тему нормальных форм, по крайней мере сможешь потом многозначительно упоминать этот термин.
Ещё один момент: почему свойства fireball'а в принципе лежат в БД, они что, как-то динамически меняются?

На твой вопрос ответить однозначно невозможно, всё очень зависит от требований. Иногда избыточность — это нормально, иногда — нет. Я могу допустить, к примеру, ситуацию, когда я бы тупо записал эти навыки в JSON-поле MySQL в таблице героев: ["fireball", "twisting nether", "avada kedavra"], а сами свойства навыков держал бы в коде. Или, к примеру, список навыков был бы в отдельной таблице, а с помощью многие-ко-многим я бы делал связь «герой <-> навыки».

 

[Forever]

решений множество, "метод" может быть поле типа set если набор ограниченый, может быть таблицей описаний если набор не ограниченый, твое решение также не лишено смысла, таким же способом каждый из типов может быть отдельным столбиком со значением да/нет 1/0 или null/not null, а сила этого метода к примеру.

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

А как могла бы выглядеть таблица описаний?

 

[Forever]

Если ты пишешь, что у каждого героя есть набор навыков и для каждого героя ты описываешь свойства этих навыков, то возникает вопрос: а что, у одного героя может быть направленный fireball, а у другого — нет? Если нет, то это проблема

У каждого героя набор навыков уникальный, и названия, и свойства навыков тоже. Игра Дота 2, может знаешь)

Ещё один момент: почему свойства fireball'а в принципе лежат в БД, они что, как-то динамически меняются?

Да, периодически выходят обновления, и навыки корректируются разработчиками. Где-то фаерболу повысят урон, где-то замедлению понизят длительность и тд

В таблице навыков будет примерно 600 записей. В принципе, не так уж много. И она практически не растет. Можно ли в таком случае пожертвовать нормализацией?

 

[Adelf]

@Forever, ты все-таки расскажи, что именно пытаешься реализовать. Есть вероятность, что таблица тебе вообще будет не нужна.

 

[Вурдалак]

Да, периодически выходят обновления, и навыки корректируются разработчиками. Где-то фаерболу повысят урон, где-то замедлению понизят длительность и тд

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

 

[Forever]

@Forever, ты все-таки расскажи, что именно пытаешься реализовать. Есть вероятность, что таблица тебе вообще будет не нужна.

http://dota2.gamepedia.com/Kunkka#Tidebringer

посмотрите там, у способностей есть описание. Тип, на кого можно применять. Работают ли через сопротивление к магии, уровни эффективности, сколько энергии требуется и все такое

 

[Вурдалак]

http://dota2.gamepedia.com/Kunkka#Tidebringer

посмотрите там, у способностей есть описание. Тип, на кого можно применять. Работают ли через сопротивление к магии, уровни эффективности, сколько энергии требуется и все такое

Ну так если в Dota 2 что-то меняют в плане способностей, то и апдейт скачивается, разве нет? Или прямо без апдейта в следующем же матче ты такой херак — а способность понерфили? Поменялась модель игры — скачиваешь новый клиент, который в курсе про эти способности.

С веб-сайтами ещё проще, т.к. код обновлять нужно только на сервере.

 

[WMix]

А как могла бы выглядеть таблица описаний?

навыки героев
1, 153, 42

навыки
42, 'firebal'

методы навыка
1, 42, 'ненаправленный'
2, 42, 'пассивный'
3, 42, 'переключаемый'

 

[Adelf]

Все более-менее вменяемые базы по доте - это вики-движки. Там у 110+ героев одинаковых скиллов(от 4 и больше на героя) - две-три штуки максимум. Все остальные разные. Причем настолько разные, что построить какую-то грамотную модель описывающую их - ну крайне сложная задача. И должна быть веская причина это делать.

 

[AnrDaemon]

Если же отвечать на вопрос отвлечённо, то гуглим слова "нормализация базы данных, первая и вторая нормальные формы".