Będę łagodnie nie zgadzać się ze wszystkimi i powiem, że podejście relacyjne jest tutaj rozsądne. Interesujące jest to, że przedmioty mogą mieć wiele ról. Głównym problemem będzie to, że odwzorowanie między tym układem relacyjnym a układem OO w kodzie nie będzie wydawać się „naturalne”, ale myślę, że po stronie bazy danych wiele ról można wyrazić w czysty sposób (bez dziwnego kodowania lub redundancji, po prostu łączy) .
Pierwszą rzeczą, którą należy podjąć, jest to, jaka część danych jest specyficzna dla elementu i ile jest dzielona przez wszystkie elementy danego typu.
Oto co bym zrobił, gdyby wszystkie dane były specyficzne dla elementu:
// ITEMS table: attributes common to all items
item_id | name | owner | location | sprite_id | ...
1 | Light Saber | 14 (Tchalvek) | 381 (Tchalvek house) | 5663 | ...
// WEAPONS table: attributes for items that are weapons
item_id | damage | damage_type | durability | ...
1 | 5 | sharp | 13 | ...
// LIGHTING table: attributes for items that serve as lights
item_id | radius | brightness | duration | ...
1 | 3 meters | 50 | 8 hours | ...
W tym projekcie każdy element znajduje się w tabeli Przedmioty, wraz z atrybutami, które mają wszystkie (lub większość) przedmiotów. Każda dodatkowa rola, jaką może odgrywać przedmiot, to osobny stół.
Jeśli chcesz użyć go jako broni, poszukaj go w tabeli broni. Jeśli tam jest, to nadaje się jako broń. Jeśli go nie ma, nie można go użyć jako broni. Istnienie zapisu mówi ci, czy to broń. A jeśli tam jest, przechowywane są tam wszystkie atrybuty specyficzne dla broni. Ponieważ te atrybuty są przechowywane bezpośrednio zamiast w jakiejś zakodowanej formie, będziesz mógł wykonywać z nimi zapytania / filtry. (Na przykład, na stronie metryki gry możesz chcieć agregować graczy według typu obrażeń od broni, a możesz to zrobić z niektórymi złączeniami i grupami według typu obrażeń).
Przedmiot może mieć wiele ról i może istnieć w więcej niż jednym stole dla poszczególnych ról (w tym przykładzie zarówno broń, jak i oświetlenie).
Jeśli jest to po prostu boolean typu „czy można to utrzymać”, umieściłbym to w tabeli Przedmioty. Może warto tam umieścić w pamięci podręcznej „czy to broń” itp., Abyś nie musiał sprawdzać broni i innych tabel ról. Dodaje jednak nadmiarowość, dlatego należy zachować ostrożność, aby zachować synchronizację.
Zalecenie Ari, aby mieć dodatkową tabelę według typu, może być również zastosowane w tym podejściu, jeśli niektóre dane nie będą się różnić dla poszczególnych pozycji. Na przykład, jeśli obrażenia od broni nie różnią się w zależności od przedmiotu, ale role wciąż różnią się w zależności od przedmiotu, możesz podzielić dzielone atrybuty broni na tabelę:
// WEAPONS table: attributes for items that are weapons
item_id | durability | weapon_type
1 | 13 | light_saber
// WEAPONTYPES table: attributes for classes of weapons
weapon_type_id | damage | damage_type
light_saber | 5 | energy
Innym podejściem byłoby, gdyby role odgrywane przez przedmioty nie różniły się w zależności od przedmiotu, ale tylko od rodzaju przedmiotu. W takim przypadku umieścisz item_type w tabeli Items i możesz przechowywać właściwości takie jak „czy to broń” i „czy można ją trzymać” oraz „czy to światło” w tabeli ItemTypes. W tym przykładzie sprawiam, że nazwy przedmiotów nie różnią się w zależności od przedmiotu:
// ITEMS table: attributes per item
item_id | item_type | owner | location
1 | light_saber | 14 (Tchalvek) | 381 (Tchalvek house)
// ITEMTYPES table: attributes shared by all items of a type
item_type | name | sprite_id | is_holdable | is_weapon | is_light
light_saber | Light Saber | 5663 | true | true | true
// WEAPONTYPES table: attributes for item types that are also weapons
item_type | damage | damage_type
light_saber | 5 | energy
Jest prawdopodobne, że typy przedmiotów i typy broni nie zmieniają się w trakcie gry, więc możesz po prostu załadować te tabele do pamięci raz i wyszukać te atrybuty w tabeli skrótów zamiast z łączeniem z bazą danych.