Het is de eerste keer dat ik normalisatie moet toepassen en er zullen dus hoogstwaarschijnlijk hier en daar fouten zijn, neem ik aan, maar kritiek is meer dan welkom =)
*nickname = spelersnaam
*guid = unieke id, per computer, dus meerde nicknames kunnen dezelfde guid hebben
*cl_id wordt toegewezen bij het joinen van een server
COMBINATIE
id [PRIMARY KEY auto_increment]
nicknameID
guidID
INFO
id [PRIMARY KEY auto_increment]
cl_id [???]
TEAM
cl_id [???]
team
kills
deaths
geen indexen: er worden telkens nieuwe records toegevoegd/geupdate | vandaar die Primary keys
In de laatste tabel (team), kan cl_id helaas een NULL retourneren, niet alle records zijn dus uniek, en het wordt daarenboven telkens geupdated/toegevoegd, dus weet ik er weinig raad mee
zou welk gek zijn mocht ik het correct hebben, maar waarschijnlijk vindt er gewoon niemand (genoeg) tijd om hiermee bezig te zijn, mijn planen te begrijpen
(ben dus nu beetje bij beetje beginnen bekijken hoe ik mijn gegevens zou kunnen opslaan - maar wacht nog af voor mogelijke veranderingen in mijn db moht ik er iets fout hebben gedaan)
wat me ten eerste opvalt is je inconsistente naamgeving (NL/EN). Ik zal me alleen iets meer moeten verdiepen in je bedoelingen wil ik het begrijpen. Waar is dit datamodel voor bedoeld? waar moet het je van kunnen voorzien en voor wat voor applicatie is het?
Ik heb een server draaien van een first shooting player spelleke.
Deze server schrijft allerlei gegevens tijdens de matchen in een .txt bestandje waaruit ik allerlei gegevens ophaal (later met cronjob)
daaruit haal ik dus de volgende gegevens:
(kzal ze in het engels opnoemen):
nickname (kan veranderd worden, maar mogen geen dubbele tegelijkertijd zijn)
client id [cl_id] (id van de speler binnen de speler op het ogenblik van de match*)
guid (uniek per person/MAC adres)
team (2 mogelijkheden, of anders offline)
kills
deaths
* ik heb 'cl_id' nodig om 'team' te kunnen bepalen, om dan te kunnen zien of er geen "teamkills" zijn om die dan van de 'kills' te kunnen aftrekken
Mijn opzet nu is dus zo goed mogelijke db te maken waarmee ik al die gegevens in een tabel kan printen, een soort van een statistieken pagina
die gameserver (wolfenstein: enemy territory)* is zo geconfigureerd, kan ik er niets aan doen =/
wat bedoel je met je laatste zin/vraag?
?
Onbekende gebruiker
09-04-2008 06:57
Eduard schreef op 08.04.2008 23:41
wat bedoel je met je laatste zin/vraag?
Hij bedoelt waarschijnlijk: Waarom de game het exporteert naar een .txt bestand. Welk ander programma dan de game zelf maakt gebruik van dat .txt bestand?
Je naamgeving kan inderdaad beter. We kunnen nu niet uit de namen van je variabelen opmaken waar ze over gaan. Wat is bijv. guid? En waarom gebruik je een combinatietabel? Is de relatie players <-> guids van het type veel op veel?
Welk ander programma dan de game zelf maakt gebruik van dat .txt bestand?
die text bestandje dient eigenlijk enkel ter controle, mocht je iets willen gaan opzoeken als er iets niet zou kloppen, dus amper 1% van de mensen gebruiken het, en mijn opzet was om er een statistiek van te maken
@Jan:
een guid is een 32 lange letter/cijfer id dat uniek is per MAC Adres, dus als je instaat ben tom je mac adres te veranderen, dan wordt je een andere guid toegewezen
die combinatie tabel heb ik eigenlijk bkomen tijdens het normaliseren, dacht dat het zo moest, maar oorspronkelijk, voordat ik het normaliseren nog begon te leren, toen had ik guid nog samen met de nickname
als ze guid, nickname samen ouden zijn, dan zou guid meermaals voorkomen, dus mischien dat ik daarom die 2 apart gezet heb, dus denk ik dat het nu is van het type veel op veel ja
mijn doel is dus alle guids samen met de bijbehorende nicknames weer te geven; maar aangezien een guid aan meerdere nicknames toegekend kan worden, wil ik enkel het laatst toegekende nickname echo'en
en ik kan er maar geen query bedenken die per guid/nickname zal limiten, dus denk ik dat mijn normalisatie mislukt is
maar dat is toch geen veel op veel relatie?
een guid kan aan maardere nickname's hangen... maar een nickname gan geen merdere guids hebben. Tenminste dat stel je net... dat is gewoon een 1 op veel relatie en maakt je koppeltabel overbodig.
