Ad stopt er mee
tabel opstellen
ik ben bezig met een scriptje maar ik vroeg me af hoe ik best de sql tabel maak.
Ik heb een tabel met leden:
- id
- gebruikersnaam
- wachtwoord
- grond
- ...
en leden kunnen een beroep hebben bijvoorbeeld boer,
een boer kan graan maken.
Dus ik heb een tabel *:
- *
- *
- *
- *
maar dan zou er ook nog een tabel werkplaats moeten zijn:
- id
- naam (*)
- grond (*)
(*)
maar als ik nu wil weergeven welk beroep iemand is moet ik dan nog bij leden een kolom beroep maken en daar het beroep inzetten of moet ik gewoon tellen of de naam ergens voorkomt in een van mijn werkplaats tabellen?
mvg
(edit: ik wil nog niet te veel vrijgeven van mijn project)
Gewijzigd op 22/10/2010 18:37:53 door Jasper DS
Ga normaliseren om tot een goed datamodel te komen. Daaruit volgt dan ook direct hoe je de beroepen in je datamodel op moet nemen!
PHP jasper op 22/10/2010 16:52:27:
dat is zeer moeilijk toe te passen op wat ik wil maken.
Hoezo dan? Het lijkt mij juist moeilijker om met een incorrect datamodel aan de slag te gaan...
Ik begrijp dat dat in dit stadium lastig in te schatten is, maar mijn advies: begin gewoon! Je merkt vanzelf als je vast loopt omdat je dingen mist en in het ergste geval moet je je datamodel aanpassen...
Code (php)
1
* weg *
Laat dit soort berichten voortaan gewoon staan. Nu is het voor een ander die dit topic leest totaal niet meer duidelijk waar de antwoorden vandaan komen.[/modedit]
Gewijzigd op 23/10/2010 16:07:34 door Joren de Wit
De oplossing ligt hem door het denken in producten en voorraden. Welk product een speler wel of niet mag hebben hangt af van zijn beroep, maar dat is iets dat je in PHP moet controleren. Overigens zou het ook mogelijk kunnen zijn producten te bezitten die niet bij je beroep horen: stel dat ik bakker was en smid ben geworden, dan kan het best zo zijn dat ik nog graan over heb :-)
leden
-----
id
gebruikersnaam
etc...
producten
---------
id
product
voorraad
-------
id
lid_id
product_id
hoeveelheid
houdbaarheidsdatum
Krijg je heel veel records in je voorraad tabel die per product aangeven hoveel een bepaald lid daarvan bezit. Zo'n record zou er dus zo uit kunnen zien:
* | 1 | 5 | 100 | 2010-10-23
Oftewel, lid 1 heeft 100 eenheden van product 5 waarvan de houdbaarheidsdatum verloopt op 2010-10-23. (Het * staat daarom omdat het id uiteraard een auto_increment is)
Nu kun je met deze records precies zien wat de voorraad van een bepaald lid is (en tot wanneer die houdbaar is) door alle records behorend bij een bepaald lid uit deze tabel op te halen...
ps. Voor de duidelijkheid: kolomnamen als 'graan' of 'ijzer' zijn fout. Dat zijn producten die een eigen record in de producten tabel verdienen.
Gewijzigd op 23/10/2010 15:54:45 door Joren de Wit
voorraad is oneindig houdbaar. maar je kan bijvoorbeeld niet 2 keer achter elkaar een actie doen er zit bijvoorbeeld 5 minuten tussen .
Op zich niet, maar wat je daarmee bedoelt is volgens mij wel erg. :) Dan zou je de kolommen: zwaarden/ schilden/ harnassen/ graan/ deeg/ brood krijgen. Dan krijg je allemaal nullen.
Beter is ong. een volgende opzet, de rest moet je zelf uitdenken en verder verwerken:
Beroep:
beroep_id, naam, omschrijving
Werkplaats:
werkplaats_id, naam, omschrijving
Beroep_werkplaats: (dit is gekozen, omdat bijv een smit en een edelsmit eenzelfde werkplaats hebben. Ook een veehouder of een landbouwer werken beiden op een boerderij)
id, werkplaats_id, beroep_id
Product:
product_id, naam, omschrijving
Product_grondstoffen:
id, product_id, grondstof_product_id (mag NULL zijn, als het een basis product is)
Beroep_product (zelfde idee als hierboven: Een boer maakt graan, een bakker gebruikt het. In beide gevallen is graan gekoppeld, dus normaliseren) LVL is toegevoegd om bepaalde producten op een bepaald level te kunnen laten starten.:
beroep_product_id, product_id, beroep_id, (lvl)
Als je begrijpt waar ik met deze opzet (het is slechts een basis, maar ik help je al een heel eind op weg) heen wil, dan moet je er verder ook uit komen. Voor het toevoegen van nieuwe producten en dergelijke kan je met een goed uitgedachte/ genormaliseerde opzet zonder aanpassingen in de code werken. Veel eenvoudiger in onderhoud.
Toevoeging gezien je reactie over de houdbaarheidsdatum:
- Is het de bedoeling dat je als speler elk type actie naast elkaar kan doen, of 1 actie totdat die is afgerond?
En tov het bericht van Blanche:
Per speler houd je uiteraard wel bij welke producten hij/ zij heeft, in de "voorraad" tabel.
Afvangen welke producten je wel en niet kan / mag genereren doe je aan de hand van mijn opzet bijvoorbeeld. Maar voorraad heeft Blanche heel goed uitgewerkt voor je.
Gewijzigd op 23/10/2010 16:05:37 door Robert Deiman
PHP jasper op 23/10/2010 16:00:57:
ik snap alleen de houdbaarheidsdatum niet..
voorraad is oneindig houdbaar.
voorraad is oneindig houdbaar.
Dat is afgeleid uit jouw originele opzet waarin je een kolom als graan_houdbaar had? Je zou je voor kunnen stellen dat graan een bepaalde houdbaarheid heeft vanaf het moment dat het aangekocht is. Dan is het wel handig om voor die hoeveelheid graag een houdbaarheidsdatum op te slaan.
Quote:
maar je kan bijvoorbeeld niet 2 keer achter elkaar een actie doen er zit bijvoorbeeld 5 minuten tussen .
Dat is weer een hele andere beperking die weinig tot niets met je datamodel te maken heeft. Je zult misschien alleen op willen slaan wanneer een bepaald product gekocht is.
Een ander voorbeeld: stel dat je gebruikers niet toe wilt staan dat ze binnen 30 dagen weer van beroep wisselen. Dan sla je in de tabel waar je een beroep aan een gebruiker koppelt op wanneer een gebruiker met dat beroep begonnen is.
Maar voordat je hier over na gaat denken, zou ik eerst zorgen dat de basis van je datamodel in orde is. Is dat nu al het geval?
iemand heeft bijvoorbeeld net graan gemaakt en 5 minuten later kan hij terug graan maken, hij doet dat dus, moet ik dan gaan updaten in de voorraad tabel?
Bij het gebruiken van graan zou ik wel records gaan updaten en dan moet je dus even goed opletten dat je de oudste voorraad eerst opmaakt.