Нуждаете се от съвет за прост дизайн на MySQL db

Защо имате attribute масата ?

Атрибутите са колони, а не таблици.

Връзката към уебсайта не ни казва нищо.

Цялата идея на базата данни е, че се присъединявате към множеството малки таблици, както е необходимо, за всяка заявка, така че трябва да свикнете с това. Разбира се, това ви дава решетка, но кратка и сладка, без Nulls. Това, което се опитвате да направите, е да избягвате маси; отидете само с една масивна мрежа, която е пълна с нулеви стойности.

(отрязване)

Не поставяйте префикс имената на вашите атрибути (имена на колони) с името на таблицата, което е излишно. Това ще ви стане ясно, когато започнете да пишете SQL, който използва повече от една таблица:тогава можете да използвате името на таблицата или псевдоним, за да поставите префикс на всички имена на колони, които са двусмислени.

Изключението е PK, който се изобразява изцяло и се използва в тази форма, където и да е FK.

Разгледайте сайта и прочетете някои SQL въпроси.

След като направите това, по-късно можете да помислите дали искатеstrength и defense да бъдат атрибути (колони) от type; или не. И така.

Отговори на коментари 30 ноември 10

.
Отлично, разбирате данните си. правилно. Сега разбирам защо сте имали таблица с атрибути.

1. Моля, уверете се, че тези 10 примера са представителни, аз ги разглеждам отблизо.

   • Тип:Име на скъпоценен камък:Висулка Emberspark ... Или тип NeckMiscellaneous ли е?
   • Истински ItemType ли е Unique? Мисля, че не
   • Действие. Показване на „Моля, върнете се към организатор на сезона“
   • Къде са атрибутите за AttackPower и HitRating ?
     .

2. Колко различни вида артикули (от 35 000) има, ала моят пример за продуктовия клъстер. Друг начин да се зададе този въпрос е колко вариации има. Имам предвид, смислено, не 3500 елемента ÷ 8 атрибута?

3. Ще се променят ли item_attributes без освобождаване на s/w (напр. нова Inner Strength атрибут) ?

4. За артикул, какви атрибути се повтарят (повече от един); досега виждам само Action?

5. Това е игра, така че имате нужда от db, който е стегнат и много бърз, може би напълно резидентен в паметта, нали. Без нулеви стойности. Без VAR Нищо. Най-кратки типове данни. Никога не дублирайте нищо (не се повтаряйте). Доволни ли сте от битове (булеви) и вектори?

6. Трябва ли лесно да превеждате тези регулярни изрази в SQL или сте доволни от сериозна задача за всеки (т.е. след като ги накарате да работят в SQL, те са доста стабилни и след това не се забърквате с него, освен ако не откриете грешка ) (без сарказъм, сериозен въпрос) ?

   6.1 Или може би е обратното:db е резидентен на диск; зареждате го в паметта веднъж; изпълнявате регулярните изрази за това по време на игра; от време на време запис на диск. Следователно няма нужда да превеждате регулярните изрази в SQL?

Ето модел на данни за това къде се насочвам, това изобщо не е сигурно; той ще бъде модулиран от вашите отговори. За да бъде ясно:

• Шестата нормална форма е Редът се състои от първичен ключ и най-много един атрибут.

• Начертал съм (6.1), а не (6), защото вашите данни засилват убеждението ми, че имате нужда от чиста 6NF релационна база данни

• Моят Модел на данни за продуктови клъстери , по-добрият от EAV пример, е 6NF, след което отново се нормализира (не в смисъла на нормална форма) от DataType, за да се намали броят на таблиците, които вече сте виждали. (Хората от EAV обикновено избират една или няколко гигантски маси.)

• Това е направо 5NF, само с 2-те маси вдясно в 6NF.

Връзка към модела на данните за играта

Връзка към нотация IDEF1X за тези, които не са запознати със стандарта за релационно моделиране.

Отговор на редакция #2 05, 10 декември

1.1. Добре, коригирано.

1.2. Тогава IsUnique е индикатор (булев) за елемент.

1.3. Действие. Разбирам. И така, къде ще го съхранявате?

1.4. NeckMiscellaneous означава, че артикулът е и в двете категории на Neck и Misc . Това означава две отделни Item.Name=Emberspark Pendant , всеки с различна категория.

.
2. и 5. Така че имате нужда от бърз бърз резидентен db в паметта. Ето защо се опитвам да ви прекарам през линията, далеч от GridLand, в RelationalLand.
.
3. Добре, оставаме с петата нормална форма, няма нужда от 6NF или продуктовия клъстер (таблици за тип данни). Досега Values всички са цели числа.
.
4. Мога да видя допълнително:Level , RequiredLevel , IsUnique , BindsPickedUp , BindsEquipped .
.
5. Битовете са булеви { 0 | 1 }. За (релационни) проекции са необходими вектори. Ще стигнем до тях по-късно.
.
6. Добре, обяснихте, Вие не превеждате регулярни изрази в SQL. (Slog означава тежък труд)..
7. Какво е Category.ParentId? Родителска категория? Това не се е случвало досега.
.
8. Attribute.GeneratedId ?

Моля, оценете модела на данни (актуализиран). Имам още няколко колони, в допълнение към това, което имате във вашата. Ако има нещо, което не разбирате в модела на данни, задайте конкретен въпрос. Прочетохте документа за нотации, нали?

Имам Action като таблица, с ItemAction задържане на Value :
Equip: increase attack power by 28 е Action.Name =Increase attack power by и ItemAction.Value =28.