Populaten winkelmand

[Anoniem: 426269]

In mijn e-commerce script gebruik ik om een winkelwagen te vullen de volgende variabelen in een tabel:

cart_idfk (gelinkt aan het cookie id van de bezoeker)
item_idfk (gelinkt aan het id van een product)
qty (het aantal van die producten)
size (de maat van het product)
color (de kleur van het product)

Het heeft altijd gewerkt maar ik vroeg me af of ik deze tabel niet moet uitbreiden met een autonummering id voor elk record. Misschien dat het daarmee een betere of makkelijkere manier is om de winkelwagen up te daten?

Want als ik nu bijvoorbeeld de aantallen van producten in de mand wil updaten dan loop ik over alle producten in de mand als volgt:

SQL:

UPDATE cartitem
    SET qty = $newqty
    WHERE cart_idfk = '$cookie_var'
        AND item_idfk = '$row[item_idfk]'
        AND size = '$row[size]'
        AND color =  '$row[color]'

Wellicht met een uniek id kan het als volgt:

SQL:

UPDATE cartitem
    SET qty = $newqty
    WHERE id = $row[id]

Dat scheelt toch, of zie ik wat over het hoofd?

[ Voor 3% gewijzigd door RobIII op 30-01-2013 00:35 . Reden: Code tags toegevoegd + indenting voor leesbaarheid ]

[RobIII]

Het kan ja. Of je er iets mee op schiet is een tweede; als je velden uit je voorbeeld, op qty na, een compound/composite key zijn kun je die ook prima gebruiken. Met een autoincrementing id worden je queries wat makkelijker te schrijven. Of 't in performance gaat schelen (laat staan meetbaar) is erg afhankelijk van of indexes je gebruikt (en hoe/welke). Meten == weten; gewoon implementeren en profilen. My guess (op 't eerste gezicht): tenzij je big-ass shopping-carts hebt zal het verschil in uitvoersnelheid verwaarloosbaar zijn (mits, again, je een goede index hebt staan op cart_idfk en de overige betrokken velden, waarbij je dus wel dient te letten op de volgorde van de velden in de index).

Je zult in ieder geval moeten definiëren wat je nou precies bedoelt met "Dat scheelt toch". Bedoel je dat 't extra typewerk scheelt? Dat het beter/slechter/anders zou performen? Dat het meer/minder schijfruimte/memory kost? Wat?

Persoonlijk hang ik, in de meeste gevallen, overal een surrogate key aan (waar je dus op doelt). Maar, if it ain't broken, don't fix it; zoals ik al aangeef: ik verwacht niet dat 't de investering in tijd/kosten/whatnot waard is om aan te passen als je geen daadwerkelijk probleem hebt (én dat het, bewezen/gemeten, blijkt te liggen aan je huidige opzet). Mocht het, daadwerkelijk, een probleem zijn dan zou ik voordat ik ging verbouwen eerst eens (héél) goed kijken naar m'n indexen voordat ik verder ging denken.

Psst; voor 't posten van code hebben we code tags

[ Voor 71% gewijzigd door RobIII op 30-01-2013 01:01 ]

[Anoniem: 426269]

Dank je. Ik heb inmiddels de key toegevoegd. Ook al zal ik er waarschijnlijk niets van merken qua snelheid, de code is in elk geval wat overzichtelijker nu.

Ik was er toch mee bezig en had juist eerst wat foutmeldingen (het was al laat), maar na het toevoegen van de key werkte alles meteen. En ik heb autonummering gebruikt.

Ja oeps, die code tags zal ik voortaan altijd gebruiken.

Nog 1 vraagje: Als een bestelling gelukt is, leeg ik altijd de winkelmand voor de betreffende cookie. Maar als ze niet bestellen blijft die tabel natuurlijk in de loop der tijd vol hangen met records. Cleanen jullie die tabellen met af en toe een bestandje automatisch draaien? Of laten jullie het aan de beheerder over om die tabel handmatig op te schonen (via het CMS)?

[ Voor 32% gewijzigd door Anoniem: 426269 op 30-01-2013 04:45 ]

[D-Raven]

Wie houd je tegen om als er niet besteld wordt, en je leegt je cookie, om dat ook niet de records in de tabel op te ruimen?

[RobIII]

Anoniem: 426269 schreef op woensdag 30 januari 2013 @ 04:39:
Nog 1 vraagje: Als een bestelling gelukt is, leeg ik altijd de winkelmand voor de betreffende cookie. Maar als ze niet bestellen blijft die tabel natuurlijk in de loop der tijd vol hangen met records. Cleanen jullie die tabellen met af en toe een bestandje automatisch draaien? Of laten jullie het aan de beheerder over om die tabel handmatig op te schonen (via het CMS)?

Alles kan. Je kunt een cronjobje draaien op X interval die mandjes ouder dan Y wegkiepert (zeg, interval 1x daags, ouder dan 30 dagen, ik roep maar wat). Je kunt ook een cronjob achterwege laten en bijv. bij elke X^e order (als er wél besteld wordt) "on completion" even een query'tje loslaten op je winkelmandjes om oude meuk op te ruimen. En je kunt 't ook alleen in schrikkeljaren doen wanneer 't volle maan is en er meer dan 50 mensen met bloedgroep O zijn geboren op een vrijdag in die week. Who cares

Eén ding is zeker: zoiets liet ik niet aan mensen over. Het wordt geheid door de jaren heen vergeten ofzo en heel je tabel loopt vol, backups worden onnodig groot enz. Nu zal 't voor een winkelmandjestabelletje wel los lopen; ik doel meer op 't algemene principe: als je dergelijke 'periodieke cleanups' kunt automatiseren door 't te schedulen, in batchfiles te zetten of aan de rookmelder te koppelen: doen. Mensen zijn slordig.

[ Voor 17% gewijzigd door RobIII op 30-01-2013 10:30 ]

[Anoniem: 426269]

@ Deathraven: Bij niet bestellen leegde ik het cookie nog niet. Want misschien ging er wel wat fout en wil de klant nogmaals een poging te doen om te bestellen en dan zou de hele inhoud van zijn winkelmand weg zijn. En dat lijkt me niet handig/commercieel dus vandaar. Maar bij het legen van de cookie natuurlijk altijd meteen ook de records in de tabel opruimen ja.

Maar na een week of maand de tabel opruimen op de manier van RobIII bij elke Xe order lijkt me wel een goede. Dan moet ik nog wel een datum in de winkelmandtabel toevoegen en meegeven bij elke insert/wijziging van een record.

[ Voor 4% gewijzigd door Anoniem: 426269 op 30-01-2013 13:26 ]

[RobIII]

Anoniem: 426269 schreef op woensdag 30 januari 2013 @ 13:25:
en meegeven bij elke insert/wijziging van een record.

Onnodig; gewoon een createdate veld met als default value een Now() en je bent er. Mandjes ouder dan X tijd mikker je dan gewoon weg. Eventueel zou je nog een lastupdated kunnen bijhouden om zo mandjes "levend te kunnen houden" door er minimaal binnen X tijd een wijziging in aan te brengen. En dat zou je, zonder RDBMS-specifieke features (triggers, CDC(?), row/data versioning, ...?) te gebruiken, in een eigen update-query'tje kunnen doen idd.

[ Voor 32% gewijzigd door RobIII op 30-01-2013 23:40 ]

[Anoniem: 426269]

O ja, dat is beter. Thanks!