[MYSQL] Database structuur

[lauwsa]

Hallo,

Ik wil een speletje gaan maken om te kijken als het me lukt, het spel ga ik maken in PHP en de database in MYSQL. De database word gemaakt door install.php, een voorvoegsel kan ingevuld worden in de database file zodat er onderschijt tussen 2 server gemaakt kan worden.

De database ziet er als volgt uit:


Deze bestaat dus uit:

Bank:

Hier worden bankgegevens van de gebruiker opgeslagen,
id staat voor de gebruiker, geld is hoeveel geld er op zijn bank staat. Dit word een gecodeerd getal.
Storting is hoe vaak er vandaag al gestord is. Dit word om 12 uur 's nachts weer op 0 gezet.



Clan:

Hier staat een clan id in, de naam van de clan en de eigennaar. Ik heb bewust geen leden er in gezet omdat ik hier gekozen heb dat ik dit bij de user zet.



Clan items:

Hier staat in welke items de clan heeft en hoeveel geld de clan heeft.



Mijnen

Hier staan mijnen in, een gebruiker kan een mijn hebben. Hier krijgt hij ook uurproductie door.
Dus id van de mijn, eigenaar en uur productie



Slaven

Id van de gebruiker, en hoeveel vecht en werk slaven de gebruiker heeft



Slaven wapens

Hier staat in welken wapens de gebruiker heeft. Je kan niet meer wapens dan slaven hebben.



Speler

Hier staan de spelers in, id van de speler, naam + wachtwoord. Hoeveel geld de speler heeft. Welke clan hij in zit en hopeveel levens hij over heeft.



Static

Dit is de statestieken pagina, hier staat de ranglijst in. Ik kan deze er ook uit halen en dan steeds laten genereren.



Update

id: welken speler of clan
idi: 1 = speler 2 = clan
tijd: waneer laatst updated

Hier staat in waneer welken speler geupdate is. als een speler ingelogt is word die steeds geupdate. Valt hij een andere speler aan word die andere speler oo geupdate.



Wapens

Hier staat in welken wapens er zijn, soort wapen
1 = aanval
2 = verdedeging
3 = goud maak.

Kracht is hoeveel per uur of hoe sterk het wapen is.



Dit zijn nog punten die ik zelf opgemerkt heb:

Speler geld na speler items verplaatsen

Static er uit halen? en dan steeds genereren?

Wat vinden jullie van deze database structuur? en wat zou jij anders doen?

Dit is bedoelt als oefening.

Edit:
Plaatjes fix

[Janoz]

Ten eerste zie ik genummerde kolomnamen. Dat is alvast een dikke rode vlag dat er toch nog iets verder genormaliseerd moet worden. Ten tweede lijkt het me handig om niet primair het saldo en de stortingen op te slaan, maar transacties. Daaruit is keurig het saldo, maar ook de stortingen af te leiden.

Tot slot betekent 'static' iets heel anders dan statistieken.

[lauwsa]

Bedankt voor je reactie,

Ten eerste zie ik genummerde kolomnamen.

Dus je bedoelt Item1 Item2.

Kan ik daar dan beter namen in zetten, dan bij de Item specificaties ook met namen werken en daar allen informatie opgeven.

Dus bvb IPV Item 1: "Zwaart"
Dan bij Wapens id = Zwaart

Dan kan je idd makkelijker zien wat wat is.

Ten tweede lijkt het me handig om niet primair het saldo en de stortingen op te slaan, maar transacties. Daaruit is keurig het saldo, maar ook de stortingen af te leiden.

Dus User

edit:
User id:10

transactie:10

edit:
User id:10

transactie:-500

Goed punt en dan kan ik ook een log maken, bedankt voor de tip

Tot slot betekent 'static' iets heel anders dan statistieken.

Idd, maar zal ik de statistieken er wel in laten?
Ik zal de naam verandere. Bedankt!

[ Voor 3% gewijzigd door lauwsa op 18-11-2010 12:10 ]

[Janoz]

Zwaard schrijf je met een d

Met nummering doel ik op de nummers in de kolomnamen. Dat is een dead give away dat je daar eigenlijk een 1:N relatie hebt en dus een extra tabel nodig hebt

Tot slot maak je geld over van de ene gebruiker naar de andere lijkt me. Een transactie is dan ook een bedrag met twee gebruikers.

[Verwijderd]

Wellicht trap ik hier een open deur in, maar is het niet beter om de tabellen allemaal dezelfde naam te geven en per server (of per logische applicatie) een aparte database te genereren met een specifieke prefix? Dan hoef je in je PHP code maar 1x een connectie aan te maken voor een specifieke database, terwijl de namen van de tabellen in je code niet veranderd hoeven te worden.

[RobIII]

Verwijderd schreef op donderdag 18 november 2010 @ 13:05:
Wellicht trap ik hier een open deur in, maar is het niet beter om de tabellen allemaal dezelfde naam te geven en per server (of per logische applicatie) een aparte database te genereren met een specifieke prefix?

In hosted omgevingen heb je vaak maar beschikking over 1 db

Verder: @TS Als je nou eens een schema maakt i.p.v. een zooi screenshots; een plaatje met een overzicht van de tabellen en hoe ze gerelateerd zijn zegt al 1000x meer dan wat je nu hebt.

offtopic:
Onderschijt? Srsly?

[ Voor 23% gewijzigd door RobIII op 18-11-2010 13:16 ]

[Davio]

Janoz schreef op donderdag 18 november 2010 @ 12:49:
Zwaard schrijf je met een d

Met nummering doel ik op de nummers in de kolomnamen. Dat is een dead give away dat je daar eigenlijk een 1:N relatie hebt en dus een extra tabel nodig hebt

Tot slot maak je geld over van de ene gebruiker naar de andere lijkt me. Een transactie is dan ook een bedrag met twee gebruikers.

Wat betreft die kolommen met nummers en de 1:N relatie, zal ik het even uitleggen.

Je hebt 1 clan die meerdere items heeft.

Dan is het logisch dat je het volgende hebt:
- Een tabel genaamd Clan, met alle info over de Clan (ID, naam)
- Een tabel genaamd Item, met alle info over een specifiek item (ID, naam)
- Een koppeltabel genaamd ClanItem met als foreign keys de ID uit de Clan-tabel en de ID uit de Item-tabel. Elke rij in de koppeltabel is een item voor een clan.

Het gebruiken van zo'n koppeltabel ipv genummerde kolommen heeft alleen voordelen:
- Als er iets verandert aan een item, hoef je het maar op één plek te veranderen
- Als je het maximaal aantal items uitbreidt, kun je makkelijker (en is het beter) een row toevoegen dan een kolom met allemaal null-waarden

Progress-databases zijn trouwens ongeveer de enige databases die een array als kolomtype toestaan, echt verschrikkelijk.

[Janoz]

Mwah, daar leg je niet helemaal uit wat ik in het kort zeg. De uitleg die jij geeft gaat over een N:M relatie. Een meer op meer. Mijn eerste aanname over het model ging er van uit dat een clan meerdere items kan hebben, maar dat een item maar bij 1 clan hoort. De uitleg die jij geeft gaat over een clan die meerdere items heeft, maar die items kunnen ook bij meerdere clans horen.

[Davio]

Janoz schreef op donderdag 18 november 2010 @ 13:38:
Mwah, daar leg je niet helemaal uit wat ik in het kort zeg. De uitleg die jij geeft gaat over een N:M relatie. Een meer op meer. Mijn eerste aanname over het model ging er van uit dat een clan meerdere items kan hebben, maar dat een item maar bij 1 clan hoort. De uitleg die jij geeft gaat over een clan die meerdere items heeft, maar die items kunnen ook bij meerdere clans horen.

Je hebt helemaal gelijk, maar ik ben er dan ook vanuit gegaan dat er inderdaad verschillende items zijn die meerdere clans kunnen bezitten.

Anders moet je de Clan-ID direct in de Item-tabel opslaan.

[cariolive23]

Davio schreef op donderdag 18 november 2010 @ 13:34:
Progress-databases zijn trouwens ongeveer de enige databases die een array als kolomtype toestaan, echt verschrikkelijk.

PostgreSQL kent ook array's, wat heel erg handig kan zijn. Maar dan vooral voor intern gebruik in de database (stored procedures, views, etc.), applicaties (en scripts zoals bv. PHP) kunnen hier echter niet/nauwelijks mee uit de voeten. In bovenstaande situatie zijn array's dan ook niet aan te raden, mocht er een database worden gebruikt die array's ondersteunt.

[jbdeiman]

Overigens voor de "Slaven" typen, geldt eigenlijk hetzelfde. Je hebt nu 2 slaven types, werk en vecht slaven. Maar straks wil je nog verschillende slaven hebben voor:
- Mijnen
- Items maken
- Bouwen

en weet ik veel wat voor acties er zijn. Dan moet je alles aanpassen, veel eenvoudiger is het om dit ook via meerdere tabellen te doen. 1 voor de typen slaven, en 1 voor de slaven per gebruiker. Dat is logischer.

Of... nog beter, de slaven dan aan een bepaalde plek koppelen, (een mijn bijv.) want die plek is aan een gebruiker gekoppeld.


Daarnaast ga ik er vanuit dat je een basis hebt en misschien wel een bepaalde opslag.
Ik zou dus ook een tabel met gebouwen definiëren en daar ook weer bepaalde eigenschappen aan hangen. Het mooie is dat je bijvoorbeeld een mijn als een gebouw kan behandelen met bepaalde eigenschappen. Je kan zo in de toekomst eenvoudig een nieuw type gebouw toevoegen.
Je moet je systeem niet afhankelijk willen maken van extra programmeerwerk als je een nieuw iets toevoegd, of iets nieuws wat behalve wat eigenschappen hetzelfde is wat je al hebt.

[lauwsa]

Ik ben even allen wijzigingen door aan het voeren, ik heb nog nooit een MQSQL schama gemaakt dus ben nog even aan het uitvoegelen hoe ik dat presies ga doen.

Een item kan elke clan hebben, ook meerdere zelfs.
De tip van de gebauwen en Slaven is ook een goeie ben hem er nu aan het in zetten.

Slaven aan mijnen koppelen is idd ook handig, de bedoeling alleen is dat er maar een aantal mijnen zijn, en dat de productie hoger zijn in een mijn. Zet je ze niet in een mijn hebben ze een lagere productie.

Er is geen opslag plaats, je kan zoveel goud hebben als je wilt (a)

edit:



edit2: roze tabel word verwijdert omdat ik niet echt het nut er meer in zie.

edit3:
Speler en clan geld verwijdert, dit is na transacties gegaan.

[ Voor 15% gewijzigd door lauwsa op 19-11-2010 10:28 ]

[MueR]

Voor het maken van database schema's zijn diverse tools beschikbaar. MySQL Workbench bijvoorbeeld, of Visio (onderdeel van MS Office). Deze lezen wat makkelijke, je krijgt namelijk dit soort schema's.

offtopic:
Srsly? Gebauwen? Installeer een spellchecker.

[ Voor 74% gewijzigd door MueR op 19-11-2010 11:33 ]

[Janoz]

Als niet alleen spelers geld kunnen hebben, maar ook clans, lijkt het me handiger om dat door te modeleren. Waarschijnlijk is het handiger om een 'bankrekening' entiteit toe te voegen. Een speler heeft een bankrekening en een clan heeft ook een bankrekening. Transacties gaan van de ene bankrekening naar de andere bankrekening. Nu kunnen spelers geld naar elkaar of naar hun clan overmaken.

[lauwsa]

Voor het maken van database schema's zijn diverse tools beschikbaar. MySQL Workbench bijvoorbeeld, of Visio (onderdeel van MS Office). Deze lezen wat makkelijke, je krijgt namelijk dit soort schema's.

Ik zal Workbench een keer proberen, Visio kan ik nog niet echt om gaan, heb er vaker mee gewerkt maar meestal vind ik het onhandig. Maar bedankt voor de tip.

offtopic:
Srsly? Gebauwen? Installeer een spellchecker.

Dit had ik getypt in notepad, zal even in word cheacken.

Als niet alleen spelers geld kunnen hebben, maar ook clans, lijkt het me handiger om dat door te modeleren. Waarschijnlijk is het handiger om een 'bankrekening' entiteit toe te voegen. Een speler heeft een bankrekening en een clan heeft ook een bankrekening. Transacties gaan van de ene bankrekening naar de andere bankrekening. Nu kunnen spelers geld naar elkaar of naar hun clan overmaken.

idd, je hebt gelijk helemaal vergeten, ik pas het aan.

Tekening aangepast:

--knip--

Als ik thuis ben gebruik ik andere software voor de tekening

Statestieken vetwijderd, denk dat ik deze beter kan genereren zodat deze altijd op to date is.

edit:

Ik heb wapens na item verplaatst zodat ik deze voor meer dingen kan gebruiken, ik heb er ook aan gehangen dat je meerdere krachten kan toevoegen:

--knip--

Namen fixt:


Volgens mij kan ik voor de rest nergens meer wat uitberijden wat handig kan zijn.

[ Voor 28% gewijzigd door lauwsa op 19-11-2010 13:22 ]

[YopY]

quote: lauwsa

Er is geen opslag plaats, je kan zoveel goud hebben als je wilt (a)

Zou in je specificaties toch wat limitaties opnemen, o.a. mbt wat je database voor getallen op kan slaan en wat nog 'normale' cijfers zijn. Je wilt denk ik niet dat iemand rondloopt met een beurs van 18446744073709551615 goudstukken .

Wat betreft Visio, het helpt misschien als je een klas informatieanalyse en/of databaseontwerp gevolgd hebt, daar leer je hoe je data en -relaties kunt visualiseren.

[Verwijderd]

YopY schreef op vrijdag 19 november 2010 @ 15:34:
[...]


Zou in je specificaties toch wat limitaties opnemen, o.a. mbt wat je database voor getallen op kan slaan en wat nog 'normale' cijfers zijn. Je wilt denk ik niet dat iemand rondloopt met een beurs van 18446744073709551615 goudstukken .

Ik heb in de praktijk dit opgelost zien worden (zie WoW, EQ2 en dat soort spellen) door simpelweg verschillende eenheden te gebruiken om dezelfde hoeveelheid currency weer te geven. Dus:

1 platina = 1000 gold = 1.000.000 silver = 1.000.000.000 copper/eenheden

Op deze manier kan iemand dus bijvoorbeeld 1p 34g 23c hebben, wat zich vertaalt naar 1*10^9 + 34*10*6 + 23*10^0 = 1.034.000.023 copper/eenheden. Doordat je de grens niet bij 10 of 100 maar bij 1000 (=10^3) legt, heb je meer dan genoeg "ruimte" in je spel voordat je reeds een nieuwe eenheid moet introduceren omdat iemand meer dan 1000 platina heeft.

[Davio]

Een klas Nederlands zou ook niet misstaan.

Het lijkt me heel vervelend voor je gebruikers als er zoveel verkeerd gespeld is, zoals gebauwen ipv gebouwen.

[Janoz]

Een rekening heeft geen gebruiker of een clan, een clan of een gebruiker heeft een rekening.

[Verwijderd]

Wat betekent trouwens de kolom transacties in de tabel transacties? Bevat die kolom de werkelijke entiteit die op dat moment geruild wordt cq. waar de transactie mee wordt gedaan? Kunnen spelers naast geld ook items ruilen?
Overigens heb ik het gevoel dat de transacties tabel fungeert als een logger; alhoewel het wellicht wel vanuit een functioneel oogpunt handig kan zijn. Zo zou je een restrictie kunnen opleggen op het aantal transacties per tijdeenheid die kunnen plaatsvinden. Ik zou hoe dan ook wél een kolom dDate (type datetime) toevoegen zodat je kan zien wanneer de transactie heeft plaatsgevonden. Dat lijkt mij hoe dan ook handig

Davio schreef op vrijdag 19 november 2010 @ 16:03:
Een klas Nederlands zou ook niet misstaan.

Het lijkt me heel vervelend voor je gebruikers als er zoveel verkeerd gespeld is, zoals gebauwen ipv gebouwen.

dan mag je gelijk met hem meedoen, gezien de brakke zinsconstructie van je laatste zin.

[ Voor 0% gewijzigd door Verwijderd op 20-11-2010 10:38 . Reden: Hele gênant fout verbeterd, met dank aan Davio! ]

[Davio]

Verwijderd schreef op vrijdag 19 november 2010 @ 23:37:
Wat betekent trouwens de kolom transacties in de tabel transacties? Bevat die kolom de werkelijke entiteit wat op dat moment geruild wordt cq. waar de transactie mee wordt gedaan? Kunnen spelers naast geld ook items ruilen?
Overigens heb ik het gevoel dat de transacties tabel fungeert als een logger; alhoewel het wellicht wel vanuit een functioneel oogpunt handig kan zijn. Zo zou je een restrictie kunnen opleggen op het aantal transacties per tijdeenheid die kunnen plaatsvinden. Ik zou hoe dan ook wél een kolom dDate (type datetime) toevoegen zodat je kan zien wanneer de transactie heeft plaatsgevonden. Dat lijkt mij hoe dan ook handig


[...]


dan mag je gelijk met hem meedoen, gezien de brakke zinsconstructie van je laatste zin.

Dat mijn zin jou niet aanstaat, betekent niet dat hij incorrect is. "De entiteit wat" is daarentegen een gruwelijke fout. Niet nitpicken als je er zelf niks van kan, dat is zo gênant.

[Verwijderd]

Davio schreef op zaterdag 20 november 2010 @ 00:44:
[...]

Dat mijn zin jou niet aanstaat, betekent niet dat hij incorrect is. "De entiteit wat" is daarentegen een gruwelijke fout. Niet nitpicken als je er zelf niks van kan, dat is zo gênant.

Ik heb hem verbeterd. Ik heb je zelfs credit gegeven in het editveld. Ga je nu weer lekker ergens anders trollen?

[Avalaxy]

lauwsa schreef op vrijdag 19 november 2010 @ 11:45:
Namen fixt:
[afbeelding]

Volgens mij kan ik voor de rest nergens meer wat uitberijden wat handig kan zijn.

Je zou er goed aan doen consistenter te werk te gaan. Ik zie dat je de ene keer meervoud gebruikt en de andere keer enkelvoud (in tabelnamen). Tevens begin je de ene keer met een hoofdletter en de andere keer met een kleine letter (en dan let ik nog niet eens op de spelfouten ). Van een inconsistente naamgeving wordt geen developer blij!