WHERE prioriteit
In onderstaande wordt een rij wel of niet getoond met show = Ja/Nee
als ik echter een plaats kies worden ook de rijen met show = Nee getoond,
kan ik een soort van prioriteit (priority?) geven aan WHERE `show` = 'Ja'
WHERE (... AND ...) OR ...
is wat anders dan
WHERE ... AND (... OR ...)
Gewijzigd op 29/05/2017 12:25:20 door - SanThe -
https://nl.wikipedia.org/wiki/Waarheidstabel
als ( Show = WAAR ) OF ( Plaats = WAAR ) dan is het WAAR
Dit lijkt te werken
Gewijzigd op 29/05/2017 13:27:21 door Ben van Velzen
Moet die veiligheid nog eens nalopen , overal lijkt het anders te zijn.
kan alleen maar tot fouten en verwaaring leiden. De backtics zijn meegekopieerd uit een ranzige tool??
Maar kan goed zijn dat ze hier niet nodig zijn.
Is ergens een goede tut te vinden hierover ,, veiligheid enz..
Dat voorkomt verwarring met JA of ja en maakt ook dat je programma begrijpelijk is voor een anderstatalige persoon.
Ivo P op 29/05/2017 14:58:01:
ik zou in de database kiezen voor 1/0 ipv Ja en Nee.
Dat voorkomt verwarring met JA of ja en maakt ook dat je programma begrijpelijk is voor een anderstatalige persoon.
Dat voorkomt verwarring met JA of ja en maakt ook dat je programma begrijpelijk is voor een anderstatalige persoon.
Klopt, had ik zelf ook aan aan zitten denken
Ik gebruik in zulke gevallen vaak een E_NUM met 0 en 1.
Hiermee wek je de (valse) suggestie dat SHOW in 5.7 niet meer reserved is.
De (R) staat voor Reserved Word en niet voor voetnoot [r]
Pierre Web op 29/05/2017 14:47:35:
Ik ben benieuwd naar de tut waar je het over hebt. Deze backtics worden doorgaans copy/paste meegenomen uit phpadmin, helaas. Je kan er inderdaad reserved words zoals SHOW gaan misbruiken in attributen en tabellen maar of het verstandig is betwijfel ik. Kan alleen maar verwarring over ontstaan. Gewoon niet doen. backtics , schijnen meningen ook verdeeld over te verschillen.
Maar kan goed zijn dat ze hier niet nodig zijn.
Is ergens een goede tut te vinden hierover ,, veiligheid enz..
Maar kan goed zijn dat ze hier niet nodig zijn.
Is ergens een goede tut te vinden hierover ,, veiligheid enz..
Gewijzigd op 29/05/2017 16:31:30 door John D
Ik heb ooit eens een probleem gehad , en iemand adviseerde me de backtics te gebruiken,
had iets te maken met tekst in een record precies weet ik het niet meer , maar werkte wel.
Ben ze dus blijven gebruiken.
Show verander ik in Display, advies heb ik hier al eens in het verleden gekregen.
Wat tut betreft bedoelde ik een goede tutorial over toepassen van veiligheid , juist toepassen van mysqli_escape_string enz.
Gewijzigd op 29/05/2017 19:26:21 door Pierre Web
Pierre Web op 29/05/2017 12:05:17:
Dit is slechte naamgeving. $db is namelijk geen database maar een tabel. En inderdaad, maak van een boolean kolom ook echt een BOOL (of TINYINT of wat dan ook). Alsjeblieft geen ENUM, dat is echt bagger because reasons. Vermijd het gebruik van een mix van engelse en nederlandse woorden door elkaar. Dit is gewoon terribly verwarrend.
Daarnaast zou je het gereserveerde-woorden-dilemma kunnen omzeilen door kolommen een vaste prefix te geven (hiermee voorkom je ook alias-issues indien je een query hebt waarin je verschillende tabellen joined waarin kolommen met eenzelfde naam zitten, door een prefix worden alle kolomnamen uniek). Als je bijvoorbeeld te maken hebt met een tabel van artikelen zou je de kolom art_show kunnen noemen (prefix art_). Zelden tot nooit meer problemen met gereserveerde woorden.
En tot slot. Introduceer eens wat abstractie in een databaselaag. Maak een eenvoudige database-klasse die je werk uit handen neemt. Zo zou je bijvoorbeeld een methode "escape" kunnen introduceren, met als eerste implementatie:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
2
3
4
5
6
7
8
9
10
11
<?php
class MyDb
{
protected $db; // refers to db-object
// ...
public function escape($in) {
return addslashes($in);
}
}
?>
class MyDb
{
protected $db; // refers to db-object
// ...
public function escape($in) {
return addslashes($in);
}
}
?>
En dan, als je later beseft dat deze beveiliging toch een wassen neus is verander je deze in:
Code (php)
De toegevoegde waarde is onder andere dat je voor een andere implementatie geen letter code tijdens communicatie met je database hoeft aan te passen. Dit was voorheen $myDb->escape($whatever) (waarbij $myDb een object van de klasse MyDb is) en is na de aanpassing nog steeds $myDb->escape($whatever), ongeacht de implementatie. Dat lijkt mij beter dan in je code addslashes()-instanties te search-and-replacen... of in het algemeen, elke keer zo'n operatie uitvoeren als je een slimmere/veiligere implementatie verzint.
Gewijzigd op 30/05/2017 01:48:06 door Thomas van den Heuvel
Klopt van die $db en integer
Wat je code betreft , hier zal ik eens op mijn gemak naar moeten kijken.
Ik ben een oudje en vind het heel fijn om met php mysqli iets te maken , meestal neem ik voorbeelden over van bijv,
https://www.sanwebe.com/2013/03/basic-php-mysqli-usage en
http://www.thaicreate.com/php/php-mysql-mysqli-delete.html.
En aanvullende vragen stel ik hier op forum.