1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | <?php $sql = "INSERT INTO test (ID, RNAME, IP) VALUES (:ID, :RNAME, :IP)"; $stmt = $pdo->prepare($sql); $id = '1'; $RNAME= 'name'; $IP= '8.8.8.8'; $stmt->bindParam(":ID", $id); $stmt->bindParam(":RNAME", $RNAME); $stmt->bindParam(":IP", $IP); $stmt->execute(); $result = $stmt->execute(array(':id'=>$id, ':RNAME'=>$RNAME, ':IP'=>$IP)); ?> |
Ik mag hopen van niet.quote:Op vrijdag 12 oktober 2018 15:48 schreef Ceased2Be het volgende:
En is je ID geen autonummering veld?
Ja klopt, de connectie is er. Ik bedoelde inderdaad tabel, die tabel bestaat uit kolommen.quote:Op vrijdag 12 oktober 2018 15:47 schreef Darkomen het volgende:
'test' is geen kolom maar een tabel.
Goed letten op je casing.
Ik ga er van uit dat je wel een connectie hebt:
Wat zegt je pdo error info? http://php.net/manual/en/pdostatement.errorinfo.php
Je bind je parameters 2 maal. Zie de voorbeelden op http://php.net/manual/en/pdostatement.execute.php
Jaa, dat is het wel. Niet goed? De bedoeling is namelijk dat bij elke entry het id automatisch wordt opgehoogd.quote:Op vrijdag 12 oktober 2018 15:48 schreef Ceased2Be het volgende:
En is je ID geen autonummering veld?
Als het een autonummering veld is, hoef je deze toch niet mee te geven? Dat is het hele idee van autonummering, lekker aan de database overlaten.quote:Op vrijdag 12 oktober 2018 16:16 schreef NoXia het volgende:
[..]
Jaa, dat is het wel. Niet goed? De bedoeling is namelijk dat bij elke entry het id automatisch wordt opgehoogd.
Want?quote:
Dat klopt en is ook wel logisch maar dat had ik al geprobeerd. Heb ook geprobeerd de waarde null mee te geven, tevergeefs overigens.quote:Op vrijdag 12 oktober 2018 21:27 schreef ralfie het volgende:
[..]
Als het een autonummering veld is, hoef je deze toch niet mee te geven? Dat is het hele idee van autonummering, lekker aan de database overlaten.
Verscheidene redenen.quote:
Ik snap je punten. Echter hoef je de id niet direct als primary te gebruiken. Performance-gewijs is het beter om een int als is te gebruiken met een auto increment en deze als clustered index te zetten. Zo garandeer je iig geen fragmentatie bij inserts wat je bij non-sequential guids wel hebt. plus je houdt je CI klein. Je punt vwb parallele inserts echter niet mee eens. Tuurlijk heb je waits maar die zijn verwaarloosbaar als je het goed inricht. En zelfs bij tienduizenden inserts per minuut heb ik daar nog geen issues mee gezien.quote:Op zaterdag 13 oktober 2018 11:08 schreef Aaargh! het volgende:
[..]
Verscheidene redenen.
• Voorspelbare ID's want oplopend, als deze ID's vervolgens in URL's gebruikt maakt dit een e.v.t. beveiligingslek erger (iemand kan een scriptje schrijven die in 1 keer je database leegtrekt). Ook zonder beveiligingsprobleem is dit vaak niet wenselijk (kijk naar b.v. dit forum die opvolgende id's gebruikt voor topic nummers, je kan zo een kopie trekken van het hele forum als je wil).
• Je creëert een synchronisatie punt in je database. Er kan maar 1 thread tegelijk het tellertje ophogen, als er veel parallelle inserts zijn vormt dit een bottleneck. Dit wordt nog erger als je database geclusterd is.
• Je kan niet 'offline' primary keys genereren, omdat je altijd eerst moet checken of ie al bestaat (en dus synchroniseren). Dit maakt het lastig om offline data op te slaan en later de synchroniseren met de database. Het maakt het ook lastig om referenties tussen verschillende rows te maken voordat je ze in de database insert (je weet pas het id van een row nadat je de insert doet).
Beter is gewoon UUID's gebruiken.
Hoe zag je code eruit zonder de identifier erbij?quote:Op vrijdag 12 oktober 2018 22:47 schreef NoXia het volgende:
[..]
Dat klopt en is ook wel logisch maar dat had ik al geprobeerd. Heb ook geprobeerd de waarde null mee te geven, tevergeefs overigens.
Ik dacht, misschien een waarde mee geven zodat het weet waar te beginnen.
-elke random id moet gequeried worden met human-readable input. Ik kan fok leegtrekken door eerst alle fora te querien, dan alle topics, dan alle posts. Is nauwelijks moeilijker dan wanneer geen uuids gebruikt wordenquote:Op zaterdag 13 oktober 2018 11:08 schreef Aaargh! het volgende:
[..]
Verscheidene redenen.
• Voorspelbare ID's want oplopend, als deze ID's vervolgens in URL's gebruikt maakt dit een e.v.t. beveiligingslek erger (iemand kan een scriptje schrijven die in 1 keer je database leegtrekt). Ook zonder beveiligingsprobleem is dit vaak niet wenselijk (kijk naar b.v. dit forum die opvolgende id's gebruikt voor topic nummers, je kan zo een kopie trekken van het hele forum als je wil).
• Je creëert een synchronisatie punt in je database. Er kan maar 1 thread tegelijk het tellertje ophogen, als er veel parallelle inserts zijn vormt dit een bottleneck. Dit wordt nog erger als je database geclusterd is.
• Je kan niet 'offline' primary keys genereren, omdat je altijd eerst moet checken of ie al bestaat (en dus synchroniseren). Dit maakt het lastig om offline data op te slaan en later de synchroniseren met de database. Het maakt het ook lastig om referenties tussen verschillende rows te maken voordat je ze in de database insert (je weet pas het id van een row nadat je de insert doet).
Beter is gewoon UUID's gebruiken.
1 2 3 4 5 6 7 8 9 10 11 12 | <?php $link = new PDO("mysql:host=$dbhost;dbname=$dbname", $dbusername, $dbpassword); $link->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); $statement = $link->prepare("INSERT INTO test(RNAME, IP) VALUES(?,?)"); $RNAME= 'name'; $IP= '8.8.8.8'; $statement->execute(array($RNAME,$IP)); ?> |
|
Forum Opties | |
---|---|
Forumhop: | |
Hop naar: |