[PHP/(My)SQL] voor dummies - Deel 17 | Digital Corner (DIG)

zaterdag 10 december 2005 @ 21:36:56 #201

existenz

is tof

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

PHP is bijna altijd de $ ervoor

This message is intended for the addressee shown. It contains information that is confidential and protected from disclosure. The contents of this message do not necessarily represent the views or policies of myself.

zaterdag 10 december 2005 @ 21:37:39 #202

wobbel

Da WoBBeL King

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 ]

Hosted VoIP SIP trunks Vast mobiel VoIP

zaterdag 10 december 2005 @ 22:46:45 #203

SuperRembo

Sinds 1998

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?

FOK!-Schrikkelbaas zaterdag 10 december 2005 @ 22:53:01 #204

Swetsenegger

Egocentrische Narcist

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

 | FOK! Schrikkelbaasch

zaterdag 10 december 2005 @ 22:54:41 #205

SkaterSam

Lurking Galore

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

Let's make life easy
Typo's are the demon spawn from hell !

zaterdag 10 december 2005 @ 22:55:15 #206

the_disheaver

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

zaterdag 10 december 2005 @ 23:10:44 #207

mschol

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

zondag 11 december 2005 @ 16:21:22 #208

wobbel

Da WoBBeL King

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94

<?php
php
session_start();
/* Load main library Files */
require_once                                    ("lib/htconfig.php");
require_once(                                    $GLOBALS['SITE']['LibPath'] . "/main.php");

if(!$_GET['sid'])
{

    $error->Report                                ("Er is geen (sub)forum ID meegegeven. Bewerking is afgebroken.");

}
else
{

    $MySQL_Fora_Select                            = "SELECT IdForumSubCat, ForumCatId, Titel FROM ForumSubCat WHERE IdForumSubCat = '" . addslashes($_GET['sid']) . "' LIMIT 1";
    $MySQL_Fora_Query                            = mysql_query($MySQL_Fora_Select) or die($error->ReportMysqlError(__FILE__, $MySQL_Fora_Select ,__LINE__));
    $MySQL_Fora_Numrow                            = mysql_num_rows($MySQL_Fora_Query);

    if($MySQL_Fora_Numrow >= 1)
    {

        ## Select the main forum Titel and Image
        $MySQL_Fora_Assoc                        = mysql_fetch_assoc($MySQL_Fora_Query);

        $MySQL_Forum_Select                        = "SELECT IdForumCat, Titel, TitelImage FROM ForumCat WHERE IdForumCat = '" . addslashes($MySQL_Fora_Assoc['ForumCatId']) . "' LIMIT 1";
        $MySQL_Forum_Query                        = mysql_query($MySQL_Forum_Select) or die(mysql_error());
        $MySQL_Forum_Assoc                        = mysql_fetch_assoc($MySQL_Forum_Query);

        $tml->RegisterVar                        ("CONTENTTOP", $MySQL_Forum_Assoc['TitelImage']);
        $tml->RegisterVar                        ("FORUMTITLE", $MySQL_Forum_Assoc['Titel']);
        $tml->RegisterVar                        ("SUBFORUMTITLE", $MySQL_Fora_Assoc['Titel']);
        ##

        $MySQL_Topic_Select                        = "SELECT IdTopic, UserId, Titel, Type FROM ForumTopics WHERE SubCatId = '" . addslashes($_GET['sid']) . "' ORDER BY Date DESC";
        $MySQL_Topic_Query                        = mysql_query($MySQL_Topic_Select) or die(mysql_error());
        $MySQL_Topic_Numrow                        = mysql_num_rows($MySQL_Topic_Query);

        while($Topic = mysql_fetch_assoc($MySQL_Topic_Query))
        {

            $MySQL_Message_Select                = "SELECT TopicId, Datum FROM ForumMessages WHERE TopicId = '" . $Topic['IdTopic'] . "' ORDER BY Datum DESC LIMIT 1";
            $MySQL_Message_Query                = mysql_query($MySQL_Message_Select) or die(mysql_error() . " op regel: " . __LINE__ . "<br />De betreffende query:" . $MySQL_Message_Select);
            $MySQL_Message_Assoc                = mysql_fetch_assoc($MySQL_Message_Query);
            $LastPostInTopic                    = $MySQL_Message_Assoc['Datum'];

            $MySQL_Reacties_Select                = "SELECT COUNT(IdMessage) FROM ForumMessages WHERE TopicId = '" . $Topic['IdTopic'] . "'";
            $MySQL_Reacties_Query                = mysql_query($MySQL_Reacties_Select);
            $MySQL_Reacties_Result                = mysql_result($MySQL_Reacties_Query, 0);

            $LoopData         = array    (

                                                "TITLE"                => $Topic['Titel'],
                                                "IDTOPIC"            => $Topic['IdTopic'],
                                                "USERID"            => $main->User_Name($Topic['UserId'], 1),
                                                "REACTIES"            => $MySQL_Reacties_Result,
                                                "LASTPOST"            => date("d-m-Y H:i:s", $LastPostInTopic),

                                    );


            $i++;

            /* Registreren van een Loop */
            $tml->RegisterLoop("TOPIC",$i,$LoopData);

        }

        /* Load Header file */
        $tml->LoadFromFile                        ("pages/overall_header");
        $tml->Parse();

        /* Load Page Content */
        $tml->LoadFromFile                        ("pages/forum_subcat");
        $tml->Parse();

        /* Load Footer file */
        $tml->LoadFromFile                        ("pages/overall_footer");
        $tml->Parse();

        /* Output Pages */
        $tml->Output();

    }
    else
    {

        $error->Report                            ("Het (sub)forum dat je probeert op te vragen is niet gevonden.");

    }

}
?>

Hosted VoIP SIP trunks Vast mobiel VoIP

FOK!-Schrikkelbaas zondag 11 december 2005 @ 20:15:58 #209

Swetsenegger

Egocentrische Narcist

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.

 | FOK! Schrikkelbaasch

zondag 11 december 2005 @ 20:33:11 #210

existenz

is tof

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.

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!

This message is intended for the addressee shown. It contains information that is confidential and protected from disclosure. The contents of this message do not necessarily represent the views or policies of myself.

zondag 11 december 2005 @ 20:34:02 #211

JeRa

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

FOK!-Schrikkelbaas zondag 11 december 2005 @ 20:34:03 #212

Swetsenegger

Egocentrische Narcist

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

 | FOK! Schrikkelbaasch

FOK!-Schrikkelbaas zondag 11 december 2005 @ 20:34:57 #213

Swetsenegger

Egocentrische Narcist

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

 | FOK! Schrikkelbaasch

zondag 11 december 2005 @ 20:44:30 #214

JeRa

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

FOK!-Schrikkelbaas zondag 11 december 2005 @ 21:06:20 #215

Swetsenegger

Egocentrische Narcist

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

1
2
3
4
5

order_table_id     user_id     order_id     product_id     number
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 ]

 | FOK! Schrikkelbaasch

zondag 11 december 2005 @ 21:18:10 #216

JeRa

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?

FOK!-Schrikkelbaas zondag 11 december 2005 @ 21:20:43 #217

Swetsenegger

Egocentrische Narcist

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.

 | FOK! Schrikkelbaasch

zondag 11 december 2005 @ 21:32:45 #218

JeRa

Mja, dat gaat toch werken?

sorry dat ik even niet duidelijk aangaf dat ik het over een nieuwe koppeltabel had

FOK!-Schrikkelbaas zondag 11 december 2005 @ 21:43:09 #219

Swetsenegger

Egocentrische Narcist

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.

 | FOK! Schrikkelbaasch

zondag 11 december 2005 @ 21:49:28 #220

JeRa

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.

FOK!-Schrikkelbaas zondag 11 december 2005 @ 21:56:57 #221

Swetsenegger

Egocentrische Narcist

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

 | FOK! Schrikkelbaasch

zondag 11 december 2005 @ 22:00:21 #222

JeRa

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

FOK!-Schrikkelbaas zondag 11 december 2005 @ 22:04:18 #223

Swetsenegger

Egocentrische Narcist

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.

 | FOK! Schrikkelbaasch

zondag 11 december 2005 @ 22:05:34 #224

JeRa

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

FOK!-Schrikkelbaas zondag 11 december 2005 @ 22:11:27 #225

Swetsenegger

Egocentrische Narcist

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.

 | FOK! Schrikkelbaasch

zondag 11 december 2005 @ 22:16:25 #226

JeRa

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.

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

Klopt ook.

zondag 11 december 2005 @ 22:30:17 #227

SuperRembo

Sinds 1998

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

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.

FOK!-Schrikkelbaas zondag 11 december 2005 @ 22:33:47 #228

Swetsenegger

Egocentrische Narcist

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.

PK?

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

 | FOK! Schrikkelbaasch

zondag 11 december 2005 @ 22:41:08 #229

JeRa

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.

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.

zondag 11 december 2005 @ 22:42:48 #230

Light

quote:
Op zondag 11 december 2005 22:33 schreef Swetsenegger het volgende:

[..]

PK?

Primary Key.

FK is Foreign Key.

fokstok.nl

FOK!-Schrikkelbaas zondag 11 december 2005 @ 23:20:24 #231

Swetsenegger

Egocentrische Narcist

quote:
Op zondag 11 december 2005 22:42 schreef Light het volgende:

[..]

Primary Key.

FK is Foreign Key.

Nav JeRa begreep ik 'm

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?

 | FOK! Schrikkelbaasch

zondag 11 december 2005 @ 23:22:32 #232

Light

Huh? Wat voor query doe je dan?

fokstok.nl

FOK!-Schrikkelbaas zondag 11 december 2005 @ 23:26:31 #233

Swetsenegger

Egocentrische Narcist

quote:
Op zondag 11 december 2005 23:22 schreef Light het volgende:
Huh? Wat voor query doe je dan?

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.

 | FOK! Schrikkelbaasch

zondag 11 december 2005 @ 23:30:05 #234

Light

MySQL (phpmyadmin) geeft bij mij gewoon een melding dat er 0 rijen zijn aangepast. Geen foutmeldingen ofzo.

fokstok.nl

zondag 11 december 2005 @ 23:37:57 #235

JeRa

Hier doet ie dat ook niet. Wat is de exacte error die je van MySQL krijgt?

zondag 11 december 2005 @ 23:43:01 #236

SuperRembo

Sinds 1998

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

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

zondag 11 december 2005 @ 23:46:31 #237

Light

quote:
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

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

fokstok.nl

zondag 11 december 2005 @ 23:48:30 #238

JeRa

quote:
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 ja

zondag 11 december 2005 @ 23:54:57 #239

SuperRembo

Sinds 1998

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

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?

maandag 12 december 2005 @ 00:04:02 #240

JeRa

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?

Ja (heb het hier draaien). Weliswaar niet in de strict-modus, misschien dat dat wat uitmaakt?

maandag 12 december 2005 @ 00:05:14 #241

Roonaan

Strictly

Wie gebruikt er eik weleens bij sql "replace" ?

maandag 12 december 2005 @ 00:08:37 #242

Light

quote:
Op maandag 12 december 2005 00:05 schreef Roï¿œaï¿œ het volgende:
Wie gebruikt er eik weleens bij sql "replace" ?

Ik. En eigenlijk moeten die herschreven worden, ze kunnen best zwaar worden voor de server (die het toch al niet makkelijk heeft). En nee, die queries gooi ik hier niet neer

fokstok.nl

maandag 12 december 2005 @ 00:15:14 #243

JeRa

quote:
Op maandag 12 december 2005 00:05 schreef Roï¿œaï¿œ het volgende:
Wie gebruikt er eik weleens bij sql "replace" ?

Ik niet. Maar even gelezen in de documentation, dan worden alle dubbele rijen gedelete en opnieuw geinsert met een nieuwe primary key. Dat moet je niet te vaak doen op een grote tabel

maandag 12 december 2005 @ 00:30:02 #244

Light

quote:
Op maandag 12 december 2005 00:15 schreef JeRa het volgende:

[..]

Ik niet. Maar even gelezen in de documentation, dan worden alle dubbele rijen gedelete en opnieuw geinsert met een nieuwe primary key. Dat moet je niet te vaak doen op een grote tabel

replace into mytable (id, name) values (1, "test")
Dat levert een 1 affected row op als je nog geen rij hebt met id=1, en anders 2. Ik ga er dan dus wel even vanuit dat id de PK is.

fokstok.nl

maandag 12 december 2005 @ 12:58:34 #245

Desdinova

Olaa

af en toe laat ik het een en ander uit een database echoen in een tabel. komt ook best vaak voor dat ik die tabel maar 3 td's breed wil, en de volgende 3 in een rij daaronder komen, de drie daarna weer daaronder etc.

dit vang ik momenteel op door php te laten tellen. per while doet hij $nr + 1;, waardoor er bij de 3e een waarde van 3 komt en de rij wordt afgebroken door een ander te laten echoen en een nieuwe wordt begonnen. daarna wordt $nr weer teruggezet op 0 zodat de riedel weer van voor af aan begint.

is dit niet wat makkelijker en netter af te vangen?

As a rule, I never touch anything more sophisticated and delicate than myself.

maandag 12 december 2005 @ 13:07:34 #246

Roonaan

Strictly

Zijn de cellen allemaal even hoog?

maandag 12 december 2005 @ 13:10:03 #247

Desdinova

Olaa

mja zijn wel even hoog.

ik zit net te denken aan een float.. als ik ze allemaal een float left meegeef, en ze per stuk in een div zet ofzo met aangegeven waardes, heb ik waarschijnlijk de hele tabel niet nodig. misschien een omringende tabel of div om de totale breedte aan te geven. eensch?

As a rule, I never touch anything more sophisticated and delicate than myself.

maandag 12 december 2005 @ 13:10:49 #248

Roonaan

Strictly

Jups, daar zat ik ook aan te denken idd.

maandag 12 december 2005 @ 15:43:41 #249

HuHu

Vraagje:

ik heb een site waarop mensen dingen kunnen kopen (soort webwinkel) en mensen kunnen betalen via CreditCard of eenmalige incasso. De betalingen worden geregeld via een Payment Service Provider, dus daar heb ik geen zorgen om.

Maar ik moet de gegevens van de bestelling naar de PSP toe sturen. Als voorbeeld geven zij een HTML pagina met daarin een FORM waarin bedrag, ordernummer, enzovoorts staan. Alles wordt vervolgens gepostnaar een HTTPS geval.

Ik wil nu vanuit een PHP bestand ook die POST kunnen uitvoeren. Dus dat ik de headers naar mijn PSP stuur. Ik had zelf het volgende gemaakt gejat:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

<?php
$url = "https://[psp]/[psp].php";
$host = substr($url, 0, strpos($url, "/"));
$uri = strstr($url, "/");
$reqbody = "";
      foreach($data as $key=>$val) {
          if (!empty($reqbody)) $reqbody.= "&";
      $reqbody.= $key."=".urlencode($val);
      }
$contentlength = strlen($reqbody);
$reqheader =  "Location: $url\r\n".
    "POST $uri HTTPS/1.1\r\n".
    "Host: ssl://$host\n". "User-Agent: PostIt\r\n".
    "Content-Type: application/x-www-form-urlencoded\r\n".
    "Content-Length: $contentlength\r\n\r\n".
    "$reqbody\r\n";
header($reqheader);
?>

Maar dit werkt niet helemaal goed, want de data is niet SSL versleuteld enzo. Dus m'n PSP accepteerd het niet. Nu las ik ergens dat je ook gebruik kon maken van cURL, maar ik heb geen flauw idee hoe ik dat kan doen. Kan iemand daarmee helpen?

[ Bericht 11% gewijzigd door HuHu op 12-12-2005 15:54:23 ]

FOK!-Schrikkelbaas maandag 12 december 2005 @ 18:46:37 #250

Swetsenegger

Egocentrische Narcist

Heeft je PSP geen kant en klaar php script dan?

 | FOK! Schrikkelbaasch

Forum Opties
Forumhop:
Hop naar:	(afkorting, bv 'KLB')

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

» digital corner

» digital corner