Советы по моей базе данных Deck Builder

Я работаю над создателем колоды для онлайн-карточной игры (вроде как Heartstone), и я ищу советы о том, как я должен обрабатывать свою базу данных.Советы по моей базе данных Deck Builder

Резюмировать это быстро: каждая карта может быть общая/необычная/редкая/легендарная/бесконечная.

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

card -> id, name, class, type, rarity (VARCHAR), cost, attack, defense

Или я должен создать две таблицы, одна называется карточки с редкости (INT) и другую таблицу под названием редкость, где я перечисляю все редкости и использовать их идентификатор в моих карт таблицы как это ?

card -> id, name, class, type, rarity (INT), cost, attack, defense 
rarity -> id, name

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

Спасибо за чтение :)

источник

2016-12-22 Tokipudi

считают, что плоская структура быстрее, и ваш второй вариант не действительно что-то делать, идти первым.

Тем не менее, вы можете попробовать:

card -> id, name, class, type, cost, attack, defense 
rarity -> id, name 
Card_rarity --> card_id, rarity_id

источник

2016-12-22 14:00:35 JohnHC

Итак, ваше решение будет быстрее, чем второе, указанное мной, хотя есть дополнительная вкладка? Кроме того, существуют и другие факторы (такие как класс, тип существ и т. Д.), Чтобы это означало, что у меня было бы еще 2 таблицы для каждого фактора? – Tokipudi

@Tokipudi Нет, первая, плоская структура быстрее. Нормализованный подход лучше подходит для целостности данных. Взгляните на [this] (http://sqlmag.com/database-performance-tuning/sql-design-why-you-need-database-normalization), чтобы по какой-то причине нормализовать – JohnHC

Согласно этой статье (и связанный с ним наверху), хотя квартира быстрее, она недостаточно «надежна» и не должна использоваться часто. Поэтому я буду больше смотреть на то, как вы описали, спасибо. – Tokipudi

Вы можете пойти на полпути и настройка редкости как CHAR (3), а затем использовать abreviations: COM UNC RAR LEG INF

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

LOOKUP_ID CHAR(8)  -- PK class,type,rarity 
CODE CHAR(3)   -- PK key code 
LANG VARCHAR(10)  -- PK e.g. en-US 
LABEL VARCHAR(255) -- Short label for UI components 
FULLTEXT VARCHAR(255) -- Full description for help etc...

Примеров данных

RARITY COM  en Common Common card 
RARITY COM  fr Commune Carte commune 
CLASS  COM  en Combat Combat has both defence and offence stats 
CLASS  COM  fr Combat Les cartes combat possèdent des stats défence et offence

источник

2016-12-22 14:01:19 Stavr00

Я действительно не понимаю, что вы говорите (извините, прошло некоторое время с тех пор, как у меня был sql в школе ^^) Я понимаю, что это в основном так же, как я описал, но с сокращениями вместо INT и что ' LANG' позволяет мне выбирать язык, который я хочу. Но я не думаю, что я все понимаю из этого второго стола. Что такое 'LOOKUP_ID' и' CODE' exatcly? Кроме того, могу ли я использовать нормализованный способ @JohnHC, описанный и обрабатывающий многоязычную часть позже? – Tokipudi

Скажите, что у вас есть класс = COMbat и редкость = COMmon. Вы должны различать их в таблице «словаря» – Stavr00

О, ладно. Таким образом, это будет одна таблица с каждой редкостью/классами/типами на каждом языке, который мне нужен. Это означает, что в таблице ** ** ** я должен создать каждую карту дважды с помощью столбца LANG, если я хочу, чтобы они были на французском и английском языках? Снова, извините, если мои вопросы немного глупы, я никогда не делал этого раньше. – Tokipudi

Советы по моей базе данных Deck Builder

ответ

Смежные вопросы