[PHP/(My)SQL] voor dummies - Deel 17

quote:

Op zaterdag 10 december 2005 21:25 schreef SkaterSam het volgende:
Grrmmmbllll zal je altijd zien, zoiets simpels... danku

Dat soort dingen heb ik ook heel veel hoor schaam je niet
* wobbel phpt er lekker op los nu


Vergeet je PHPMyAdmin trouwens niet te updaten!! Zit groot security leak in!

[ Bericht 5% gewijzigd door wobbel op 10-12-2005 21:45:21 ]

quote:

Op zaterdag 10 december 2005 20:43 schreef SkaterSam het volgende:
Grmmbblll, op een of andere manier krijg ik nooit errors te zien, maar telkens een standaard blanke pagina, maar dat terzijde...

Heb je wel display_errors = On staan in php.ini?

quote:

Op zaterdag 10 december 2005 22:46 schreef SuperRembo het volgende:

[..]

Heb je wel display_errors = On staan in php.ini?

Ik heb tijdens ontwikkeling altijd error_reporting(E_ALL); aanstaan, maar als ik een curly bracket vergeet krijg ik ook een lege page te zien en geen foutmelding

quote:

Op zaterdag 10 december 2005 22:53 schreef Swetsenegger het volgende:

[..]

Ik heb tijdens ontwikkeling altijd error_reporting(E_ALL); aanstaan, maar als ik een curly bracket vergeet krijg ik ook een lege page te zien en geen foutmelding

Jup, dat heb ik dus ook ja, dus moet ik altijd de fouten uit de error.log lezen, verder niet zo'n probleem, wel een beetje onhandig

quote:

Op zaterdag 10 december 2005 22:46 schreef SuperRembo het volgende:

[..]

Heb je wel display_errors = On staan in php.ini?

Dank, ik niet

quote:

Op zaterdag 10 december 2005 22:54 schreef SkaterSam het volgende:

[..]

Jup, dat heb ik dus ook ja, dus moet ik altijd de fouten uit de error.log lezen, verder niet zo'n probleem, wel een beetje onhandig

weet iemand een leuke windows apache log file parser?
zou ik wel handig vinden..

Ok, komt ie dan...ik ben bezig met een Forum en het is circa 1½ jaar geleden dat ik met joins ofzo heb gewerkt in een query. Dat ik dus gegevens uit 2 tabellen haal dmv 1 query.

Wat is het doel? Ik wil informatie uit 2 tabellen ophalen. Ik heb nu de tabel ForumTopics,waarmee ik een loop maak om alle topics uit te poepen. Opzich werkt dat prima. Nu heb ik ook een tabel genaamd ForumMessages met alle berichten (ook het eerste bericht). Nu wil ik dus de datum van het laatste geplaatste bericht uit ForumMessages weergeven in de loop van ForumTopics. Dus achter elke topic wanneer er voor het laatst gereageerd is.
Ook wil ik het aantal records uit ForumMessages weten bij het bijbehorende IdTopic uit de loop.

M'n algemene vraag is dus: Kan dit met minder query's? (alleen als het sneller is)
Wat heb ik nu? Ik heb het nu dmv 3 aparte query's. Lekker brak dus.
Zie mijn code hieronder:

http://194.126.173.14/~xostnl/tccl/fokcode.phps

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.

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.

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()

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!

Hoezo?
Een array uit een kolom trekken kost geen zeeen van tijd dacht ik zo

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()

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*.

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*.

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

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

Je geeft als voorbeeld een tabel met de volgende kolommen:

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...



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?

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?

Zie de edit.
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

quote:

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

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.

Indien niet geactiveerd moet ik dus wel de order EN de inhoud wissen.

quote:

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.

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

quote:

Indien niet geactiveerd moet ik dus wel de order EN de inhoud wissen.

Dat kan met één DELETE door te joinen of meerdere DELETEs die je binnen een LOCK TABLES / UNLOCK TABLES zet.

quote:

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

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 tabel

quote:

Dat kan met één DELETE door te joinen of meerdere DELETEs die je binnen een LOCK TABLES / UNLOCK TABLES zet.

Bedankt voor de tip, daar ga ik mee stoeien.

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

quote:

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

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

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

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.

quote:

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.

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.

quote:

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.

mysql_insert_id() it is dus

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

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?

Maar ik kan dus save mysql_insert_id gebruiken direkt na de query welke de klantgegevens in de DB zet.