Förslag på modellering

Hej, jag har tänkt bygga en databas som på ett ungefär ska likna en mmorpg databas som sparar information om personen samt deras gubbe på en server. Absolut ingenting komplext utan det ska vara väldigt "basic".

Än så länge har jag kommit på 3 entiteter men letar helst efter en 4 och just nu står det still. Dessa ska bli tabeller hade jag tänkt.

Användare -> (namn, email, lösen, användarens_id, registrerings datum )

Karaktär -> (karaktärsnamn, level, ras, klass, karaktärs_id)

Server -> (ej färdig)

förhållanden mellan dessa hade jag tänkt vara : 1:N mellan användare - karaktär / N:M mellan karaktär - Server. Visst måste detta fungera?, Tycker ni modellen fungerar? Om någon har ett tips på en fjärde tabell kom gärna med förslag,

T

Några meh förslag, var ett tag sen jag höll på med ER diagram:

värld(värld_id,värld_typ,....) en server kan ha flera instanser av världar, en värld kan ha flera karaktärer, saker, miljöer, ....

sak(sak_id,sak_typ,material_typ...) en sak kan bestå av en eller flera material_typer, användas av en/flera pc's/npcs etc etc

subklasser till karaktär
npc(hostilitet_gentemot_pcs) ...
pc(....) ...

Rustning(hjälm, vapen, .....)

Och ditt ER-diagram är annars korrekt.

Tack för alla svar, är i princip klar! Är det någon som har någon ide på hur man kan koppla så att man ska kunna se att en karaktär har mött ett monster? Visst borde det fungera att bara koppla in monsterID i karaktärs tabellen?

T

Nej.

Hur hanterar du i sådana fall att en spelare kan ha mött ett flertal monster? Gör du som du tänkte kommer det att fallera miserabelt, eftersom du då kommer behöva skapa ett nytt attribut för varje monster man mött, alternativt skapa dubletter av spelarna med en rad per mött monster. Bägge dessa approacher är ur modelleringssynpunkt helt förkastliga och kommer ställa till en hel del trassel för dej längre fram.

Ett betydligt bättre sätt att tackla problemet på är ju att skapa en ny tabell, kalla den till exempel "monster_encounters". I denna tabell kan du ju ha spelarid och monsterid som tillsammans får utgöra primärnyckel i tabellen. I denna tabell sparas även data om när och var mötet skedde om nu det är intressant med.

I och med att monsterid och spelarid tillsammans bildar primärnyckel finns det ingen möjlighet för samma spelare att kunna möta samma monster två gånger, modellen sätter stopp för det.

Den extra tabellen kommer göra dina SQL-er betydligt enklare att skriva med för den delen.

Aha okej, så jag kan t.ex ha karaktärsID, monsterID och eventuellt zonID för att visa var mötet skedde. Jag lägger ej till dessa som nycklar va? Eftersom jag redan har karaktärsID från karaktärs tabellen. Dom anges alltså som sekundära nycklar , eller har jag fel?

Det beror ju på hur du vill att databasen ska funka. Om det endast ska vara möjligt för en spelare att möta ett och samma monster endast en gång så är det ju lämpligast att ha spelarid i kombination med monsterid som primärnyckel.

Sitter begränsningen i "zonen" så har du ju lämpligen spelarid,monsterid och zonid som PN.

Ur SQL-sammanhang sedan kan det ju även vara värt att sätta en räknare som PN i mötestabellen, men sätta ett unique index på spelarid och monsterid så kommer det inte bli så joxiga joinar för dej sedan, samtidigt som du är garanterad att en spelare aldrig kommer att kunna möta samma monster mer än en gång.