[Project] Tips voor optimaal design?

[Verwijderd]

Voorwoord
Ik hoop dat de grote hoeveelheid tekst jullie niet afschrikt om te replyen, ik heb daarom liever een domme reply (of zelfs een reply als www.google.nl) dan geen reply Alle hulp wordt zeer op prijs gesteld! Elke tip is waardevol!

Inleiding
Ik speel een MMORPG online (starwars galaxies, of kort swg) en daarin zitten ook crafting professies. Nu wilde ik hiervoor een eigen site maken waarbij ik makkelijk kan kijken welke dingen ik kan craften en welke resources ik hiervoor nodig heb, welke hiervan de besten zijn en welke resources er momenteel beschikbaar zijn.

Nu is er een site die ongeveer hetzelfde doet, maar niet helemaal aan mijn wensen voldoet, plus ik vind het leuk en een uitdaging om zoiets als ik verder op beschrijf in elkaar te zetten. Daarnaast is sinds de nieuwste update is deze site niet meer bruikbaar voor mijn doeleinden. Deze site is www.swgcraft.com trouwens. Deze geeft echter wel perfecte mogelijkheden om mij het leven makkelijker te maken, hierop kom ik later terug.

Doel
Nu is het doel van dit topic om een aantal design tips te krijgen hoe ik het beste de website in elkaar kan zetten om mij een boel kopzorgen te besparen en te voorkomen dat ik halverwege er achter kom dat ik beter ergens een andere methode had kunnen gebruiken.

Voorbereiding
Een voorbeeld professie uit SWG is de armorsmith. Deze kan, zoals een ieder al verwacht , armor craften. Een voorbeeld hiervan is een composite armor chestplate. Deze heeft een aantal resources nodig die kunnen worden ge-harvest, maar ook een aantal onderdelen die moeten worden gecraft en een aantal onderdelen die optioneel zijn. Hieronder heb ik meerdere screenshots samengevoegd en kleuren gegeven zodat het duidelijk te zien is welke craft waarbij hoort.

(klik op de thumb voor het volledige screenshot)

Uitleg screenshot
Op het screenshot is dus te zien dat als ik de composite body armor wil craften, ik twee soorten resources moet hebben (Wooly_hide en Solid_Petrochem_feul) en daarnaast een aantal dingen die gecraft moeten(/kunnen) worden.
Hierbij zijn is één van rode componenten nodig (wél 3 keer). Hierin moet dus een keuze gemaakt worden.
De rode componenten op zijn beurt bestaan weer uit een x aantal andere items die benodigd zijn.
Hieronder valt het groene component. Afhankelijk van welk rood component er gebruikt wordt (basic/standard/advanced), zijn 1 tot 3 groenen nodig in een rood component.
De rode componenten kunnen naast een aantal resources ook blauwe componenten bevatten, dit is echter een optie, en niet verplicht. Er kan een willekeurige combinatie worden gemaakt van 0 tot 3 blauwen.

Doel van de site
Het doel dat ik momenteel met de site voor ogen heb is een lijst maken met de resources die ik allemaal nodig hebt c.q. kan gebruiken voor bepaalde items in het spel. De resources hebben bepaalde waarden, welke aangeven welke resources de besten zijn voor een bepaald component. De site moet daarom zelf kijken welke resources het beste zijn voor het specifieke produkt. Daarnaast moet de site aangeven welke resources in totaal nodig zijn, meegerekend de andere crafts, om een bepaald product te maken.
Ook zou het mooi zijn dat de site het omgekeerde kan, namelijk kijken welke resources er beschikbaar zijn, en waar deze goed in gebruikt zouden kunnen worden.

Beschikbare middelen
De website www.swgcraft.com heeft een aantal opties beschikbaar die ik perfect kan gebruiken voor mijn doel ( http://www.swgcraft.com/resourceexport.php )
Dit is bijvoorbeeld de resourcetree ( http://www.swgcraft.com/files/resourcetree.xml ) welke alle levels (basis -> specifiek) aangeeft van de resources die gebruik kunnen worden, en welke specifiekere resources hier weer onder vallen. Non-ferrous metal is bijvoorbeeld een child van metal.
Daarna zijn er de resources zelf ( http://www.swgcraft.com/sendfile.php?file=currentresources_infinity.xml.gz ) die gebruikt kunnen worden voor de crafts. Uit de vorige link kunnen de classes worden gehaald en kunnen alle resources uit dit bestand worden gehaald die onder dezelfde categorie vallen.

Beschikbare technieken
Wat ik sowieso beschikbaar heb (inclusief enige kennis) zijn, plus waar mijn voorkeuren naar uit gaan:

• PHP
• MySQL
• XML (en XML schema, XPATH, etc)

Daarnaast is het uiteraard mogelijk een mouw te passen aan de rest die jullie adviseren.

Tips?
In eerste instantie zal ik graag wat tips ontvangen over de technieken en database structuur.
Ook hoe ik de relaties tussen de verschillende componenten en resources gelegd kunnen worden, vooral omdat er verschillende mogelijkheden zijn en een aantal dingen optioneel zijn terwijl anderen juist verplicht zijn.

Nawoord
Uiteraard heb ik mijn eigen ideeën over hoe dit alles te doen en hoe de structuren er uit kunnen zien en heb ik meer nagedacht over de site dan hier beschreven staat.
Deze kan ik verder toelichten als iemand er behoefte aan heeft, maar ik wilde graag niet in het begin al de topic een bepaalde hoek indrukken met het risico dat ik in het begin al niet de optimale richting in ga, plus ik wilde de intro informatie tot op een zekere hoogte beperkt houden, zodat jullie niet alleen al een half uur kwijt zijn met lezen en begrijpen.

Bedankt
Ik hoop dat jullie ook een uitdaging zien in mij tips te geven hoe ik het beste mijn site kan ontwerpen. Ik zie in ieder geval een leuke uitdaging in de site zelf, en ik weet zeker dat ik er een boel van zal leren Bedankt!

[NMe]

Ik zie dat je nieuw bent. Welkom op GoT.

Ik vind je vraag, ondanks de omvang van je startpost, een beetje erg open. Ik zal wat globale tips geven, ik hoop dat je daar wat mee kan.

Tabelstructuur:
Maak in MySQL een tabel aan met alle items. Dit zijn dan zowel de items die je maakt, als ook de items die je nodig hebt om andere items te maken. Neem in deze tabel alle kenmerken op die je nodig hebt (ID, naam, gewicht, whatever ).
Maak daarna nog een tabel aan die items met elkaar linkt, en wel op deze manier: je neemt in deze tabel 3 velden op: 2x een ID dat naar een item wijst, en 1x een veld voor een aantal. Het eerste ID zegt welk item je maakt, het tweede ID zegt welk item je nodig hebt, en het aantal zegt hoeveel van die items je hebben moet om het item dat je maakt in elkaar te zetten.

Voorbeeld:
Item

ID	name	weight	cost
1	Leather Jacket	3	30
2	Leather Boots	3	20
2	Cowhide	1	5

Crafting

craftID	resourceID	count
1	3	2
2	3	1

In de crafting-tabel heb je een samengestelde sleutel van beide ID's. Op deze manier voeg je gewoon een extra regel aan de tabel toe die Leather Boots ook nog eens aan Laces koppelt, en dan heb je dus 2 records die de samenstelling van Leather Boots bepalen: Cowhide en Laces.

Wat betreft XML: het nut om dit te gebruiken ontgaat me een beetje. Ik heb het hier al vaker geroepen, maar ik roep het nog een keer: XML is een middel, geen doel. Het lijkt me hier weinig toe te voegen, dus kun je het beter niet gebruiken.

Ook wat betreft PHP kan ik weinig vertellen. Het is allemaal vrij straight to the point werk, waar je in principe niet veel problemen mee moet ondervinden. In dit geval is een goede structuur in je database het belangrijkste.

[Verwijderd]

-NMe- schreef op vrijdag 20 mei 2005 @ 00:26:
Ik zie dat je nieuw bent. Welkom op GoT.

Nieuw in dusverre dat dit de eerste keer is dat ik zelf een vraag stel. In de GoT database staat zo verrekte veel dat in de meeste gevallen het absoluut niet nodig is om een vraag te stellen. Daarnaast browse ik het forum niet zo vaak als de meeste GoT'ers zodat de meeste vragen ook al beantwoord zijn voordat ik ze uberhaupt gelezen heb
In ieder geval bedankt voor de welkom

[b]-NMe- schreef op vrijdag 20 mei 2005 @ 00:26Ik vind je vraag, ondanks de omvang van je startpost, een beetje erg open. Ik zal wat globale tips geven, ik hoop dat je daar wat mee kan.

Ik gaf het zelf al aan. Maar het idee hiervan was om open te beginnen en om steeds verder naar 'closed' te gaan naarmate er een aantal replies zijn. Dit om te voorkomen dat ik al een verkeerde strategie kies in het begin. (als ik de database verkeerd design bijv. dan kan ik weer opnieuw beginnen?)

-NMe- schreef op vrijdag 20 mei 2005 @ 00:26:
Tabelstructuur:
Maak in MySQL een tabel aan met alle items. Dit zijn dan zowel de items die je maakt, als ook de items die je nodig hebt om andere items te maken. Neem in deze tabel alle kenmerken op die je nodig hebt (ID, naam, gewicht, whatever ).
Maak daarna nog een tabel aan die items met elkaar linkt, en wel op deze manier: je neemt in deze tabel 3 velden op: 2x een ID dat naar een item wijst, en 1x een veld voor een aantal. Het eerste ID zegt welk item je maakt, het tweede ID zegt welk item je nodig hebt, en het aantal zegt hoeveel van die items je hebben moet om het item dat je maakt in elkaar te zetten.

Voorbeeld:
Item

ID	name	weight	cost
1	Leather Jacket	3	30
2	Leather Boots	3	20
2	Cowhide	1	5

Crafting

craftID	resourceID	count
1	3	2
2	3	1

In de crafting-tabel heb je een samengestelde sleutel van beide ID's. Op deze manier voeg je gewoon een extra regel aan de tabel toe die Leather Boots ook nog eens aan Laces koppelt, en dan heb je dus 2 records die de samenstelling van Leather Boots bepalen: Cowhide en Laces.

_{(( Allereerst moet ik toegeven dat ik inmiddels een aantal biertjes op heb, dus als ik ff de plank volledig mis sla, excuseert u mij ))}
Kan ik op deze manier ook aangeven welke onderdelen optioneel zijn, en waar welke verschillende keuzes gemaakt kunnen worden? Ik wil later in de eind GUI bijvoorbeeld aangeven dat ik basic/standard/advanced componenten wil gebruiken, en niet altijd alleen de advanced componenten gebruiken.
Ik denk zelf dat ik dan eenzelfde tree-structuur moet maken als de resourcetree.xml om aan te geven dat er bijvoorbeeld verschillende 3 rode keuzes mogelijk zijn? En daarnaast aangeven of het een verplichte keuze is of een optionele? En dan deze tree vervolgens met behulp van unieke ID's te koppelen aan de items zelf?

-NMe- schreef op vrijdag 20 mei 2005 @ 00:26:Wat betreft XML: het nut om dit te gebruiken ontgaat me een beetje. Ik heb het hier al vaker geroepen, maar ik roep het nog een keer: XML is een middel, geen doel. Het lijkt me hier weinig toe te voegen, dus kun je het beter niet gebruiken.

Eigenlijk was ik al bang dat ik deze reply zou krijgen, en warempel, de eerste reply al. Nu moet ik het wel toegeven: ik heb de hele dag wat dingen (verplicht) door gelezen over XML, en jep, omdat het deels nieuwe kennis is, moest het even genoemd worden

[b]-NMe- schreef op vrijdag 20 mei 2005 @ 00:26Ook wat betreft PHP kan ik weinig vertellen. Het is allemaal vrij straight to the point werk, waar je in principe niet veel problemen mee moet ondervinden. In dit geval is een goede structuur in je database het belangrijkste.

Inderdaad, maar nu is het iig duidelijk dat het een webpagina wordt in dit geval, en niet een c-programma, bijvoorbeeld. Maar point taken.

[NMe]

Verwijderd schreef op vrijdag 20 mei 2005 @ 00:59:
_{(( Allereerst moet ik toegeven dat ik inmiddels een aantal biertjes op heb, dus als ik ff de plank volledig mis sla, excuseert u mij ))}
Kan ik op deze manier ook aangeven welke onderdelen optioneel zijn, en waar welke verschillende keuzes gemaakt kunnen worden? Ik wil later in de eind GUI bijvoorbeeld aangeven dat ik basic/standard/advanced componenten wil gebruiken, en niet altijd alleen de advanced componenten gebruiken.

Als je advanced componenten gebruikt, dan krijg je ook een advanced item, met andere kenmerken. Je zal dit dus sowieso apart op moeten nemen lijkt me.
Datzelfde geldt voor optionaliteit denk ik. Wanneer een "ingrediënt" optioneel is, wil dat normalerwijs zeggen dat je een ander item krijgt als dat onderdeel er wel in zit, dan wanneer dit er niet in zit. Gewoon een apart record voor opnemen in de itemtabel en opnieuw koppelen in de crafting tabel.

Je zou eventueel een en ander nog wel op een andere manier aan kunnen pakken, zodat je inderdaad een soort van boomstructuur hebt (Light Leather Jacket, Medium Leather Jacket, Heavy Leather Jacket, enz horen allemaal bij elkaar, die zou je kunnen groeperen), maar ik denk dat mijn oplossing iets eenvoudiger is te implementeren. Het betekent echter wel wat extra records.

[Verwijderd]

Ik heb er wat verder over nagedacht en ik zat er aan te denken om het op de volgende manier te gaan doen:

• Eén tabel (items_table) met de items, waarin elk item een aantal vaste gegevens heeft, en uiteraard een uniek ID.
• Eén tabel (ingredients_table) met de ingredienten die nodig zijn om een item uit items_table te maken, deze worden bij elkaar gehouden dmv van de items_id
• Eén tabel (craft_tree_table) met een tree die aangeeft welke items hoe gegroepeerd zijn, dit om de mogelijkheid te behouden voor de bijvoorbeeld 3 vershilllende opties voor rood.
• _{Eén tabel (experimentation tabel) voor de experimentation waarden, hierover heb ik nog niet nagedacht}

Voor het screenshot zal dat dan deels het volgende worden:

Items tabel

id description complexity schema_size cmp_bdy Composite Armor Chestplate Appearance 15 3 cre_aslt_bsc Basic Assault Core 21 1 cre_aslt_std Standard Assault Core 22 1 cre_aslt_adv Advanced Assault Core 23 1 seg_aslt Assualt Armor Segment 21 1 lay_pri Advanced Armor Layer Primus 32 1 lay_sec Advanced Armor Layer Secondus 32 1 lay_ter Advanced Armor Layer Tertius 32 1 lay_kin Kinetic Protection Armor Layer 28 1 lay_cld Cold Protection Armor Layer 28 1 lay_hea Heat Protection Armor Layer 28 1 lay_ele Electrical Protection Armor Layer 28 1 lay_eng Energy Protection Armor Layer 28 1 lay_acd Acid Protection Armor Layer 28 1

Ingredients tabel

id description item_id swgcraft_id craft_id amount optional 1 Appearance Fragments cmp_bdy whd 50 2 Armor Core Frame cmp_bdy spc 50 3 Armor Core cmp_bdy cre 3 4 Load Bearing Harness cmp_bdy cloth 1 5 Reinforcement cmp_bdy rfp 1 6 Bio Enhancement Cartridge cmp_bdy bmc 1 true 7 Appearance Enhancement cmp_bdy fae 1 true 8 Appearance Enhancement cmp_bdy aae 1 true 9 Padding cre_aslt_bsc hid 30 10 Liner cre_aslt_bsc fib 30 11 Body cre_aslt_bsc mtl 30 12 Auxilary Coverage cre_aslt_bsc gem 25 13 Armor Segment cre_aslt_bsc seg_aslt 1 14 Core Enhancement cre_aslt_bsc ace 1 true

Relations tabel

id description level_1 level_2 level_3 cre Armor Core cre_aslt Armor Assault Core cre cre_aslt_bsc Basic Assault Core cre cre_aslt cre_aslt_std Standard Assault Core cre cre_aslt cre_aslt_adv Advanced Assault Core cre cre_aslt seg Armor Segment seg_aslt Assault Armor Segment seg cloth Synthetic Cloth rfp Reinforced Fiber Panel bmc Biological-Mechanical Cartridge fae Feathered Appearance Enhancement aae Armor Appearance Enhancement ace Armor Core Enhancement

Nu vraag ik me het volgende echter af

• Gaat het werken voor wat ik wil?
• Is het praktisch of is er een betere tabel structuur?
• Is het verstandiger om numerieke id's te gebruiken of zijn unieke namen beter?
• Is er buiten de database structuur nog iets wat ik het beste van te voren uit kan zoeken? Voordat ik één regel programmeer?

Bedankt iedereen
B

[Verwijderd]

mmm, ach, probeer het zo wel... zie wel waar het schip strand ty

[NMe]

Zo kan het ook, al zegt mijn gevoel dat ook de "ingrediënten" items zijn, maar dat is meer een gut feeling dan goed verstand op dit late uur denk ik.

Een kleine opmerking heb ik wel: in die relations-tabel, daar noem je level 1 t/m 3. Staat dit aantal vast? Zo te zien niet, want sommige relaties hebben minder levels dan andere. Wanneer het maximum aantal levels 3 is, dan kun je het nog wel in één tabel laten staan (al druist dat een beetje tegen de normalisatieregels in), maar als er meer levels kunnen zijn (5? 10? 20?) dan kun je beter een aparte tabel bijhouden voor levels.

[Verwijderd]

-NMe-, allereerst bedankt voor alle posts tot dusverre al, ze helpen me zeker in de juiste richting denken

-NMe- schreef op zaterdag 21 mei 2005 @ 02:37:
Zo kan het ook, al zegt mijn gevoel dat ook de "ingrediënten" items zijn, maar dat is meer een gut feeling dan goed verstand op dit late uur denk ik.

De ingredienten kunnen ook items zijn inderdaad. Als het in de swgcraft_id colom staat dan zijn het resources (hides, bones, etc) en als het in de craft_id colom staat dan zijn het craftables en dus items inderdaad. De logica (voor mij ) achter deze manier is dus dat ik op deze manier aangeef dat de volgende regel:

id	description	item_id	swgcraft_id	craft_id	amount	optional
3	Armor Core	cmp_bdy		cre	3

De cre uit de de relations tabel komt en dus 3 verschillende items kan bevatten, namelijk:

cre	Armor Core
cre_aslt	Armor Assault Core	cre
cre_aslt_bsc	Basic Assault Core	cre	cre_aslt
cre_aslt_std	Standard Assault Core	cre	cre_aslt
cre_aslt_adv	Advanced Assault Core	cre	cre_aslt

Hier komt wel wat lastig om de hoek kijken inderdaad, dus misschien dat de relaties tabel nog niet helemaal goed is. Maar de Armor Assault Core's lijken zo ook een item, maar eigenlijk is dit gewoon de groep voor de assualt cores. DIt moet ik nog even verder onderzoeken denk ik?
iig probeer ik zo aan te geven dat de items cre_aslt_bsc/cre_aslt_std/cre_aslt_adv allemaal gebruikt kunnen worden als armor core in de cmp_bdy.

Een kleine opmerking heb ik wel: in die relations-tabel, daar noem je level 1 t/m 3. Staat dit aantal vast? Zo te zien niet, want sommige relaties hebben minder levels dan andere. Wanneer het maximum aantal levels 3 is, dan kun je het nog wel in één tabel laten staan (al druist dat een beetje tegen de normalisatieregels in), maar als er meer levels kunnen zijn (5? 10? 20?) dan kun je beter een aparte tabel bijhouden voor levels.

Jep, zoals hierboven ook aangegeven... ik denk dat de relaties table inderdaad nog een tweak kan gebruiken... Hmmm...

[Verwijderd]

Hmm, ik kwam deze link tegen, en deze gaf voor mij een mooie kijk op het op slaan van hierarchical data in een database. Nu lijkt het mij dat ik de eerste methode prima kan gebruiken voor mijn doeleinde (de tweede is niet nodig)?

Maar wat nou als ik de tree in een xml document maak, en daarna xml-standaard functies gebruik om alle children, parents etc te vinden? xml is altijd in tree-structure, dus die zal er vast prima functies voor hebben? Waarom doet men het niet op deze manier? is het dan moeilijk om de tree te manipuleren?

Iemand uitleg/ideeen?

[NMe]

Verwijderd schreef op zaterdag 21 mei 2005 @ 21:21:
Hmm, ik kwam deze link tegen, en deze gaf voor mij een mooie kijk op het op slaan van hierarchical data in een database. Nu lijkt het mij dat ik de eerste methode prima kan gebruiken voor mijn doeleinde (de tweede is niet nodig)?

Dat lijkt me inderdaad wel toe te passen op jouw situatie ja.

Maar wat nou als ik de tree in een xml document maak, en daarna xml-standaard functies gebruik om alle children, parents etc te vinden? xml is altijd in tree-structure, dus die zal er vast prima functies voor hebben? Waarom doet men het niet op deze manier? is het dan moeilijk om de tree te manipuleren?

Omdat je dan van DB->XML->HTML moet converteren, terwijl je net zo goed DB->HTML kan doen. De tussenstap 'XML' voegt hier niets aan toe, aangezien zoeken in een database sowieso meestal sneller is (indexes ). Aan de andere kant is wat jij noemt weer een argument om XML te gebruiken: de boomstructuur die XML voor je mogelijk maakt zorgt ervoor dat je alles makkelijk kunt benaderen. Weer een argument tegen is dat je bij een wijziging de hele file opnieuw weg moet schrijven. Welke van de twee technieken je gebruikt is dus aan jou, maar zelf zou ik niet voor de XML-manier gaan.

[Verwijderd]

Ok, het database gedeelte heb ik geimplementeerd. Met een test script heb ik een aantal dingen gecontroleerd, en het ziet er naar uit dat ik alles kan wat ik wil. (hopelijk ) Nu kan ik me dus gaan richten op het gebruikers-interface gedeelte en de implementatie.

Nu had ik in eerste instantie het volgende ontwerp in gedachten (deze is dus statisch):

Klik op de thumb voor de html versie

Nu heb ik echter een aantal trappen in de juiste richting nodig voor de implementatie e.d. Een aantal kreten waar ik naar zou kunnen kijken helpen hierbij al heel erg (treeview, dhtml, etc).

Ook zat ik te denken hoe ik het het beste op kan lossen wat betreft de volgende punten:

• De tree client of server side uitvoeren? Voordelen/nadelen?
• De source van de opmaak en dus ook de tabellen e.d. scheiden. Als ik de volgorde van de tabellen, of een tabel wel of niet weer wil geven, dan moet ik niet de hele code herschrijven lijkt me?
• De de trees uitgeklapt kan laten, maar toch de mogelijkheid behoudt om de tabellen op naam/waarden/oid te orderen. Ik heb werkelijk geen idee hoe ik alle items/tabellen en acties het beste uit elkaar kan houden.

Elke tip is welkom

[Rath]

• tree zou ik client side uitvoeren...waarom in mijn ogen zuiver om het feit dat je dan niet elke keer een volledige refresh van je pagina moet doen...(dit brengt wel een langere pagina-load met zich mee)
  dus eventueel opsplitsen? De volledige Appereance Fragments laden en client side werken en als je dan Armor Core Frame wil laden ff dit stuk van de tree binnen halen en client side verder behandelen
• opmaak: ?css?
• geen idee

[Verwijderd]

Ik ben het helemaal eens met dat we de pagina het liefst niet helemaal willen refreshen, voor de gebruiker wel zo makkelijk en voor de bandbreedte ook wel lekker Maar ik heb geen idee welke technieken/methodes ik in dat geval toe moet passen. Hoe kan ik de elementaire elementen gelijk al laden, maar zodra er dieper in de tree gegaan wordt, de waarden eerst ophalen en dan pas verder gaan?
CSS, uiteraard, uiteraard. Maar ik boelde eigenlijk meer de globale opmaak van de site. Dus ook naast de kleuren ook de plaatjes ( +, - ) aanpassen en andere groten geven, de tabel volgorde veranderen, bepaalde onderdelen uitschakelen, trees hergroeperen. Maar ik denk dat dit 'probleem' zichzelf wel zal op lossen, dus sta er niet te uitgbreid bij stil

[Gerco]

Misschien ten overvloedde nog even over die items en ingredients. Dat komt op mij niet over als een tree, maar meer als een gerichtte graaf. Een craftable bestaat uit verschillende andere items (craftable of niet) en die items kunnen weer ingredient zijn voor 1 of meer craftables.

Die structuur is lastig in een tree te vatten aangezien elke node meerdere children kan hebben en ook meerdere parents. Het idee om een Items tabel en een Relations tabel te hebben lijkt me dan ook superieur aan twee tabellen voor Items en Ingredienten.

Vervolgens maak je een tabel met Constraints waarin beschreven wordt welk soort relaties een craftable moet hebben met zijn children om geldig te zijn.

Je maakt dan dus de volgende tables:
Items (id, description, weight, cost, craftable)
Relations (parentid, childid, amount, function)
Constraints (parentid, contype, reltype)

Nu kun je dus relaties maken zoals dit:
1: armour, piece_of_leather, 3, coating
2: armour, piece_of_steel, 1, coating
3: armour, silver_strip, 1, adornment
4: armour, gold_strip, 1, adornment

En constraints:
1: armour, exactly_one, coating
2: armour, at_most_one, adornment

Zo geef je dus aan dat je armour precies 1 ingredient van type coating nodig heeft en 0 of 1 adornments. Vervolgens overgieten met een sausje recursie en je kunt oneindig diepe structuren van items maken die onderdeel uitmaken van andere items, optioneel of niet, met de keuze om 1_van_een_lijstje te requiren.

[ Voor 49% gewijzigd door Gerco op 25-05-2005 21:07 ]

[Verwijderd]

Sorry Gerco, maar inderdaad staan de uiteindelijk tabellen niet hierboven weergegeven.. hieronder de tabellen zoals ik ze op dit moment heb:

craft_tree

id

id_name

description

parent

ingredients

id

description

item_id

swgcraft_id

craft_id

amount

optional

items

id

id_name

description

complexity

schema_size

resources

id

planet_id

planet_name

resource_id

resource_name

resource_type

resource_type_id

er

cr

cd

dr

fl

hr

ma

oq

sr

ut

pe

availability_id

available_timestamp

available_by_name

available_by_id

verified

verified_timestamp

verified_by_name

verified_by_id

resource_tree

id

swgcraft_id

description

parent

--edit--
Volgens mij is dit ongeveer op de manier die jij ook aangeeft? ik heb het volgens de 1e manier gedaan die hieronder beschreven staat (de externe url dus). ((Het is wel de database geworden))

Verwijderd schreef op zaterdag 21 mei 2005 @ 21:21:
Hmm, ik kwam deze link tegen, en deze gaf voor mij een mooie kijk op het op slaan van hierarchical data in een database. Nu lijkt het mij dat ik de eerste methode prima kan gebruiken voor mijn doeleinde (de tweede is niet nodig)?

--edit 2--
voor de liefhebbers, een sql dump van de databases en test waarden van dit moment

[ Voor 22% gewijzigd door Verwijderd op 25-05-2005 21:32 ]

[Gerco]

Het lijkt er wel wat op ja, maar er zijn een paar belangrijke verschillen:

1. In jouw systeem is er een echt verschil tussen een craftable item en een niet craftable item. Een craftable die ook een ingredient is voor een andere craftable staat dus in twee tabellen. In mijn systeem zijn de twee identiek, een item heeft alleen een attribuut wat aangeeft of het craftable is of niet. Op die manier hoef je dus ook geen onderscheid te maken tussen de twee types items.

Dat attribuut is eigenlijk niet eens nodig omdat je kunt kijken of er relaties bestaan met dat item als parent, maar het is ook wel handig als je dat direct aan het item kan zien, zonder weer een dure extra query te moeten gaan doen.

2. Ik heb het niet zo goed bekeken, maar zo te zien heeft jouw systeem wel een mogelijkheid om aan te geven of een ingredient optioneel is of niet. Volgens mij kun je nu aangeven dat je bijvoorbeeld voor een armour kan kiezen uit een lederen en een stalen coating. Je kan echter niet verplichten dat de gebruiker 1 van de twee moet kiezen, geen of beiden zijn ook mogelijk, terwijl dat onzinnig is.

Met die constraints kun je dit soort dingen bijvoorbeeld vastleggen:
- Een kar heeft precies 4 wielen, precies 1 frame en 0 of 1 dak.
- De wielen kunnen van type houten_wiel of stalen_wiel zijn.
- Het frame kan van type berkenhouten_frame of eikenhouten_frame zijn
- Het dak kan een katoenen_doek of houten_dak zijn.

Het is natuurlijk de vraag of je zoveel flexibiliteit nodig hebt, want het is een behoorlijk werk om dit in elkaar te coden.

[ Voor 14% gewijzigd door Gerco op 25-05-2005 22:23 ]

[Verwijderd]

Gerco schreef op woensdag 25 mei 2005 @ 22:20:
Het lijkt er wel wat op ja, maar er zijn een paar belangrijke verschillen:

1. In jouw systeem is er een echt verschil tussen een craftable item en een niet craftable item. Een craftable die ook een ingredient is voor een andere craftable staat dus in twee tabellen. In mijn systeem zijn de twee identiek, een item heeft alleen een attribuut wat aangeeft of het craftable is of niet. Op die manier hoef je dus ook geen onderscheid te maken tussen de twee types items.

Dat attribuut is eigenlijk niet eens nodig omdat je kunt kijken of er relaties bestaan met dat item als parent, maar het is ook wel handig als je dat direct aan het item kan zien, zonder weer een dure extra query te moeten gaan doen.

Interessant, inderdaad. Het maakte me bijna vergeten waarom ik het in twee tabellen had geplaatst
Ik maak inderdaad een verschil tussen craftables en ingredienten, echter alléén in een latere stap. De eerste stap die in een schema aangeeft wat de ingredienten zijn maak ik in principe géén onderscheid of het een craftable of een resource is (niet helemaal waar, omdat ze wel in verschillende kolommen staan) De reden echter waarom ze verschillende ID-kolommen hebben en uiteindelijk verschillende tabellen is dat de resources van een externe-site worden geimporteerd, hierdoor hoef ik maar 1 tabel up-te-daten én voorkom ik de mogelijkheid dat die site per-ongeluk een zelfde id gebruikt die ik ook gebruik.
De structuur waarop de databases worden gebruikt is echter:

code:

Items 
> Ingredient (resource_type)
   > resource_tree (10 resources)
> Ingredient (resource_type)
   > resource_tree (3 resources)
> Ingredient (craftable_type)
   > craftable_tree (2 craftables)
      > Items
         .... etc ....

2. Ik heb het niet zo goed bekeken, maar zo te zien heeft jouw systeem wel een mogelijkheid om aan te geven of een ingredient optioneel is of niet. Volgens mij kun je nu aangeven dat je bijvoorbeeld voor een armour kan kiezen uit een lederen en een stalen coating. Je kan echter niet verplichten dat de gebruiker 1 van de twee moet kiezen, geen of beiden zijn ook mogelijk, terwijl dat onzinnig is.

Met die constraints kun je dit soort dingen bijvoorbeeld vastleggen:
- Een kar heeft precies 4 wielen, precies 1 frame en 0 of 1 dak.
- De wielen kunnen van type houten_wiel of stalen_wiel zijn.
- Het frame kan van type berkenhouten_frame of eikenhouten_frame zijn
- Het dak kan een katoenen_doek of houten_dak zijn.

Het is natuurlijk de vraag of je zoveel flexibiliteit nodig hebt, want het is een behoorlijk werk om dit in elkaar te coden.

Inderdaad. De "optional" in mijn tabel geeft aan of deze verplicht is of niet. Ik ben het helemaal eens met jou systeem en de relaties, dat lijkt me inderdaad een prima oplossing.
Echter zie ik in het crafting systeem geen reden om dat te implementeren, helaas , omdat het óf alles is óf niets. Sterker nog, het is alles van exact het zelfde type (exact zelfde serial/id) en niet van het zelfde soort, indien het 1 ingredient is.

--edit--
Ik kan de gebruiker via de trees verplichten om een lederen of een stalen couting te gebruiken trouwens. de structuur in de trees geeft aan wat er onder de categorie valt en wat niet. De gebruiker is altijd verplicht één van de dingen onder deze categorie te kiezen, tenzij het optioneel is.

[ Voor 6% gewijzigd door Verwijderd op 25-05-2005 23:14 ]

[Verwijderd]

Nog even het screenshot voor het gemak herhalen, ik denk dat het goed kan helpen met een snel idee krijgen wat het probleem momenteel is, vooral als je nieuw in dit topic bent:

Om even terug te komen om de uitdagingen te tackelen waar ik nu mee te maken heb:

Orderen
Op welke manieren zou ik in mijn tabellen kunnen orderen? Ik kan dit uiteraard doen met het ORDER BY commando van mysql, of ik kan alles in een array zetten en dit orderen? Of is er ook iets mogelijk aan de client side? Dat zou net zo makkelijk zijn, of?
(edit: ben al een paar manieren tegengekomen op inet, zoals deze , maar gelieve een aantal technieken/methoden, want er moet er 1 de beste zijn )

Gegevens/wijzigingen bijhouden
Even aangenomen dat ik de tabellen server side orden, wat is dat de makkelijkste manier om bij te houden welke tabellen hoe geordend zijn en welke opnieuw geordened moeten worden? Voor zover mij momenteel binnen geschoten is dat ik het op 2 manieren kunnen doen. De 1e is met de url b.v. item.php?order=table1&order_by=oq. Dat lijkt mij echter op een gegeven moment erg uit de hand lopen me de link, die wordt langer en langer. De 2e manier zou kunnen zijn om het in de session variabelen bij te houden. Maar op deze manier kan men niet een bepaalde instelling bookmarken?

Client side gegevens ophalen
Derde punt waar ik tegen aan loop is dat ik me af vraag of er manieren zijn om gegevens van mijn site op te halen en weertegeven zonder dat de pagina vernieuwd hoeft te worden? vast wel? in dat geval, noem eens een paar kreten dan zoek ik ze uit.

In ieder geval al bedank voor alle voorgaande replies, ze hielpen echt mijn denkwijze op een rechte lijn te krijgen

[ Voor 8% gewijzigd door Verwijderd op 26-05-2005 00:56 ]

[mindcrash]

Verwijderd schreef op woensdag 25 mei 2005 @ 23:44:
Nog even het screenshot voor het gemak herhalen, ik denk dat het goed kan helpen met een snel idee krijgen wat het probleem momenteel is, vooral als je nieuw in dit topic bent:

[afbeelding]

Om even terug te komen om de uitdagingen te tackelen waar ik nu mee te maken heb:

Orderen
Op welke manieren zou ik in mijn tabellen kunnen orderen? Ik kan dit uiteraard doen met het ORDER BY commando van mysql, of ik kan alles in een array zetten en dit orderen? Of is er ook iets mogelijk aan de client side? Dat zou net zo makkelijk zijn, of?
(edit: ben al een paar manieren tegengekomen op inet, zoals deze , maar gelieve een aantal technieken/methoden, want er moet er 1 de beste zijn )

ORDER BY, en dat client side aan laten sturen. Dit door de middleware laten doen is een stuk onlogischer omdat de db dat veel sneller kan (vanwege indices enzo)

Gegevens/wijzigingen bijhouden
Even aangenomen dat ik de tabellen server side orden, wat is dat de makkelijkste manier om bij te houden welke tabellen hoe geordend zijn en welke opnieuw geordened moeten worden? Voor zover mij momenteel binnen geschoten is dat ik het op 2 manieren kunnen doen. De 1e is met de url b.v. item.php?order=table1&order_by=oq. Dat lijkt mij echter op een gegeven moment erg uit de hand lopen me de link, die wordt langer en langer. De 2e manier zou kunnen zijn om het in de session variabelen bij te houden. Maar op deze manier kan men niet een bepaalde instelling bookmarken?

Cookies?

Client side gegevens ophalen
Derde punt waar ik tegen aan loop is dat ik me af vraag of er manieren zijn om gegevens van mijn site op te halen en weertegeven zonder dat de pagina vernieuwd hoeft te worden? vast wel? in dat geval, noem eens een paar kreten dan zoek ik ze uit.

In ieder geval al bedank voor alle voorgaande replies, ze hielpen echt mijn denkwijze op een rechte lijn te krijgen

mja, daar is op dit moment maar 1 heel hip buzzword voor: AJAX

[Verwijderd]

Hmm, ik denk dat ik in eerste instantie het php script laat orderen en daarna de browser zelf. Dit is voor de gebruiker net zo makkelijk denk ik en scheelt elke keer de pagina vernieuwen (tenzij ik de techniek die je verderop noemt juist weet te implementeren, maar dat is voor later). Ik heb een leuk javascriptje hiervoor gevonden en getest, en het lijkt best erg mooi te werken

Cookies... Waarom was ik zoiets logisch vergeten? ik zal er eens over nadenken hoe het te doen

KIJK.... Zo'n buzzwoord zocht ik dat woord gaf mij een boel info bij de search, thanks, ben ik aan het uitzoeken!