[PHP] Key en Value uit Array imploden naar string

[Verwijderd]

He jongens,

Ik ben nu al een tijdje bezig met een probleem dat ik heb.
Op een website die ik aan het ontwikkelen ben gebruik in een Array.
In deze array sla ik dingen op -> een ID en een HOEVEELHEID.

Wanneer ik de array print krijg ik iets als: [4][2] .. dus.. van ID 4 heb ik er 2.

Nu heb ik al geprobeerd om met implode() de array te imploden, maar dan krijg ik alleen de value terug en niet de key, terwijl die key net zo belangrijk is.

Ik kan wel de key imploden en de value imploden, alleen dan kan ik ze niet meer naast elkaar zetten in de string.

Ik had eigenlijk het idee om de string op te slaan als 4:2,8:1,43:1.

Neem aan dat dit mogelijk is, maar ik kom niet op weg, kan iemand me wellicht helpen?
Alvast bedankt!

[Jaap-Jan]

zelf doen met een foreach loop?

[Verwijderd]

Je kan het op verschillende manieren doen, dit is denk ik de makkelijkste:

code:

while(list($key,$value)=each($array)){
    //hier kun je met $key en $value imploden of wat dan ook
}

Of het ook efficient is hangt een beetje af waar en hoe je het gaat gebruiken (bij kleine arrays zou ik me niet teveel druk maken om de snelheid/effecientie van de functie).

[pedorus]

Anders gewoon serialize gebruiken? Waar(voor) ga je het eigenlijk opslaan? Data die op deze manier is opgeslagen is niet goed doorzoekbaar..

[mithras]

Voor de performance kan je beter met doorzoeken een array gebruiken. Als je hem wil opslaan (vandaar die stap naar een string denk ik) moet je gewoon serializen. Daar is het voor bedoeld. Met unserialize krijg je je data weer terug

[Verwijderd]

Ja ik wil hem inderdaad in een MySQL database schrijven.
Het is als het ware een bestellijst. De ID's van producten en het aantal dat mensen bestellen.

Ik zou dus het liefst de string een beetje leesbaar willen houden. Er moet namelijk met die informatie nog redelijk wat gedaan worden. Facturen moeten nog gegenereerd worden, eventueel pakbonnen etc.

hoe wordt de informatie opgeslagen dan als ik serialze ga gebruiken? Ik kon daar bij de voorbeelden niet echt inzicht in krijgen.

[Snake]

Ge moet niet kijken hoe het wordt opgeslagen als ge serialiseerd, als ge unserialized krijgt ge u data identiek terug.

[Jaap-Jan]

Verwijderd schreef op woensdag 21 mei 2008 @ 22:18:
Ja ik wil hem inderdaad in een MySQL database schrijven.
Het is als het ware een bestellijst. De ID's van producten en het aantal dat mensen bestellen.

Ik zou dus het liefst de string een beetje leesbaar willen houden. Er moet namelijk met die informatie nog redelijk wat gedaan worden. Facturen moeten nog gegenereerd worden, eventueel pakbonnen etc.

hoe wordt de informatie opgeslagen dan als ik serialze ga gebruiken? Ik kon daar bij de voorbeelden niet echt inzicht in krijgen.

Wat bedoel je met 'als het ware'? Volgens mij heb je geen methode nodig om data weg te schrijven, maar een beter datamodel.

[BarthezZ]

Verwijderd schreef op woensdag 21 mei 2008 @ 22:18:
Ja ik wil hem inderdaad in een MySQL database schrijven.
Het is als het ware een bestellijst. De ID's van producten en het aantal dat mensen bestellen.

Ik zou dus het liefst de string een beetje leesbaar willen houden. Er moet namelijk met die informatie nog redelijk wat gedaan worden. Facturen moeten nog gegenereerd worden, eventueel pakbonnen etc.

hoe wordt de informatie opgeslagen dan als ik serialze ga gebruiken? Ik kon daar bij de voorbeelden niet echt inzicht in krijgen.

Als je met een database aan de slag gaat is wat je wilt not the way to go
Je kan beter aan de slag gaan met een koppeltabel, als ik het goed lees is het een standaard n:m relatie. Hoe je dit aanpakt valt veel over te vinden.

[pedorus]

Hm, een bestellijst op deze manier opslaan lijkt me niet zo handig. Het lijkt me beter om hier een aparte tabel van te maken (aankoopId, productId, hoeveelheid). Dan kun je veel makkelijker vragen beantwoorden zoals:
"Geef het totaal aantal verkochte producten per product"
"Geef de klanten die product x besteld hebben"
etc.

[Verwijderd]

Ik maak op deze manier toch gebruik van een koppeltabel?
Ik wil enkel de ID's en het aantal wat daarbij hoort in een bestellingen tabel stoppen.
Aan de hand van die gegevens wil ik dan in de database op zoeken welke producten erbij horen.

Toen ik mijn reactie postte, toen zag ik de reactie van Pedorus, dat is inderdaad de manier om het te doen! Dan moet ik alsnog de informatie uit de array halen, maar dat is geen probleem. Lijkt me?

[ Voor 30% gewijzigd door Verwijderd op 21-05-2008 22:32 ]

[Verwijderd]

Gebruik maar een koppeltabel Want wat ga je doen als je wilt weten hoe vaak een product is verkocht bijvoorbeeld?

edit
Wat betreft die array, ik denk dat je beter een multidimensionale array had kunnen gebruiken. ID en hoeveelheid onder dezelfde key dus.

[ Voor 38% gewijzigd door Verwijderd op 21-05-2008 22:34 ]

[Verwijderd]

Ik heb nu hetvolgende om de extra aangemaakte tabel te vullen:

PHP:

foreach ($_SESSION["winkelwagen"] as $WijnID => $Aantal)
    {
        $OrderItem = "INSERT INTO tblOrderItem (OrderID, WijnID, Aantal) VALUES ('".$HuidigOrderNummer."', '".$WijnID."', '".$Aantal."')";
        $AddOrderItem = mysql_query($OrderItem);
    }

Het werkt :-) Nu alleen nog even iets inbouwen dat ie met de refresh van de pagina niet alles dubbel toevoegd.

Bedankt voor jullie hulp!

[ Voor 2% gewijzigd door Verwijderd op 21-05-2008 23:13 . Reden: produktid -> wijnid ]

[Jaap-Jan]

edit:
slecht op de code gelet

[ Voor 86% gewijzigd door Jaap-Jan op 21-05-2008 23:06 ]

[Voutloos]

Verwijderd schreef op woensdag 21 mei 2008 @ 22:53:
Het werkt :-) Nu alleen nog even iets inbouwen dat ie met de refresh van de pagina niet alles dubbel toevoegd.

POST voor niet idempotente acties, unique constraints op je winkelmandje tabel, en wat triviale checks daar om heen.

[MueR]

En gewoon altijd netjes redirecten na het afhandelen van een post tbh. Dan krijg je ook geen datavervuiling doordat er via refresh dubbel gepost wordt.

[Cartman!]

Vergeet niet dat soms na een tijdje producten verwijderd worden uit je database maar waar nog wel naar gelinkt wordt in je ordertabel. Dan kun je dus de productinformatie nooit meer terugkrijgen. Dus of zorgen dat je producten bij verwijderen alleen een flag krijgen dat ze verwijderd zijn of ook de productnaam opslaan. Als je hier na een jaar achterkomt ben je de zak namelijk.

[Janoz]

Naast bovenstaande kanttekening is er nog 1. Wat gebeurt er met bestaande facturen wanneer je de prijs van een product wijzigt?

[Cartman!]

Inderdaad, dat is er nog zo een

[glashio]

Niet ingaande over de functionaliteit van je Orderprocess.

Zocht je dit

code:

$result = vsprintf(($s = $arr ? '%s:' : '') . implode(",$s", array_keys($arr)), $arr);

alhoewel een foreach lus eleganter is

[Verwijderd]

Dus of zorgen dat je producten bij verwijderen alleen een flag krijgen dat ze verwijderd zijn of ook de productnaam opslaan.

De producten zijn, als ze online zijn IsActief = true, indien niet natuurlijk false.. ze verdwijnen dan ook niet uit de database.

Janoz schreef op donderdag 22 mei 2008 @ 09:07:
Naast bovenstaande kanttekening is er nog 1. Wat gebeurt er met bestaande facturen wanneer je de prijs van een product wijzigt?

De prijs van de factuur wordt opgeslagen in de tabel 'order'. Hier zet ik prijsexclbtw, verzendkosten, btw en de prijsinclbtw in zoals ie op dat moment is.

Heb wel redelijk over dit soort dingen nagedacht, alleen ik dacht dat ik gewoon een array in mysql kon zetten :-) De oplossing die jullie geven is natuurlijk veel beter, had er zelf nog niet over nagedacht.

[Janoz]

Verwijderd schreef op donderdag 22 mei 2008 @ 12:25:
De prijs van de factuur wordt opgeslagen in de tabel 'order'. Hier zet ik prijsexclbtw, verzendkosten, btw en de prijsinclbtw in zoals ie op dat moment is.

Wat gebeurt er wanneer je de hele factuur nog eens uitdraait?

Waarom sla je een berekend veld op dat ook uit de twee andere velden af te leiden is?

Wat gebeurt er wanneer je producten met verschillende btw percentages gaat verkopen?

[Verwijderd]

Janoz schreef op donderdag 22 mei 2008 @ 13:25:
[...]

Wat gebeurt er wanneer je de hele factuur nog eens uitdraait?

Waarom sla je een berekend veld op dat ook uit de twee andere velden af te leiden is?

Wat gebeurt er wanneer je producten met verschillende btw percentages gaat verkopen?

Ze printen ze maar 1 keer uit, en anders dan komt er een berekening van de nieuwe en oude prijs, dan is er een soort van korting.

Ik sla die zo op, geen idee.. is net zo handig als naderhand berekenen hehe.

Verschillende percentages btw, het is een wijnwinkel, dat wordt met 19% berekend. Als ze een meer uitgebreidere website wilden hebben, hadden ze mij niet moeten aannemen en zijn ze waarschijnlijk voor 200 euro ook niet klaar ;-)

[Verwijderd]

Dan hoop ik ook dat je ze hebt uitgelegd dat je dat op die manier voor ze gaat doen. Zo gaat over een paar maanden bijvoorbeeld de btw omhoog, zou een beetje lullig zijn als ze er dan achter komen hoe jij het in elkaar hebt gezet en dat er dan ineens beperkingen aan zitten waar ze niets van wisten. Ik ga er even van uit dat die wijnwinkel geen it-verstand heeft en dus geen idee heeft hoeveel zoiets zou moeten kosten, misschien verwacht hij voor die 200 euro juist wel iets dat helemaal top in elkaar zit. Voor 200 euro hadden ze bij wijze van spreke ook een kant-en-klare webwinkel kunnen kopen namelijk (met een template van 10-50 euro erbij is een dergelijke klant al vaak erg tevreden).

[Verwijderd]

Mjah.. gelukkig staat BTW wel gewoon in een functie, dus dat is zo aan te passen

[Verwijderd]

Verwijderd schreef op donderdag 22 mei 2008 @ 15:00:
Mjah.. gelukkig staat BTW wel gewoon in een functie, dus dat is zo aan te passen

Ja voor jou ja . Maar het is natuurlijk een beetje raar dat je een dergelijke wisselende variabele alleen aan kan passen via de source. Bouw er dan een mooie admin omheen die het de opdrachtgever ook kan laten doen .

Overigens, ik krijg niet het idee dat je het plan al helemaal goed hebt uitgedacht. Heb je al een soort van ontwerp gemaakt met wat je er precies in wilt stoppen en hoe, en heb je dat al doorgesproken met je opdrachtegever? Communicatie is altijd erg belangrijk, omdat de klant vaak pas weet wat hij wilt als hij weet wat hij niet wilt

[.oisyn]

Verwijderd schreef op donderdag 22 mei 2008 @ 14:13:
Ik sla die zo op, geen idee.. is net zo handig als naderhand berekenen hehe.

Nee, minder handig. Nu moet je die andere waarde ook gaan maintainen als de ene wijzigt.

Verwijderd schreef op vrijdag 23 mei 2008 @ 07:44:
[...]


Ja voor jou ja . Maar het is natuurlijk een beetje raar dat je een dergelijke wisselende variabele alleen aan kan passen via de source.

Dat heet jobsecurity

[ Voor 34% gewijzigd door .oisyn op 23-05-2008 11:14 ]

[mocean]

Als je dat BTW verhaal netjes aan wilt pakken, maak je een tabel met tarieven (hoog/laag/0). En elk product valt in een tarief. Bij een buitenlandse order gelden weer andere regels afhankelijk van het land (EU/daarbuiten). En stel ze gaan wijn-boeken/gidsen verkopen, dan vallen die in het 6% tarief. En verder natuurlijk alle prijsinfo en BTW per tarief opslaan bij een order: achteraf kunnen de percentages en prijzen wijzigen, maar voor oude orders geldt dat niet.

[Verwijderd]

uuhmm boeken en gidsen vallen toch ook gewoon binnen 19%? enkel levensmiddelen en dergelijke, dingen die worden gezien als primaire levensbehoeften vallen onder 6% BTW.

[NetForce1]

nope: http://www.belastingdiens...b09-107.html#P1108_128009

[mocean]

NetForce1 schreef op zaterdag 24 mei 2008 @ 11:14:
nope: http://www.belastingdiens...b09-107.html#P1108_128009

Om die reden kan je dus ook orders krijgen, met meerdere tarieven op 1 factuur. Dus elke order-regel zou een btw-percentage moeten hebben. En er valt dus meer in het 6% tarief dan je zou denken!