DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
Je hebt alleen een tabel nodig (inhoud van de winkelwagen) die de gebruiker koppelt aan de gekozen producten en het aantal dat daarbij hoort. Oftwel, een userid, productid en number (aantal producten).quote:Op zondag 11 december 2005 20:15 schreef Swetsenegger het volgende:
Korte vraag,
zoals jullie weten ben ik met een webshop bezig.
Het winkelwagentje is een array, waarbij de key het produkt ID is en de value het aantal.
Nu moet ik deze gegevens op gaan slaan in de db. Zal ik simpelweg de array opslaan in een kolom? Het lijkt me een beetje 'vreemde' oplossing eigenlijk, maar aan de andere kant lijkt het me niet handig wanneer ik elk produkt van de bestelling afzonderlijk in een kolom of rij op ga slaan en vervolgens nog iets van een koppeltable moet maken voor de aantallen.
Mocht je het toch als array willen opslaan, dan kan dat het makkelijkst via serialize()
Hoezo?quote:Op zondag 11 december 2005 20:33 schreef existenz het volgende:
[..]
Dat laatste is dus wel de juiste manier, het gaat hier niet om "handig", want misschien gaat het opslaan zo wel sneller, maar het ophalen wel 10x zo traag!
Een array uit een kolom trekken kost geen zeeen van tijd dacht ik zo
De tabel moet dan wel userid, product id, order id en number worden.quote:Op zondag 11 december 2005 20:34 schreef JeRa het volgende:
[..]
Je hebt alleen een tabel nodig (inhoud van de winkelwagen) die de gebruiker koppelt aan de gekozen producten en het aantal dat daarbij hoort. Oftwel, een userid, productid en number (aantal producten).
Mocht je het toch als array willen opslaan, dan kan dat het makkelijkst via serialize()
Anders weet ik nooit welke rij bij welke bestelling hoort en een klant kan meerdere bestellingen plaatsen.
Hmz, zit ik weer met het ophogen van order_id. Of ik moet me in 'unique' mbt mysql gaan verdiepen. *zucht*.
Ophogen van order_id?quote:Op zondag 11 december 2005 20:34 schreef Swetsenegger het volgende:
[..]
De tabel moet dan wel userid, product id, order id en number worden.
Anders weet ik nooit welke rij bij welke bestelling hoort en een klant kan meerdere bestellingen plaatsen.
Hmz, zit ik weer met het ophogen van order_id. Of ik moet me in 'unique' mbt mysql gaan verdiepen. *zucht*.
Als een klant een nieuwe bestelling doet maak je (neem ik aan) een nieuwe entry in de tabel met orders. De id van die tabel is dan toch gewoon AUTO_INCREMENT? Vervolgens plaats je in de tabel met de inhoud van een bestelling de id van die bestelling
Je geeft als voorbeeld een tabel met de volgende kolommen:quote:Op zondag 11 december 2005 20:44 schreef JeRa het volgende:
[..]
Ophogen van order_id?
Als een klant een nieuwe bestelling doet maak je (neem ik aan) een nieuwe entry in de tabel met orders. De id van die tabel is dan toch gewoon AUTO_INCREMENT? Vervolgens plaats je in de tabel met de inhoud van een bestelling de id van die bestelling
user_id (de klant welke de bestelling doet)
product_id (het bestelde product)
number (het aantal van het bestelde product)
Dit betekent dus voor ELK product een rij en een verhoogd id van deze tabel, laten we die voor het gemak order_table_id noemen
Maar een klant kan toch meerdere produkten bestellen in 1 keer. En een klant kan een maand later weer produkten bestellen, zelfs dezelfde als een maand geleden.
Dus ik moet een kolom toevoegen met order_id. En elke keer als een klant een bestelling doet, moet ik dat order_id genereren en bij elk besteld product in de order tabel schrijven toch...
| 1 2 3 4 5 | 1 1 1 1 2 2 1 1 4 1 3 2 2 3 1 4 1 3 1 1 |
In dit voorbeeld is 1 en 2 één bestelling van 1 klant
3 is een bestelling van een andere klant
4 is wederom een bestelling van klant 1, maar WEL een nieuwe, bv een maand later.
Bij elke klant welke een bestlling doet, moet ik dus een unieke order_id hebben welke niet gewoon auto increment kan zijn in dit voorbeeld.
-edit- Ow wacht ff, jij bedoeld dat order_id in dit geval uit een tabel orders komt en dat bovenstaande tabel order inhoud is.
[ Bericht 2% gewijzigd door Swetsenegger op 11-12-2005 21:18:47 ]
Ik snap niet welk probleem je hebt
Je hebt een tabel users met daarin de klantennummers. FK = userid.
Je hebt een tabel orders met daarin de bestellingen. FK = orderid.
Je hebt een tabel products met daarin de producten. FK = productid
Je hebt een tabel winkelwagen (ofzo) met daarin de koppeling van bovenstaande drie tabellen én het aantal producten. Die ziet er dan toch als volgt uit?
id --> unieke verwijzing naar een bestelling in een winkelwagen (AUTO_INCREMENT PRIMARY KEY)
userid --> verwijzing naar klant (mag ook vaker voorkomen)
orderid --> verwijzing naar order. De 'id'-kolom van de tabel 'orders' is AUTO_INCREMENT
productid --> verwijzing naar het product
number --> aantal producten dat gewenst is
Wat is het probleem hiermee?
Je hebt een tabel users met daarin de klantennummers. FK = userid.
Je hebt een tabel orders met daarin de bestellingen. FK = orderid.
Je hebt een tabel products met daarin de producten. FK = productid
Je hebt een tabel winkelwagen (ofzo) met daarin de koppeling van bovenstaande drie tabellen én het aantal producten. Die ziet er dan toch als volgt uit?
id --> unieke verwijzing naar een bestelling in een winkelwagen (AUTO_INCREMENT PRIMARY KEY)
userid --> verwijzing naar klant (mag ook vaker voorkomen)
orderid --> verwijzing naar order. De 'id'-kolom van de tabel 'orders' is AUTO_INCREMENT
productid --> verwijzing naar het product
number --> aantal producten dat gewenst is
Wat is het probleem hiermee?
Zie de edit.quote:Op zondag 11 december 2005 21:18 schreef JeRa het volgende:
Ik snap niet welk probleem je hebt
Je hebt een tabel users met daarin de klantennummers. FK = userid.
Je hebt een tabel orders met daarin de bestellingen. FK = orderid.
Je hebt een tabel products met daarin de producten. FK = productid
Je hebt een tabel winkelwagen (ofzo) met daarin de koppeling van bovenstaande drie tabellen én het aantal producten. Die ziet er dan toch als volgt uit?
id --> unieke verwijzing naar een bestelling in een winkelwagen (AUTO_INCREMENT PRIMARY KEY)
userid --> verwijzing naar klant (mag ook vaker voorkomen)
orderid --> verwijzing naar order. De 'id'-kolom van de tabel 'orders' is AUTO_INCREMENT
productid --> verwijzing naar het product
number --> aantal producten dat gewenst is
Wat is het probleem hiermee?
Het ontging me even dat je een extra tabel bedoelde:
orderid --> verwijzing naar order. De 'id'-kolom van de tabel 'orders' is AUTO_INCREMENT
Ok, even pragmatisch. Klant pleurt van alles in zijn winkelwagen
Gaat naar bestellen.
Vult zijn klantgegevens in, die gaan in de user tabel.
Ik zet zijn user_id in de order tabel.
Ik zet user_id, order_id, product_id en number voor elk besteld product in de cart tabel.
Als ik de history van een klant wil laten bekijken door de beheerder, toon ik de order tabel WHERE user_id == de gekozen user.
Vervolgens kan ik op de order_id klikken om de specifieke bestelling in zijn geheel uit de cart tabel te trekken.
Mja, dat gaat toch werken? sorry dat ik even niet duidelijk aangaf dat ik het over een nieuwe koppeltabel had
Ja dat gaat perfect werkenquote:Op zondag 11 december 2005 21:32 schreef JeRa het volgende:
Mja, dat gaat toch werken? sorry dat ik even niet duidelijk aangaf dat ik het over een nieuwe koppeltabel had
Ik moet nog wel even goed nadenken, want orders moeten nogwel via mail bevestigt worden dus in de order tabel komt nog een activation kolom.
Indien niet geactiveerd moet ik dus wel de order EN de inhoud wissen.
Er komt natuurlijk nog veel meer bij kijken; ik noem even het tijdstip van aanmaken of het IP-adres van de klant. Maar dat is aan jouquote:Op zondag 11 december 2005 21:43 schreef Swetsenegger het volgende:
[..]
Ja dat gaat perfect werken
Ik moet nog wel even goed nadenken, want orders moeten nogwel via mail bevestigt worden dus in de order tabel komt nog een activation kolom.
Dat kan met één DELETE door te joinen of meerdere DELETEs die je binnen een LOCK TABLES / UNLOCK TABLES zet.quote:Indien niet geactiveerd moet ik dus wel de order EN de inhoud wissen.
Ja, dat heb ik allemaal op een rijtje ivm tweedehandsboek, waarbij gebruikers ook hun aanmelding moeten bevestigen. Er moet dus ook een datum/tijd in de order tabelquote:Op zondag 11 december 2005 21:49 schreef JeRa het volgende:
[..]
Er komt natuurlijk nog veel meer bij kijken; ik noem even het tijdstip van aanmaken of het IP-adres van de klant. Maar dat is aan jou
Bedankt voor de tip, daar ga ik mee stoeien.quote:Dat kan met één DELETE door te joinen of meerdere DELETEs die je binnen een LOCK TABLES / UNLOCK TABLES zet.
Andere vraag.
Klanten stoppen het een en ander in de winkelwagen en gaan bestellen. Indien ze al eerder besteld hebben kunnen ze vervolgens inloggen zodat de voorgaande gegevens direkt bekend zijn. Indien het een nieuwe klant is, moet deze z'n NAW gegevens invullen.
Nu wil ik op deze NAW gegevens pagina nadat een en ander succesvol is ingevuld en naar db is geschreven de klant direkt automatisch inloggen. Maar vanuit PHP Kan ik volgens mij niet automatisch de juiste gegevens (inlognaam en wachtwoord welke bij aanmelden is opgegeven) POSTen naar inlog.php. Uiteraard kan het wel met GET, maar dat lijkt me niet zo veilig
Dat ligt aan je inlogsysteem. Stel, je hebt een sessie-variabele genaamd 'userid' waarvoor geldt dat als userid groter is dan 0 de user is ingelogd als klant nummer #userid. Dan kun je na het toevoegen van de NAW-gegevens in de usertabel de primary key ophalen (mysql_insertid) en die in je sessie-variabele zetten. Voila, user ingelogdquote:Op zondag 11 december 2005 21:56 schreef Swetsenegger het volgende:
Nu wil ik op deze NAW gegevens pagina nadat een en ander succesvol is ingevuld en naar db is geschreven de klant direkt automatisch inloggen. Maar vanuit PHP Kan ik volgens mij niet automatisch de juiste gegevens (inlognaam en wachtwoord welke bij aanmelden is opgegeven) POSTen naar inlog.php. Uiteraard kan het wel met GET, maar dat lijkt me niet zo veilig
Maar dat is een klein risico als er meerdere gebruikers min of meer teglijk aanmelden. mysql_insertid kan dan hoger zijn dan degene welke ik voor deze klant bedoel toch?quote:Op zondag 11 december 2005 22:00 schreef JeRa het volgende:
[..]
Dat ligt aan je inlogsysteem. Stel, je hebt een sessie-variabele genaamd 'userid' waarvoor geldt dat als userid groter is dan 0 de user is ingelogd als klant nummer #userid. Dan kun je na het toevoegen van de NAW-gegevens in de usertabel de primary key ophalen (mysql_insertid) en die in je sessie-variabele zetten. Voila, user ingelogd
Of ik moet met lock table gaan werken natuurlijk.
Nope, mysql_insert_id() geeft de waarde terug van de laatste INSERT-operatie van de huidige thread. Zolang je users niet weten hoe ze op de webserver threads moeten overnemen is dat vrij veiligquote:Op zondag 11 december 2005 22:04 schreef Swetsenegger het volgende:
[..]
Maar dat is een klein risico als er meerdere gebruikers min of meer teglijk aanmelden. mysql_insertid kan dan hoger zijn dan degene welke ik voor deze klant bedoel toch?
Of ik moet met lock table gaan werken natuurlijk.
Nu lees ik op die pagina ook dat je LAST_INSERT_ID kunt gebruiken dat is eigenlijk wel heel handig, gegeven dat dat ook de laatste insert id van de huidige thread is.
edit: nee dus.
mysql_insert_id() it is dusquote:Note: The value of the MySQL SQL function LAST_INSERT_ID() always contains the most recently generated AUTO_INCREMENT value, and is not reset between queries.
Het verschil tussen beide ontging me even, maar ik lees dat last_insert_id niet gereset wordt tussen queries en dus niet thread gerelateerd is. Begrijp ik het zo goed?quote:Op zondag 11 december 2005 22:05 schreef JeRa het volgende:
[..]
Nope, mysql_insert_id() geeft de waarde terug van de laatste INSERT-operatie van de huidige thread. Zolang je users niet weten hoe ze op de webserver threads moeten overnemen is dat vrij veilig
Nu lees ik op die pagina ook dat je LAST_INSERT_ID kunt gebruiken dat is eigenlijk wel heel handig, gegeven dat dat ook de laatste insert id van de huidige thread is.
edit: nee dus.
[..]
mysql_insert_id() it is dus
Maar ik kan dus save mysql_insert_id gebruiken direkt na de query welke de klantgegevens in de DB zet.
Klopt.quote:Op zondag 11 december 2005 22:11 schreef Swetsenegger het volgende:
[..]
Het verschil tussen beide ontging me even, maar ik lees dat last_insert_id niet gereset wordt tussen queries en dus niet thread gerelateerd is. Begrijp ik het zo goed?
Klopt ook.quote:Maar ik kan dus save mysql_insert_id gebruiken direkt na de query welke de klantgegevens in de DB zet.
De combinatie orderid, productid is uniek, dus die kan je als PK gebruiken.quote:Op zondag 11 december 2005 21:18 schreef JeRa het volgende:
id --> unieke verwijzing naar een bestelling in een winkelwagen (AUTO_INCREMENT PRIMARY KEY)
userid --> verwijzing naar klant (mag ook vaker voorkomen)
orderid --> verwijzing naar order. De 'id'-kolom van de tabel 'orders' is AUTO_INCREMENT
productid --> verwijzing naar het product
number --> aantal producten dat gewenst is
Ik neem aan dat in de tabel met bestellingen bij een order een userid staat. Dan is de kolom userid in deze tabel overbodig.
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
PK?quote:Op zondag 11 december 2005 22:30 schreef SuperRembo het volgende:
[..]
De combinatie orderid, productid is uniek, dus die kan je als PK gebruiken.
Ik neem aan dat in de tabel met bestellingen bij een order een userid staat. Dan is de kolom userid in deze tabel overbodig.
Ja ik had me inderdaad al bedacht dat user_id ook nog een keer in de inhoud tabel toevoegen ietwat overdreven is die moet bestaan uit inhoud_id, order_id, product_id en number
Klopt helemaal. Over die primary key, ikzelf vind het altijd handig om in elke tabel een unieke waarde te hebben die ik kan toekennen aan elke entry, vandaar ook als je nog een koppeling wilt leggen tussen een product uit een bestelling en iets anders is het handig als je niet met twee variabelen hoeft te klooien.quote:Op zondag 11 december 2005 22:30 schreef SuperRembo het volgende:
[..]
De combinatie orderid, productid is uniek, dus die kan je als PK gebruiken.
Ik neem aan dat in de tabel met bestellingen bij een order een userid staat. Dan is de kolom userid in deze tabel overbodig.
Nav JeRa begreep ik 'mquote:
Simpele vraag,
Wanneer ik een UPDATE query uitvoer met data welke gelijk is aan de huidige data, krijg je een sql error.
Is die error eenvoudig op te vangen en te vervangen door een specifieke string?
Ik niets , maar ik heb klantgegevens. En als klanten op edit drukken, vul ik de gegevens al voor ze in in het formulier. Maar als ze vervolgens op submit rammen zonder iets te veranderen, ga ik dus een UPDATE query draaien met dezelfde gegevens als de huidige. Dat geeft een sql error/notice.quote:Op zondag 11 december 2005 23:22 schreef Light het volgende:
Huh? Wat voor query doe je dan?
MySQL (phpmyadmin) geeft bij mij gewoon een melding dat er 0 rijen zijn aangepast. Geen foutmeldingen ofzo.
Hmmmz. Dat is weer zo'n vaag iets van MySQLquote:Op zondag 11 december 2005 23:30 schreef Light het volgende:
MySQL (phpmyadmin) geeft bij mij gewoon een melding dat er 0 rijen zijn aangepast. Geen foutmeldingen ofzo.
Als je dus 2x het statement "UPDATE MyTable SET name = 'Foo' WHERE id = 1" uitvoert, dat krijg je de eerste keer affected rows = 1, maar daarna affected rows = 0
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
MySQL redeneert dat als er geen velden worden aangepast, dat er dan ook geen rijen worden aangepast. En het schijnt sneller te zijn om niet opnieuw te schrijven als de waarde voor en na de update gelijk is. Klinkt op zich ook nog wel logisch, ergensquote:Op zondag 11 december 2005 23:43 schreef SuperRembo het volgende:
[..]
Hmmmz. Dat is weer zo'n vaag iets van MySQL
Als je dus 2x het statement "UPDATE MyTable SET name = 'Foo' WHERE id = 1" uitvoert, dat krijg je de eerste keer affected rows = 1, maar daarna affected rows = 0
Het kost veel minder tijd om zo'n waarde niet weg te schrijven (indices hoeven dan ook niet bijgewerkt te worden, query/block cache kan blijven bestaan, etc). Echter zou het wel wat netter zijn als affected rows 1 teruggaf jaquote:Op zondag 11 december 2005 23:43 schreef SuperRembo het volgende:
[..]
Hmmmz. Dat is weer zo'n vaag iets van MySQL
Als je dus 2x het statement "UPDATE MyTable SET name = 'Foo' WHERE id = 1" uitvoert, dat krijg je de eerste keer affected rows = 1, maar daarna affected rows = 0
Je moet dan wel eerst de oude en de nieuwe gegevens vergelijken, dat kost ook tijd.quote:Op zondag 11 december 2005 23:46 schreef Light het volgende:
[..]
MySQL redeneert dat als er geen velden worden aangepast, dat er dan ook geen rijen worden aangepast. En het schijnt sneller te zijn om niet opnieuw te schrijven als de waarde voor en na de update gelijk is. Klinkt op zich ook nog wel logisch, ergens
Het lijkt me geen standaard gedrag. Is dat is MySQL 5 ook zo?
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
Ja (heb het hier draaien). Weliswaar niet in de strict-modus, misschien dat dat wat uitmaakt?quote:Op zondag 11 december 2005 23:54 schreef SuperRembo het volgende:
[..]
Je moet dan wel eerst de oude en de nieuwe gegevens vergelijken, dat kost ook tijd.
Het lijkt me geen standaard gedrag. Is dat is MySQL 5 ook zo?
