PHP gegevens in een sessie

[Verwijderd]

Ik heb een sessie winkelwagen, daarin staan 3 producten!
Nu pak ik deze sessie uit met foreach()

Nou wil ik deze drie producten die nu uit de sessie worden getoond
met een INSERT INTO query in een tabel in de phpmyadmin database stoppen

Maarrr, hij maakt nu gewoon 3 nieuwe rijen aan in de tabel orders met dus drie nieuwe
order_id, maar hij moet gewoon 1 nieuwe rij aanmaken met in die rij die drie artikelen (artikel_id)

Weet iemand hoe dit moet?

[Gonadan]

Dit klinkt als een schoolopdracht

Misschien is het handig om even wat code en je datamodel te tonen.
Gebruik je alleen orders of ook orderregels?
Het is namelijk het makkelijkst om voor elk artikel_id een orderregel te maken die samen onder één order vallen.
Maar om je echt te kunnen helpen heb ik toch meer informatie nodig

[CodeCaster]

Je geeft wel erg weinig informatie over je database-layout.

En als je juist zou normaliseren, is het in meerdere regels opslaan juist logisch! Hoe breed wil je je databaseregel anders maken voor mensen die 50 producten in één keer bestellen?

Ik denk dat je even moet googlen op normalisatie, en je databaselayout herschrijven

offtopic:
En ik heb nog nooit gehoord van een phpMyAdmin database

[ Voor 10% gewijzigd door CodeCaster op 16-05-2006 09:41 ]

[Janoz]

Die drie artikelen zijn gewoon drie entiteiten. Wanneer je 1 order wilt hebben zul je een apparte order tabel moeten hebben met de order gegevens. De daadwerkelijke producten schrijf je dan in een orderregels tabel weg die je weer aan de order tabel koppelt.

Het lijkt me handig wanneer je je gaat verdiepen in het normaliseren van een datamodel en hoe dit gebruikt zou moeten worden.

[user109731]

Je kan toch in plaats van 3 query's uit te voeren er 1 van maken, na je foreach()-loop?

PHP:

$artikel_id = "";
foreach ($products as $productId) {
   $artikel_id .= $productId;
}
// store in db

edit: met de mensen hierboven: het is beter om dit anders op te lossen

[ Voor 19% gewijzigd door user109731 op 16-05-2006 09:42 ]

[NMe]

Gonadan schreef op dinsdag 16 mei 2006 @ 09:39:
Dit klinkt als een schoolopdracht

What's your point?

[Gonadan]

-NMe- schreef op dinsdag 16 mei 2006 @ 10:04:
[...]

What's your point?

offtopic:
what's yours

eigenlijk weinig, maar volgens het (oude) beleid hoor je dat te melden
als ik fout zat hoor ik dat graag (ook van de TS)

[Creepy]

Gonadan schreef op dinsdag 16 mei 2006 @ 10:10:
[...]

offtopic:
what's yours

eigenlijk weinig, maar volgens het (oude) beleid hoor je dat te melden
als ik fout zat hoor ik dat graag (ook van de TS)

offtopic:
Melden doen we tegenwoordig via de optie Topic Report Daarnaast mag een schoolopdracht in principe hier gevraagd worden mits natuurlijk aan de normale eisen van een topicstart worden voldaan.

En ontopic weer, alhoewel ik denk dat Janoz het antwoord al gegeven heeft.

[Gonadan]

Creepy schreef op dinsdag 16 mei 2006 @ 10:17:
[...]

offtopic:
Melden doen we tegenwoordig via de optie Topic Report Daarnaast mag een schoolopdracht in principe hier gevraagd worden mits natuurlijk aan de normale eisen van een topicstart worden voldaan.

En ontopic weer, alhoewel ik denk dat Janoz het antwoord al gegeven heeft.

offtopic:
oh sorry, ik bedoelde niet melden als in TR maar dat de TS het hoort aan te geven en dat vragen dan mag

Ik heb in een grijs verleden namelijk dezelfde opdracht gehad

CodeCaster schreef op dinsdag 16 mei 2006 @ 09:39:
Je geeft wel erg weinig informatie over je database-layout.

En als je juist zou normaliseren, is het in meerdere regels opslaan juist logisch! Hoe breed wil je je databaseregel anders maken voor mensen die 50 producten in één keer bestellen?

En als je dan ook nog eens de aantallen wilt bijhouden

Ik denk dat je even moet googlen op normalisatie, en je databaselayout herschrijven

offtopic:
En ik heb nog nooit gehoord van een phpMyAdmin database

Maar je weet heel goed wat hij bedoelt

[Verwijderd]

De database ziet er zo uit (NA normalisatie)

De volgende tabellen

afleverbon
afleverbon_regel --> De koppeling met de afleverbon tabel
artikelen
fac_regel --> De koppeling met de factuur tabel
factuur
klanten
koeriers
orders
personeel

Deze structuur had ik na de normalisatie van een factuur en een afleverbon die ik al had genormaliseerd voordat ik dit topic opende trouwens

[JHS]

Er mist een koppeling tussen de order en artikelen, order_regels, denk ik . Als die bestaat kan je bij een nieuwe order gewoon de relevante artikelen in de order_regels tabel invoeren.

[Gonadan]

Met deze structuur moet inderdaad elk artikel zijn eigen order hebben.
Als dat je bedoeling is omdat je dan alle orders aan één factuur hangt dan kan het.
Maar ik denk niet dat je dat wilt.
Dus zal je nog verder moeten normaliseren en ook een tabel order_regels maken.

Waarom zou je wel de factuur opslitsen in regels maar de orders niet?
Dan klopt het geheid niet

[storeman]

Een database order met bijbehorende orderregels tabel lijkt mij toch echt noodzaak:

code:

order-tabel
orderID    userID      orderDate

orderregels-tabel
orderRuleID    orderID     artID    number

[H@rry]

Verwijderd schreef op dinsdag 16 mei 2006 @ 09:36:
Ik heb een sessie winkelwagen, daarin staan 3 producten!
Nu pak ik deze sessie uit met foreach()

dus je heb 3 variabelen met waardes

Maarrr, hij maakt nu gewoon 3 nieuwe rijen aan in de tabel orders met dus drie nieuwe
order_id, maar hij moet gewoon 1 nieuwe rij aanmaken met in die rij die drie artikelen (artikel_id)

Je gaat dus 3x een insert into statement uitvoeren, wat resulteert in het toevoegen van 3 rijen. Wat ik uit je uitleg begrijp is dat je de hele winkelwagen in 1 vakje wil zetten.

Wat je dus zou moeten doen is zorgen dat je het in een bepaald formaat in 1 vakje ga zetten. Denk aan een scheidingsteken tussen artikel1 en artikel2. Voorbeeld:

1-muis-logitech:2-toetsenbord-microsoft:3.... enz.

Een andere manier lijkt mij niet mogelijk om het zootje bijmekaar te houden.

Een andere mogelijkheid: 3 rijen met dezelfde order_id. Je kan met een select statement de waarde van de hoogste order_id uitlezen en deze vervolgens bij een nieuwe order dus met 1 verhogen, en bij een extra artikel dus gelijk laten.

[ Voor 12% gewijzigd door H@rry op 16-05-2006 11:02 ]

[Voutloos]

007BigHarry schreef op dinsdag 16 mei 2006 @ 10:59:
Een andere manier lijkt mij niet mogelijk om het zootje bijmekaar te houden.

En een 'zootje' wil je niet, dus kan je beter eerst nog wat over het datamodel gaan nadenken.

Een andere mogelijkheid: 3 rijen met dezelfde order_id. Je kan met een select statement de waarde van de hoogste order_id uitlezen en deze vervolgens bij een nieuwe order dus met 1 verhogen, en bij een extra artikel dus gelijk laten.

Een SELECT statement om het hoogste id te achterhalen en die in een insert query met 1 verhogen is bad practice. Als je het niet in een transactie doet heb je kans op race condities. De tabel met de totale order kan gewoon een auto_increment id hebben.

[TeeDee]

007BigHarry schreef op dinsdag 16 mei 2006 @ 10:59:
Wat je dus zou moeten doen is zorgen dat je het in een bepaald formaat in 1 vakje ga zetten. Denk aan een scheidingsteken tussen artikel1 en artikel2. Voorbeeld:

1-muis-logitech:2-toetsenbord-microsoft:3.... enz.

Een andere manier lijkt mij niet mogelijk om het zootje bijmekaar te houden.

Dat lijkt mij niet de handigste oplossing. Tenzij de TS een aanpassing op zijn databank (dus een koppeltabel > order_regels is het inderdaad één van de weinige oplossingen.

Ik raad de TS toch echt even een herziening van het datamodel aan.

Een andere mogelijkheid: 3 rijen met dezelfde order_id.

Wat als het een auto_increment is?

Je kan met een select statement de waarde van de hoogste order_id uitlezen en deze vervolgens bij een nieuwe order dus met 1 verhogen, en bij een extra artikel dus gelijk laten.

Wat als in de tussentijd iemand anders een order plaatst?

[ Voor 5% gewijzigd door TeeDee op 16-05-2006 11:10 ]

[H@rry]

Voutloos schreef op dinsdag 16 mei 2006 @ 11:05:
Een SELECT statement om het hoogste id te achterhalen en die in een insert query met 1 verhogen is bad practice. Als je het niet in een transactie doet heb je kans op race condities. De tabel met de totale order kan gewoon een auto_increment id hebben.

Ja ok... beetje vieze oplossing

Maar wat eerder is gezegd is denk ik de beste oplossing.

Een veld order_id met daaraan de order_regel, zodat je dus met je auto_increment je order_id kan bepalen, en dan met order_regel een relatie heb naar de order_id. Dan heb je meteen het probleem met meerdere mensen te pakken.