[PHP] Snelste manier om gegevens uit DB te halen

[WingsOfFury]

Ik had net een flink bericht getypt die op eens weg was toen ik op UBB-codes drukte. Misschien is een waarschuwing dat je je bericht kwijt raakt zodra je daarop klikt wel handig, admins? Nou ja, nu maar even opnieuw in de korte versie:

Waarschijnlijk is dit nogal een beginners vraag, en is hij makkelijk op internet te vinden, maar ik weet het echt niet en weet ook niet precies hoe ik hem moet stellen om het op internet te vinden. Ik mis de kennis over de vaktermen, vandaar.

Ik heb een berichtjes site met de berichtjes in 1 tabel in mijn DB. De berichtjes kunnen een status krijgen; 1, 2, 3 of 4. Hoe kan ik nu het snelst/best/veiligst/oid de berichtjes opgesplitst uitlezen?

Ik kan zelf 2 manieren bedenken, die beiden goed werken omdat het om een kleine site gaat, maar deze basis kennis is wel handig voor het geval ik grotere projecten ga opzetten.

Optie 1:

code:

$query = "SELECT * FROM tbl_bb WHERE status = 1";
$row = mysql_query($query) or die(mysql_error());
while ($w = mysql_fetch_array($row)) {
echo $w['tekst']; }

En zo verder voor de andere statussen.

Optie 2:

code:

$query = "SELECT * FROM tbl_bb";
$row = mysql_query($query) or die(mysql_error());
while ($w = mysql_fetch_array($row)) {
if ($w['status'] == 1) { echo $w['tekst']; }

En zo verder voor de andere statussen.

Kortom: voor iedere status een losse query maken, of juist alle berichtjes in 1 query ophalen en ze dan met if/else verdelen?

Als het niks uitmaakt zou ik graag jullie voorkeur willen weten

[MLM]

Doe het in je query, dan moet er minder data uit de DB komen.

[susscorfa]

als je 1 status zou willen is het eerste sneller als je alle statusen wilt zou je kunnen kijken om het gesorteerd per status uit de database te halen. Houd er wel rekening mee dat je met de huidige setups moeilijk statusen kan toevoegen ( lees meer over normalisatie als je daar meer over wilt weten)

Ik denk dat het handig is om in de gaten te houden dat over het algemeen een database sneller is in data handelen dan zelf gecode php dingen zoals je if statement

overigens voor snelheids optimalisaties is het ook wenselijk alleen de data op te halen waar in in geintreseert bent en niet alles met *

[TheMe]

Ik zat ook te denken aan:

code:

$query = "SELECT * FROM tbl_bb WHERE status = '".$_GET['id']."";
$row = mysql_query($query) or die(mysql_error());
while ($w = mysql_fetch_array($row)) {
echo $w['tekst']; }

En dan op de pagina met links waarop je kiest index.php?id=1 /2 /4

Volgens mij scheelt dat veel code schrijven ten opzichte van if/else

[susscorfa]

houd er rekening mee dat de oplossing van TheMe zonder appropriate measures gevoelig is voor sql injecties

[.oisyn]

WingsOfFury schreef op woensdag 05 mei 2010 @ 17:19:
Kortom: voor iedere status een losse query maken, of juist alle berichtjes in 1 query ophalen en ze dan met if/else verdelen?

Als het niks uitmaakt zou ik graag jullie voorkeur willen weten

Sowieso, om hoeveel berichten gaat het hier? Feitelijk maakt het niet zo heel veel uit als je het goed aanpakt. Ik vermoed dat op jouw manier met een ifje per iteratie in de loop in PHP het iets langzamer is, maar dan nog, waar praten we over?
In een echte productieomgeving die serieus veel data af moet handelen op een dergelijke manier zul je niet eens kijken naar wat in een testopstelling het snelst is, maar wat in de praktijk het snelst is. Als je meerdere webservers hebt die allemaal met 1 db server communiceren wil je feitelijk zo weinig mogelijk op de db server doen. Staat die db server(s) echter weer 90% van de tijd uit z'n neus te vreten terwijl de webserver volle toeren draait dan is het handig om je data op de server alvast te sorteren of per status op te halen. Maar waarschijnlijk zijn dit punten die totaal niet van belang zijn voor je

Ik had net een flink bericht getypt die op eens weg was toen ik op UBB-codes drukte. Misschien is een waarschuwing dat je je bericht kwijt raakt zodra je daarop klikt wel handig, admins?

Of je gebruikt een browser die zoiets voor je bewaart en je dus gewoon de backknop kunt gebruiken. Daarnaast was het van jezelf natuurlijk ook wel een beetje klungelig, je weet dat op een link klikken in het hoofdmenu doorgaans gewoon de pagina opent in de huidige tab. Dat is vrij standaard gedrag dat iedere internetter kent en daarom dus ook geen warning behoeft

[Serenity]

TheMe schreef op woensdag 05 mei 2010 @ 17:30:
Ik zat ook te denken aan:

code:

$query = "SELECT * FROM tbl_bb WHERE status = '".$_GET['id']."";
$row = mysql_query($query) or die(mysql_error());
while ($w = mysql_fetch_array($row)) {
echo $w['tekst']; }

En dan op de pagina met links waarop je kiest index.php?id=1 /2 /4

Volgens mij scheelt dat veel code schrijven ten opzichte van if/else

Zoals susscorfa al zei, pas goed op met dit soort dingen. In principe kun je vanalles invullen in de URL, waardoor je niet weet wat er in $_GET['id'] staat, en wat voor query je dus eigenlijk uitvoert. Maar het idee is inderdaad goed; dit is de makkelijkste manier om een bepaalde lijst berichten te krijgen.

Je kunt iets van PDO of MySQLi gebruiken die kortweg voorkomen dat er vage variabelen in je query komen en uitgevoerd worden. Maar zolang je gewoon goed nagaat wat voor waardes je erin stopt, en in hoeverre die door anderen zijn aan te passen kun je imho voor simpele sites prima met standaard MySQL-queries werken.

Bij bovenstaande voorbeeld dus eerst afvangen of het wel daadwerkelijk een status is.

Kan door te kijken of het numeriek is:

code:

if (is_numeric($_GET['id'])) {
  $id = $_GET['id'];
} else {
 // negeer het, en pak bijv. de standaard id
  $id = 1;
}
$query = "SELECT * FROM tbl_bb WHERE status = $id";

Of om er zeker van te zijn dat het een id is die bestaat:

code:

if (in_array($_GET['id'],array(1,2,3,4)) {
  // etc
}

of korter met (voorwaarde ? true : false):

$id = in_array($_GET['id'],array(1,2,3,4)) ? $_GET['id'] : 1;

[S_tef]

Gebruik a.u.b. de functie ctype_digit i.p.v. is_numeric om ids te controleren, meer info hierover in de php manual.

[Verwijderd]

Waarom niet gelijk zo:

PHP:

$query = mysql_query("SELECT * FROM tbl_bb WHERE status = '".mysql_escape_string($_GET['id'])."'")or die(mysql_error());
while ($w = mysql_fetch_array($query)) {
echo $w['tekst'];
 }

En waarom vraagje de velden niet op in query want nu pakt hij de hele tabel.

Als je nu het volgende doet is het sneller:

PHP:

$query = mysql_query("SELECT status,veld1,veld2,veld4 FROM tbl_bb WHERE status = '".mysql_escape_string($_GET['id'])."'")or die(mysql_error());
while ($w = mysql_fetch_array($query)) {
echo $w['tekst'];
 }

[ Voor 81% gewijzigd door Verwijderd op 05-05-2010 22:29 ]

[HenkEisDS]

Verwijderd schreef op woensdag 05 mei 2010 @ 22:19:
Waarom niet gelijk zo:

PHP:

$query = mysql_query("SELECT * FROM tbl_bb WHERE status = '".(int) $_GET['id']."'")or die(mysql_error());
while ($w = mysql_fetch_array($query)) {
echo $w['tekst'];
 }

Waarom niet gelijk zo? Tuurlijk krijg je een fout als er dan toch iets raars in staat, maar je weet dan tenminste zeker dat er geen code in zit. Of kun je het datatype niet zo in de query zetten?

[ACM]

HenkEisDS schreef op woensdag 05 mei 2010 @ 22:26:
Waarom niet gelijk zo? Tuurlijk krijg je een fout als er dan toch iets raars in staat, maar je weet dan tenminste zeker dat er geen code in zit. Of kun je het datatype niet zo in de query zetten?

Wat heeft het datatype met de "query" te maken? Het is pas voor de MySQL-server een query, voor de rest van het traject (het zichtbare deel in deze code iig) is het gewoon een string met string-concatenation en dergelijke. Dus als jij de get-waarde naar int cast om vervolgens in de string te concatenaten... wordt het geheel gewoon string.

Als je het zo netjes mogelijk wilt doen, gebruik dan mysqli of pdo met een prepared statement nadat je eerst gekeken hebt dat het inderdaad netjes een getal was om zo de gebruiker op zijn fouten te wijzen.

Anders is het vooral een kwestie van smaak wat je het liefste doet om zeker te weten dat de er in geplakte variabele in de query uiteindelijk zeker weten een int was. Het is dan wel iets netter om vooraf te checken dat het aldaniet een (positieve) int was, zodat je een concrete foutafhandeling voor dat scenario kan maken.
Anderzijds, voor veel pagina's is de kans dat iemand nog geinteresseerd is in die nettere foutmelding als er moedwillig iets verkeerd in gezet wordt vrij klein, dus is de cast naar int waarschijnlijk het simpelst en snelst

[WingsOfFury]

Ik zie dat ik iets te weinig info heb gegeven. De $_GET optie kan niet omdat ik op 1 pagina 3 statussen wil hebben. De vraag wordt dan: 3 statussen = 3 queries, of 1 query en if/else codering?

Wat kan er eigenlijk bij de $_GET worden ingevuld om een database te wissen of andere schade aan te richten? Op bepaalde pagina's gebruik ik namelijk wel $_GET's in de query en ik heb wel vaker gelezen dat het gevaarlijk is, maar kom eigenlijk nooit tegen waarom het gevaarlijk is en wat er nou precies kan gebeuren.

De database bevat zo'n 30.000 berichten verspreid over 2 tabellen. Voor biede tabellen heb ik losse pagina's, dus gaat het om 15.000 berichten. In principe worden er maar 30 berichten weergeven:

code:

$query2= "SELECT * FROM tbl_bb LIMIT ".$vorige_page_limit.", 30 ";

Hier gaat nog een hele berekening aan vooraf voor de vorige_page_limit, maar dat is nu niet van belang.

Ik wil alleen binnenkort alle berichten even onder elkaar zetten om ze uit te gaan zoeken. Hierbij is het dan wel handig als ze zsm tevoorschijn komen. Vandaar dat ik wil weten hoe ik ze het beste uit de DB kan halen.
Dit brengt mij trouwens bij nog een vraag: hoe kan ik de berichten van beide tabellen in 1 lijst krijgen, gesorteerd op datum? Zodra er een bericht wordt toegevoegd krijgt hij in de DB bij het veld datum een timestamp mee.

Ik gebruik trouwens het * omdat ik alle velden uit de tabel nodig heb.

Offtopic:

.oisyn schreef op woensdag 05 mei 2010 @ 17:38:
Of je gebruikt een browser die zoiets voor je bewaart en je dus gewoon de backknop kunt gebruiken. Daarnaast was het van jezelf natuurlijk ook wel een beetje klungelig, je weet dat op een link klikken in het hoofdmenu doorgaans gewoon de pagina opent in de huidige tab. Dat is vrij standaard gedrag dat iedere internetter kent en daarom dus ook geen warning behoeft

Dat bewaren is niet alleen van de browser afhankelijk, ook van de site. Ik heb het namelijk bij de meeste sites wel als ik op de backknop druk. En bovendien opent een link die bij het invoeren van een post staat vaak in een pop-up, niet in het huidige tabblad.

[eghie]

S_tef schreef op woensdag 05 mei 2010 @ 19:11:
Gebruik a.u.b. de functie ctype_digit i.p.v. is_numeric om ids te controleren, meer info hierover in de php manual.

Over die ctype_digit:

quote: http://nl.php.net/manual/en/function.ctype-digit.php

Note: This function require a string to be useful, so for example passing in an integer will always return FALSE. However, also note that HTML Forms will result in numeric strings and not integers. See also the types section of the manual.

en:

quote: http://nl.php.net/manual/en/function.ctype-digit.php#95117

ctype_digit() will treat all passed integers below 256 as character-codes. It returns true for 48 through 57 (ASCII '0'-'9') and false for the rest.

ctype_digit(5) -> false
ctype_digit(48) -> true
ctype_digit(255) -> false
ctype_digit(256) -> true

(Note: the PHP type must be an int; if you pass strings it works as expected)

Meestal gebruik ik voor zoiets, als ik even snel een query moet programmeren een vorm van sprintf met intval().

Ik zou als ik jou was, mysql_fetch_assoc gebruiken in plaats van mysql_fetch_array. Dit omdat fetch_array ook numerieke keys van de arrays terug geeft. Dit vreet meer geheugen en kan in de weg gaan zitten met parsen.

Zo doe ik dit soort dingen meestal:

PHP:

$query = sprintf("SELECT * FROM tbl_bb LIMIT %d, %d", intval($vorige_page_limit), intval($aantal_items));
$qres = mysql_query($query);

if ($qres !== FALSE) //geen error
while (($w = mysql_fetch_assoc($qres)) !== FALSE) {
    switch (intval($w['status'])) {
        case 1:
        case 2:
        case 3:
        default:
                  break;
    }
}

[.oisyn]

WingsOfFury schreef op woensdag 05 mei 2010 @ 23:50:
Dat bewaren is niet alleen van de browser afhankelijk, ook van de site.

Klopt, IE maakt er bijvoorbeeld altijd wel een potje van aangezien hij de pagina doodleuk opnieuw op gaat halen als hij 'm niet mocht cachen (en dus is je input weg). Ik kan met Chrome echter gewoon een post tikken, wegnavigeren, en dan met de backknop weer terug. Ergo, het ligt aan je browser.

En bovendien opent een link die bij het invoeren van een post staat vaak in een pop-up, niet in het huidige tabblad.

Een link uit het hoofdmenu niet. Ik ken geen enkele site die dat wel doet. En de kleine ubb codes link die bij de post zelf staat opent gewoon een nieuwe tab. Zo staat het ook in de HTML:
<a href="Overzicht van UBB-codes" rel="external" target="_blank">UBB-codes</a>

[ Voor 20% gewijzigd door .oisyn op 06-05-2010 00:53 ]

[crisp]

offtopic:

.oisyn schreef op donderdag 06 mei 2010 @ 00:27:
[...]

Klopt, IE maakt er bijvoorbeeld altijd wel een potje van. Ik kan met Chrome echter gewoon een post tikken, wegnavigeren, en dan met de backknop weer terug. Ergo, het ligt aan je browser.

True

[...]

Een link uit het hoofdmenu niet. Ik ken geen enkele site die dat wel doet. En de kleine ubb codes link die bij de post zelf staat opent gewoon een nieuwe tab. Zo staat het ook in de HTML:
<a href="Overzicht van UBB-codes" rel="external" target="_blank">UBB-codes</a>

Het target-attribuut wordt mbv javascript toegevoegd bij links met rel="external" indien je 'Open externe links in nieuw venster' in je voorkeuren aan hebt staan.

[pedorus]

eghie schreef op donderdag 06 mei 2010 @ 00:07:
Ik zou als ik jou was, mysql_fetch_assoc gebruiken in plaats van mysql_fetch_array.

In principe is alles met mysql_* ouderwets, en niet meer aan te raden. mysqli_ of pdo is aanbevolen. Welke van beide je dan nog moet kiezen ligt aan wat je zelf beter vindt, hier een voorbeeld (een voorbeeld met pdo+prepared statements was nog mooier geweest).
(En op de oorspronkelijke vraag van TS was natuurlijk optie 1 het goede antwoord in bijna alle gevallen.)

crisp schreef op donderdag 06 mei 2010 @ 00:49:
Het target-attribuut wordt mbv javascript toegevoegd bij links met rel="external" indien je 'Open externe links in nieuw venster' in je voorkeuren aan hebt staan.

offtopic:
Ik vind dit enkel eigenlijk geen externe link.

[crisp]

pedorus schreef op donderdag 06 mei 2010 @ 01:12:
[...]

offtopic:
Ik vind dit enkel eigenlijk geen externe link.

offtopic:
'zijdelingse' links vallen daar ook onder

[Patriot]

eghie schreef op donderdag 06 mei 2010 @ 00:07:
[...]

Over die ctype_digit:

[...]

en:

[...]


Meestal gebruik ik voor zoiets, als ik even snel een query moet programmeren een vorm van sprintf met intval().

In de context van het testen van dingen die uit de $_GET-array komen is ctype_digit wel de beste oplossing hoor. De problemen die jij noemt treden daar namelijk niet op omdat dat een string is (tenzij je er zelf expliciet een integer in hebt gestopt).

Zo doe ik dit soort dingen meestal:

PHP:

$query = sprintf("SELECT * FROM tbl_bb LIMIT %d, %d", intval($vorige_page_limit), intval($aantal_items));

Je snapt wel dat dat dubbel is? Sowieso vind ik het geen slimme oplossing, omdat je in situaties waar het nodig is de gebruiker niet kunt attenderen op een gemaakte fout (je negeert foutieve invoer gewoon).

[Serenity]

WingsOfFury schreef op woensdag 05 mei 2010 @ 23:50:
Ik zie dat ik iets te weinig info heb gegeven. De $_GET optie kan niet omdat ik op 1 pagina 3 statussen wil hebben. De vraag wordt dan: 3 statussen = 3 queries, of 1 query en if/else codering?

Je kunt één query uitvoeren en bepaalde statussen ophalen. Dit kan ook wel afhankelijk van de pagina waar je op zit. Dus bij bijv. pagina A alleen status=1, bij pagina B status 1, 2, en 3. Met "IN" kun je dan gemakkelijk bepaalde statussen ophalen. Afhankelijk van de pagina kun je bijvoorbeeld bijhouden welke statussen opgehaald moeten worden, en die specifieke statussen in de query stoppen.

PHP:

$query = "SELECT * FROM tbl_bb WHERE status IN (1,2,3)";

WingsOfFury schreef op woensdag 05 mei 2010 @ 23:50:
Wat kan er eigenlijk bij de $_GET worden ingevuld om een database te wissen of andere schade aan te richten? Op bepaalde pagina's gebruik ik namelijk wel $_GET's in de query en ik heb wel vaker gelezen dat het gevaarlijk is, maar kom eigenlijk nooit tegen waarom het gevaarlijk is en wat er nou precies kan gebeuren.

Zie de eerste paar voorbeelden: Wikipedia: SQL injection. Voor je het weet zijn je tabellen weg Het hangt natuurlijk helemaal van de site af, en wat voor users je hebt, maar in principe is het aan te raden altijd van het ergste uit te gaan en er gewoon voor te zorgen dat er niets mis kan gaan. In het begin is dat even met veel rekening houden, maar dat wordt al snel routine en dan voeg je al die checks gewoon automatisch toe.

WingsOfFury schreef op woensdag 05 mei 2010 @ 23:50:
Dit brengt mij trouwens bij nog een vraag: hoe kan ik de berichten van beide tabellen in 1 lijst krijgen, gesorteerd op datum? Zodra er een bericht wordt toegevoegd krijgt hij in de DB bij het veld datum een timestamp mee.

Je kunt dit bijvoorbeeld met een UNION doen:

PHP:

$sql = "(SELECT * FROM tabel1) UNION (SELECT * FROM tabel2) ORDER BY datum ASC";

Haakjes hoeven niet, maar is meer voor de duidelijkheid. Hou er wel rekening mee dat * wat gevaarlijk is hier. Omdat je alles van beide tabellen bij elkaar stopt moeten beide queries wel dezelfde kolommen hebben, die ook in dezelfde volgorde staan. Het is meestal duidelijker (voor jezelf en voor anderen die eens met je code moeten werken) om de veldnamen gewoon in de query te noemen. Sowieso nodig bij tabellen die niet geheel hetzelfde zijn, maar die je wel wilt combineren. Bijvoorbeeld:

PHP:

$sql = "
SELECT id, status, datum, user, bericht FROM berichten1
UNION
SELECT id, status, timestamp AS datum, user, bericht FROM berichten2
ORDER BY datum ASC";

[eghie]

pedorus schreef op donderdag 06 mei 2010 @ 01:12:
[...]

In principe is alles met mysql_* ouderwets, en niet meer aan te raden. mysqli_ of pdo is aanbevolen. Welke van beide je dan nog moet kiezen ligt aan wat je zelf beter vindt, hier een voorbeeld (een voorbeeld met pdo+prepared statements was nog mooier geweest).
(En op de oorspronkelijke vraag van TS was natuurlijk optie 1 het goede antwoord in bijna alle gevallen.)

Ik ben zelf ook voorstander van PDO met prepared statements. Werkt toch een stuk netter en beter. Maar aangezien hij al mysql_* hier gebruikt, leek het me handiger om die methode te pakken, want dan hoeft hij zijn applicatie niet om te bouwen. Trouwens mysql_* wordt nog steeds onderhouden in PHP 5.3, geen idee hoe het in PHP 6 zit. Dus ik zelf vind het niet echt "ouderwets", maar ben het zeker eens met de voordelen die mysqli of pdo bieden.

Optie 1 leek mij niet handig. Als die optie mogelijk is, dan is ook dat mijn keuze. Hier gaat het dan voornamelijk om mijn interpretatie met wat hij met de berichten wil doen. Ik schatte in dat hij ze op dezelfde pagina wil lezen, maar dan anders geparsed.

Patriot schreef op donderdag 06 mei 2010 @ 01:35:
[...]


In de context van het testen van dingen die uit de $_GET-array komen is ctype_digit wel de beste oplossing hoor. De problemen die jij noemt treden daar namelijk niet op omdat dat een string is (tenzij je er zelf expliciet een integer in hebt gestopt).

Klopt, in $_GET komt het als string naar voren. Dan kan het zeker. Je hebt alleen soms van die frameworks die er bewerkingen op gaan lopen doen. Daarom sta ik graag aan de safe side wat dat betreft.

[...]


Je snapt wel dat dat dubbel is? Sowieso vind ik het geen slimme oplossing, omdat je in situaties waar het nodig is de gebruiker niet kunt attenderen op een gemaakte fout (je negeert foutieve invoer gewoon).

Zeker snap ik dat het dubbel is. Ik doe het zelf vaak nog weer anders en maak ik gebruik van prepared statements, maar ik wil het beginnende programmeurs nog wel eens op een defensieve manier uitleggen. Dit omdat veel tutorials je minimaal SQL injection je in de hand werken. Dus ook een beetje een tegenwicht. Ik leg de gebruiker liefst eerst de veilige methode uit en later pas waarom andere methodes liever niet gewenst zijn, in plaats van andersom.

Ik genereer foutieve invoer hier ja. Ik er hiervan wel gewoon uit dat hij validatie ernaast regeld. Maar dit houd de applicatie in ieder geval veilig tegen SQL injectie, wat toch de laatste tijd een van de meest gebruikte aanvalsmethodes is. Validatie moet je ook naar mijn mening niet gaan doen, als de query fout loopt, maar daarvoor al.

Ik ben het overigens wel met je eens hoor.

[WingsOfFury]

Er zijn ondertussen zoveel dingen voorbij gekomen die mij totaal (nog) niks zeggen dat ik daar nog wel een tijdje zoet mee ben. Ik heb nu als voorbeeld een berichten site gepakt die niet zo belangrijk is, maar alle informatie die ik daar test kan ik later ook meenemen bij mijn betalende klanten (ik heb een klein webdesign bedrijf), waaronder een aantal webshops. En dan is het wel handig om dingen als mysqli en pdo, en ctype_digit en al het andere moois wat in dit topic besproken is te kennen.

Het topic gaat dus lekker mijn favorieten in en ik ga alles op mijn gemak uitzoeken. De berichten site ga ik volledig opnieuw coderen adhv de tips hier, en ja, dat zal in het begin alleen maar extra werk "lijken", maar het MOET gewoon automatisme worden om de veiligheid van de sites mijn klanten te kunnen garanderen.

Iedereen super bedankt voor alle tips en uitleg! Mocht nog iemand de behoefte voelen om meer informatie te geven dan wil ik dat heel graag, maar ik snap dat dit nogal een algemeen verzoek is

Nogmaals bedankt!

[Gomez12]

Tja 1 extra tip die ik je kan geven is : Vermeld niets concreets in je contracten qua security etc.

Het klinkt heel lullig, maar als hier een boel dingen voorbij zijn gekomen die je niets zeggen dan ben je wmb nog niet klaar voor het grote internet

Het kan vrij duur worden als je iets concreets in je contract met een klant hebt staan en zijn site wordt gehackt...

[Cartman!]

WingsOfFury schreef op donderdag 06 mei 2010 @ 10:15:
Het topic gaat dus lekker mijn favorieten in en ik ga alles op mijn gemak uitzoeken. De berichten site ga ik volledig opnieuw coderen adhv de tips hier, en ja, dat zal in het begin alleen maar extra werk "lijken", maar het MOET gewoon automatisme worden om de veiligheid van de sites mijn klanten te kunnen garanderen.

Dat is ieder geval de juiste insteek, top

[moozzuzz]

Om terug te komen op je vraag wat het snelst is en je hebt niet de mogelijkheden hebt die .oisyn aangeeft. Over het algemeen is de db sneller dan PHP om de bewerkingen uit te voeren.

je wil dan

PHP:

$q = "SELECT B.* FROM tbl_bb AS B WHERE B.status < 4 ORDER BY B.status, B.datum;";
$r  = mysql_query($q) or die(mysql_error()); //$r is geen row maar een resultset (de lijst van rows die je wil uitschrijven!
$prev_status = 0;
while ($v = mysql_fetch_array($r)) {
   if ($prev_status != $v['status']) {
      // schrijf een title uit of doe iets anders.
      $prev_status = $v['status'];
   }
   echo $v['tekst']; 
}

Let op: als je al je 30k berichten wilt uitschrijven naar een browser dan heb je erg veel kans dat deze crasht (want een tabel van 30k rijen vind FF helemaal niet leuk en ook IE heeft er moeite mee om dit te renderen). Ik raad je aan om geen html maar een xls of csv uit te poepen :^)

[Patriot]

eghie schreef op donderdag 06 mei 2010 @ 07:56:
[...]

Klopt, in $_GET komt het als string naar voren. Dan kan het zeker. Je hebt alleen soms van die frameworks die er bewerkingen op gaan lopen doen. Daarom sta ik graag aan de safe side wat dat betreft.

Ok, daar zit wat in. Ik bedoelde meer dat je ctype_digit niet kunt vervangen door iets wat de gegevens gewoon omzet naar int omdat de resultaten van de twee niet op elkaar lijken. Het ene is om te kijken of het een cijfer is, en het ander om er een cijfer van te maken. Dat is natuurlijk nogal een verschil . Als je echt niet zeker weet of iets een integer of string gaat zijn, kun je altijd naar string casten of zelf een wrapper maken die dat voor je doet.

[...]

Zeker snap ik dat het dubbel is. Ik doe het zelf vaak nog weer anders en maak ik gebruik van prepared statements, maar ik wil het beginnende programmeurs nog wel eens op een defensieve manier uitleggen. Dit omdat veel tutorials je minimaal SQL injection je in de hand werken. Dus ook een beetje een tegenwicht. Ik leg de gebruiker liefst eerst de veilige methode uit en later pas waarom andere methodes liever niet gewenst zijn, in plaats van andersom.

Ik genereer foutieve invoer hier ja. Ik er hiervan wel gewoon uit dat hij validatie ernaast regeld. Maar dit houd de applicatie in ieder geval veilig tegen SQL injectie, wat toch de laatste tijd een van de meest gebruikte aanvalsmethodes is. Validatie moet je ook naar mijn mening niet gaan doen, als de query fout loopt, maar daarvoor al.

Ik ben het overigens wel met je eens hoor.

Nouja, met zo'n better-safe-than-sorry-instelling is natuurlijk niets mis

[Verwijderd]

Snelste manier om gegevens uit DB te halen

TRUNCATE `tablename`

[ZaZ]

Verwijderd schreef op vrijdag 07 mei 2010 @ 23:33:
[...]


TRUNCATE `tablename`

Dank! Ik hou me al dagen in om een soortgelijk grapje te maken

[djluc]

Deze discussie is echt alleen maar interessant als het aantal berichten, aantal requests en beschikbare capaciteit duidelijk is. Premature optimalisation wordt geen goed plan, dat werkt in het algemeen alleen maar tegen je.

[WingsOfFury]

Gomez12 schreef op donderdag 06 mei 2010 @ 21:19:
Tja 1 extra tip die ik je kan geven is : Vermeld niets concreets in je contracten qua security etc.

Het klinkt heel lullig, maar als hier een boel dingen voorbij zijn gekomen die je niets zeggen dan ben je wmb nog niet klaar voor het grote internet

Het kan vrij duur worden als je iets concreets in je contract met een klant hebt staan en zijn site wordt gehackt...

Ik ben een paar dagen weggeweest en zie dat het topic toch nog is doorgegaan. Bovenstaand bericht kwam niet als een verrassing, maar ik besef wel dat ik er echt iets aan moet doen. Momenteel zit ik gewoon op hobby niveau, zeg maar mbo-4. Komend schooljaar ga ik een HBO studie ICT & Media Design doen in Eindhoven en dan zal ik alles leren mbt veiligheid en alles wat hier besproken is. Tot die tijd leek het mij een tijdelijke oplossing om met opensource te gaan werken en dan voor Joomla te kiezen. Is dat een goede optie gezien mijn beperkte php/sql kennis?

eghie schreef op donderdag 06 mei 2010 @ 07:56:
[...]
Ik ben zelf ook voorstander van PDO met prepared statements. Werkt toch een stuk netter en beter. Maar aangezien hij al mysql_* hier gebruikt, leek het me handiger om die methode te pakken, want dan hoeft hij zijn applicatie niet om te bouwen. Trouwens mysql_* wordt nog steeds onderhouden in PHP 5.3, geen idee hoe het in PHP 6 zit. Dus ik zelf vind het niet echt "ouderwets", maar ben het zeker eens met de voordelen die mysqli of pdo bieden.

Hier zat ik ook aan te denken, en had eigenlijk gehoopt dat ik mijn mysql_ codering kon vervangen door mysqli_, maar zo simpel zal het vast niet zijn Aangezien ik altijd met mysql_ heb gewerkt is het denk ik wel makkelijker om mysqli_ te leren dan PDO, of vergis ik mij daarin?

Verwijderd schreef op vrijdag 07 mei 2010 @ 23:33:
[...]
TRUNCATE `tablename`

Ik moet eerlijk bekennen dat ik truncate even heb moeten opzoeken, maar ja, je hebt wel gelijk

Ik heb trouwens nog een vraag over het uitlezen van het aantal rijen. Ik gebruik mysql_num_rows om het aantal berichtjes te kunnen zien:

code:

$query_bart = "SELECT * FROM tbl_bb";
$result_bart = mysql_query($query_bart);
$show_bart = mysql_num_rows($result_bart);

Hier komt vervolgens 15172 uit. Maar als ik in de db (InnoDB free in phpMyAdmin?) op de tabel ga met mijn muis dan geeft hij aan dat er 15203 rijen zijn.
Doe ik hetzelfde bij de andere tabel dan geeft mysql_num_rows 12854 aan, en de db gaaft daar 10820 aan.
Welke van de 2 moet ik nou geloven? Bij de een geeft de db meer rijen aan, en bij de ander geeft de db weer minder rijen aan...

[Kalentum]

WingsOfFury schreef op maandag 10 mei 2010 @ 14:14:
Ik heb trouwens nog een vraag over het uitlezen van het aantal rijen. Ik gebruik mysql_num_rows om het aantal berichtjes te kunnen zien:

code:

$query_bart = "SELECT * FROM tbl_bb";
$result_bart = mysql_query($query_bart);
$show_bart = mysql_num_rows($result_bart);

Hier komt vervolgens 15172 uit. Maar als ik in de db (InnoDB free in phpMyAdmin?) op de tabel ga met mijn muis dan geeft hij aan dat er 15203 rijen zijn.
Doe ik hetzelfde bij de andere tabel dan geeft mysql_num_rows 12854 aan, en de db gaaft daar 10820 aan.
Welke van de 2 moet ik nou geloven? Bij de een geeft de db meer rijen aan, en bij de ander geeft de db weer minder rijen aan...

phpmyadmin gebruikt SHOW TABLE STATUS voor die informatie en die geeft voor InnoDB tabellen een schatting. Wil je het echt zeker weten dan kun je het beste een query gebruiken als SELECT COUNT(*) FROM tbl_bb.

[TheNephilim]

Hier komt vervolgens 15172 uit. Maar als ik in de db (InnoDB free in phpMyAdmin?) op de tabel ga met mijn muis dan geeft hij aan dat er 15203 rijen zijn.
Doe ik hetzelfde bij de andere tabel dan geeft mysql_num_rows 12854 aan, en de db gaaft daar 10820 aan.
Welke van de 2 moet ik nou geloven? Bij de een geeft de db meer rijen aan, en bij de ander geeft de db weer minder rijen aan...

InnoDB weet zelf nooit hoeveel rijen er precies in de tabel zitten. Als je num_rows doet, is het als ik mij niet vergis het juiste aantal.

mysql_ vervangen voor mysqli_ is inderdaad niet zomaar mogelijk. De mysqli-connector verreist een link identifier waar de mysql-connector dat nog niet doet. Het makkelijkste is een class te gebruiken om je databaseaanvragen te regelen. Dan doe je (bijv.) $db->query ipv mysql_query ...

[Yoozer]

WingsOfFury schreef op maandag 10 mei 2010 @ 14:14:
alles leren mbt veiligheid

Er zijn een stel eenvoudige basisregels, waarvan de belangrijkste is dat je de gebruiker (en de invoer daarvan) nooit of te nimmer kan vertrouwen. In de browser kun je nummertjes in de URL typen - ergo, gebruikersinvoer, ergo, niet te vertrouwen.

Je moet zeker kunnen zijn van het ingevoerde datatype (als er een getal moet komen moet je "ABC" weigeren), zeker kunnen zijn van het bereik (in een messageboard is post 34298 goed, maar -3.1415926 nooit ook al zijn ze beiden getallen).

en alles wat hier besproken is. Tot die tijd leek het mij een tijdelijke oplossing om met opensource te gaan werken en dan voor Joomla te kiezen. Is dat een goede optie gezien mijn beperkte php/sql kennis?

De reden dat ik niet voor een Joomla zou kiezen met beperkte kennis is dat het een ongelofelijke bak structuur eromheen heeft zitten en als er iets fout gaat kun je hoogstwaarschijnlijk niet eens zomaar traceren waar het mis gaat. Verder gebruikt het componentjes - erg leuk, maar vaak doen ze -net- niet precies wat je wil, en dan mag je gaan herschrijven, en da's ook niet altijd even obvious (tel er op dat bij meer dan 20% herschrijven dat je net zo goed from scratch had kunnen beginnen)

Kies liever een light-weight framework; het lost het gedoe met veilige (of niet veilige) queries voor je op maar blijft verder uit de weg van je programmeerwerk. Bonus: URL rewriting wordt vaak al voor je gedaan zodat je geen gedoe hebt met hoi/dit/is/mijn/blog/post/325/jemig-wat-vliegt-de-tijd.html wat er anders uit zou zien als blog.php?showpost=325

Zie bijvoorbeeld iets als http://konstrukt.dk/ - je ziet in het voorbeeld bij http://konstrukt.dk/getting-started-part1.html dat er "firstname = :firstname" wordt gebruikt, wat het hele getyp voor elke keer verbinding te maken lekker van je overneemt; en belangrijker, bij voldoende abstractie zorgt 't er voor dat je gewoon zegt "geef me iets terug op basis van dit SQL statement" - en wat er dan achter hangt (SQL Server, mySQL of wat dan ook boeit dan niet.

[ Voor 13% gewijzigd door Yoozer op 10-05-2010 17:02 ]

[WingsOfFury]

Yoozer schreef op maandag 10 mei 2010 @ 16:46:
[...]

Er zijn een stel eenvoudige basisregels

Dat begrijp ik, maar waar vind ik die?! Ik heb van Academic Services wel "Het complete handboek PHP4" en "MySQL/PHP Database Applicaties", maar die zijn al veroudert. Is het die 50 euro per boek waard om te investeren in de laatste versies of is internet een beter naslagwerk?
En zelfs als ik die boeken zou kopen blijft bovenstaande vraag staan: waar vind ik die basisregels? Om zo maar in het wilde weg een boek van 600 pagina's door te lezen is ook niet echt de beste optie...

Yoozer schreef op maandag 10 mei 2010 @ 16:46:
[...]

De reden dat ik niet voor een Joomla zou kiezen met beperkte kennis is dat het een ongelofelijke bak structuur eromheen heeft zitten en als er iets fout gaat kun je hoogstwaarschijnlijk niet eens zomaar traceren waar het mis gaat. Verder gebruikt het componentjes - erg leuk, maar vaak doen ze -net- niet precies wat je wil, en dan mag je gaan herschrijven, en da's ook niet altijd even obvious (tel er op dat bij meer dan 20% herschrijven dat je net zo goed from scratch had kunnen beginnen)

Kies liever een light-weight framework; het lost het gedoe met veilige (of niet veilige) queries voor je op maar blijft verder uit de weg van je programmeerwerk. Bonus: URL rewriting wordt vaak al voor je gedaan zodat je geen gedoe hebt met hoi/dit/is/mijn/blog/post/325/jemig-wat-vliegt-de-tijd.html wat er anders uit zou zien als blog.php?showpost=325

Zie bijvoorbeeld iets als http://konstrukt.dk/ - je ziet in het voorbeeld bij http://konstrukt.dk/getting-started-part1.html dat er "firstname = :firstname" wordt gebruikt, wat het hele getyp voor elke keer verbinding te maken lekker van je overneemt; en belangrijker, bij voldoende abstractie zorgt 't er voor dat je gewoon zegt "geef me iets terug op basis van dit SQL statement" - en wat er dan achter hangt (SQL Server, mySQL of wat dan ook boeit dan niet.

Dit is een tip waarop ik zat te wachten! Ik weet dat Joomla voor een beginner als ik complete chaos is. Zeker ook omdat het niet alleen php en sql is, maar ook javascript en vast nog andere codeertalen. Ik kan me er aardig doorheen worstelen met Google aan mijn zijde, maar echt fijn werkt het niet voor mij. Daarnaast vind ik het wel echt heel leuk om lekker te puzzelen en zo zelf wat scriptjes in elkaar te zetten. De tip om dus met konstrukt te gaan werken is super!
Maar als ik nou even wil zoeken naar andere light-weight frameworks, zoals Yoozer ze noemt, kan ik dan simpelweg "light-weight framework" in Google in typen, of moet ik dan ergens anders op zoeken? Of kan iemand de 3 (of 4 of 5?) grootste/bekendste even op een rijtje zetten? Ik zoek dan zelf wel even de voor -en nadelen uit, aangezien ik al zoveel ben geholpen hier.

Alvast bedankt!

[ Voor 12% gewijzigd door WingsOfFury op 10-05-2010 21:32 ]

[Serenity]

Ik weet niet wat je doel precies is, maar waarom überhaupt een framework gebruiken als je kleinschalig bezig bent? Je leert er veel meer van om zelf uit te zoeken hoe je bepaalde doelen kan bereiken en zelf iets in elkaar te zetten. Natuurlijk kun je kijken naar (simpele) frameworks en uitzoeken waarom en hoe ze iets doen, en dat vervolgens gebruiken. Je kunt wel starten met een framework, maar dan is de kans groot dat je maar half doorhebt waarom het werkt zoals het werkt. Het aanpassen en uitbreiden naar iets dat het beste aansluit bij wat je probeert te schrijven wordt dan een stuk moeilijker.

[Gomez12]

WingsOfFury schreef op maandag 10 mei 2010 @ 21:27:
[...]
Is het die 50 euro per boek waard om te investeren in de laatste versies of is internet een beter naslagwerk?

Zeker in het begin vind ik het die 50 euro zeker waard.
Inet is op den duur een beter ( / actueler ) naslagwerk, maar dan moet je eerst de bagger van de gems kunnen onderscheiden en wmb kan menig uitgever dat beter doen dan een beginner.

Naar mijn idee zijn zo ongeveer 90% van alle tuts op inet ( ongeacht onderwerp ) foutief of misleidend omdat ze enkel maar uitgaan van de specifieke situatie die dan optreed, of omdat de schrijver gewoon niet genoeg kennis heeft.

En zelfs als ik die boeken zou kopen blijft bovenstaande vraag staan: waar vind ik die basisregels? Om zo maar in het wilde weg een boek van 600 pagina's door te lezen is ook niet echt de beste optie...

Waarom is dit niet de beste optie? Er is geen lijstje van 10 gouden regels die altijd opgaan. Voor zo ongeveer elke don't is er wel een do-argument te verzinnen, als de situatie daarom vraagt.
600 pagina's kan enigszins evenwicht bieden in die regels.

[The Eagle]

Als ex-ERP-developer en nu ERP infrastructureel figuur kan ik je eigenlijk wel wat vuistregels meegeven:

• Een databaseserver is gemaakt voor het ophalen en sorteren van ruwe data. Een applicatieserver / webserver al een stuk minder. Je dataprocessing wil je dus zoveel mogelijk op de DB server doen en niet in je webapp
• Op basis van bovenstaande zal het gebruik van een query die toegespitst geschreven is voor het ophalen van specifieke data (veel where clauses etc ), altijd sneller, of in het ergste geval even snel zijn als een query die een bulk ophaalt en het zaakje vervolgens door de app/webserver laat sorteren.
• Het gebruik van DB-objecten als indexen kan het ophalen van queries een boost geven. Dat hoeft echter zeer zeker niet. Afhankelijk van de op te halen data kan de queryoptimizer van het DBMS er namelijk voor kiezen om een full table scan te doen ipv specifieke data te pakken, en dan is een query nutteloos.
• Als je echt gaat tunen, vergeet dan ook niet naar de combinatie van je DB en je OS te kijken. Heeft die full table scan soms ook (zijdelings) mee te maken. Maar die diepte wil ik je nog niet ingooien; bovendien is dit ook DBMS-specifiek

[Yoozer]

Serenity schreef op maandag 10 mei 2010 @ 21:51:
Ik weet niet wat je doel precies is, maar waarom überhaupt een framework gebruiken als je kleinschalig bezig bent?

Gemak dient de mens. Met $Db->Query() hoef je je nooit druk te maken om wat er onder zit, of je queries wel goed geescape'd zijn, of de server magic quotes aan of uit heeft, of je op die pagina wel verbinding maakt, en kun je je op de code zelf storten. Als je er templates bij doet is het nog makkelijker. Als je ziet hoe snel je een Hello World hebt staan - waarom zou je dan uberhaupt nog in Wordpress of wat dan ook gaan duiken (wat een tweede keuze zou zijn, maar dan moet je je vooral richten op stylen, gebruik van bestaande plugins, en niks met de PHP willen doen, of met tegenzin).

Nog beter; $Db->Select("* FROM posts ORDER BY date_posted DESC"); geeft je gelijk schaalbaarheid (het is dan een peuleschil om alle SELECTS naar slaves te sturen en alle INSERT/UPDATE/DELETEs naar de master, omdat ze al op functie-niveau gescheiden zijn).

Voor kleinschalig gebruik ga je ook zelf geen JS meer doen maar gebruik je jQuery of Mootools. Het maakt de klus hoe dan ook makkelijker, en includen is 2 seconden werk.

Je leert er veel meer van om zelf uit te zoeken hoe je bepaalde doelen kan bereiken en zelf iets in elkaar te zetten.

En dan doe je het fout, omdat je een stuk code uit 2004 las waar toevallig iets in stond wat je nodig had, wat vervolgens een enorm security-lek presenteert. En zo krijg je allerhande zelfgebakken fora waar je na 2 uur opeens alleen maar TURKISH/CHINESE/RUSSIAN HACKER CREW WAS HERE aantreft, plus een hoop porno van twijfelachtige oorsprong.

WingsOfFury schreef op maandag 10 mei 2010 @ 21:27:
Dat begrijp ik, maar waar vind ik die?! Ik heb van Academic Services wel "Het complete handboek PHP4" en "MySQL/PHP Database Applicaties", maar die zijn al veroudert.

Ja.

Is het die 50 euro per boek waard om te investeren in de laatste versies of is internet een beter naslagwerk?

Het is allebei la-la, want er hangt een hoop af van de kwaliteit van de schrijver. Omdat 't een boek is wil dit nog niet altijd zeggen dat 't goed is.

En zelfs als ik die boeken zou kopen blijft bovenstaande vraag staan: waar vind ik die basisregels?

Kijk naar de manier waarop webapplicaties gekraakt worden. Blokkeer die manieren. Zie bijv. Wikipedia: Cross-site scripting . Gebrek aan optimalisatie kun je altijd afkopen door een paar honderd euro extra aan je server te spenderen; veiligheid is onbetaalbaar.

Wat ik noemde was al het voorbeeld van een getal in een querystring en wat je moet controleren.

Op GoT heb je een aantal forums die niet toegankelijk zijn voor Henkie van 12 die z'n Medion-computer opeens ziet roken en "hij doet 't niet lol wtf wat nu :s" zegt. Daar moet 'ie langer lid voor zijn, en de rechten daarop moeten toegekend worden door een administrator.

Dus, dan heb je met het volgende te maken:

- heeft de gebruiker zich bekend gemaakt met de juiste credentials (authentication)
- heeft de gebruiker het recht om iets te bekijken (authorization)
- heeft de gebruiker eigendomsrechten op wat hij wil bekijken (ownership)

Die controle moet je bij alles uitvoeren wat niet voor jan en alleman zichtbaar moet zijn, en als je dat vergeet in te bakken in een pagina is het over. Elk van die dingen is een mogelijk zwak punt. Als voorbeeld: heb je iets als gebruiker_id=23&product_id=12 en kan ik daar andere getallen invullen zonder dat de applicatie een kik geeft, dan heb je een probleem met alledrie. Laat je in het inlogveld toe dat ik SQL injection kan doen, dan heb je een probleem met nr. 1. Enzovoort.

Dit is een tip waarop ik zat te wachten! Ik weet dat Joomla voor een beginner als ik complete chaos is. Zeker ook omdat het niet alleen php en sql is, maar ook javascript en vast nog andere codeertalen.

Javascript doet alleen wat leuke dingetjes aan de client side. Je kunt alles doen zonder ooit een regel JS te gebruiken, maar dan blijf je dus heel vaak de pagina verversen. Dan nog is kennis van JS - zeker als je aan het ontwerpen komt van webapps - gruwelijk nuttig. Leer het, en dan bedoel ik niet de lullige alert('hoi pipeloi'); zooi maar een populair framework.

Maar als ik nou even wil zoeken naar andere light-weight frameworks, zoals Yoozer ze noemt, kan ik dan simpelweg "light-weight framework" in Google in typen

Da's precies wat ik gedaan heb en toen kwam ik op precies dezelfde vraag op StackOverflow uit. Daar werd een hele ris suggesties gegeven.

http://stackoverflow.com/...ication-framework-for-php

Lees de howto's door, kijk of ze recent zijn en geupdate worden door de auteur (geen enkel framework is perfect, en een dood framework is rot) en wat de activiteit er rondom is.

[ Voor 73% gewijzigd door Yoozer op 10-05-2010 22:47 ]

[Serenity]

Yoozer schreef op maandag 10 mei 2010 @ 22:25:
[...]
Gemak dient de mens.

Natuurlijk, het is makkelijker in sommige situaties en voor sommige toepassingen. Neemt niet weg dat het erg handig is om eerst te weten hoe zo'n framework tot stand komt en beter te begrijpen wat erbij komt kijken. Dan kun je zelf veel beter beoordelen wat je nodig hebt, en dat maakt het uitbreiden en specificeren naar je eigen wensen een stuk gemakkelijker. De OP geeft ook aan dat hij hierin geïnteresseerd is, volgend jaar ook een studie kiest in deze richting en het leuk vindt zelf scripts te schrijven en dit uit te proberen.

Yoozer schreef op maandag 10 mei 2010 @ 22:25:
[...]En dan doe je het fout, omdat je een stuk code uit 2004 las waar toevallig iets in stond wat je nodig had, wat vervolgens een enorm security-lek presenteert. En zo krijg je allerhande zelfgebakken fora waar je na 2 uur opeens alleen maar TURKISH/CHINESE/RUSSIAN HACKER CREW WAS HERE aantreft, plus een hoop porno van twijfelachtige oorsprong.

Stel je voor, leren door te doen . Als je zo redeneert kan niemand ooit meer iets zelf uitproberen en gaandeweg leren, want dan loop je de kans dat je 't verkeerd doet. Voor zover ik weet gaat het hier gewoon om een simpele site. Ik zie niet in waarom je dit niet gewoon zelf kan schrijven i.p.v. een framework te gebruiken waarvan je nog niet weet wat de helft doet en wellicht nog meer niet eens gebruikt.

[Verwijderd]

Omdat juist voor een simpele site dat soort fouten wordt gemaakt.

[Serenity]

Verwijderd schreef op dinsdag 11 mei 2010 @ 00:05:
Omdat juist voor een simpele site dat soort fouten wordt gemaakt.

En wat is je alternatief? Niks leren want je gaat toch fouten maken, en maar vertrouwen op een framework?

[Verwijderd]

Serenity schreef op dinsdag 11 mei 2010 @ 00:32:

En wat is je alternatief? Niks leren want je gaat toch fouten maken, en maar vertrouwen op een framework?

Als je denkt dat je niks leert als je een framework gebruikt ben je in elk geval niet goed wijs.

[Serenity]

Je mist m'n punt. Er iets niets mis met zelf eerst de basis leren en uitvogelen hoe die frameworks überhaupt tot stand komen, alvorens je besluit dat een specifiek framework aan je eisen en wensen voldoet, om dit vervolgens efficiënter en doelgerichter te kunnen gebruiken. Net als dat, om terug te komen op Yoozer's voorbeeld, je veel voordeel hebt met het leren van standaard JavaScript voordat of wanneer je jQuery gaat gebruiken. Als je erin geïnteresseerd bent en je de tijd ervoor hebt kun je ook gewoon bij 't begin beginnen, dan raak je ook een heel stuk sneller bekend met een framework.

[WingsOfFury]

Een standaard framework gebruiken is gewoon een makkelijke manier om het te leren. Ik heb heel duidelijk gemerkt dat het lezen van codeertalen vele malen makkelijker is dan het schrijven (tot je genoeg ervaring hebt). Bovendien is een framework, of een Joomla, of wat dan ook, vaak nog net niet zoals je hem zelf wilt en moet je toch een beetje knutselen, knippen en plakken. Zodoende leer je dan inderdaad door je fouten: als iets niet werkt, doe je even CTRL-Z in Dreamweaver en je kunt kijken hoe het dan wel moet. Mocht alles compleet verkloot zijn, dan kun je het framework weer opnieuw downloaden en opnieuw beginnen.

Dit is echter de 2e reden om met een framework te gaan werken, de belangrijkste reden is namelijk dat ik denk dat het huidige login script wat ik gebruik niet veilig is, en daarnaast trouwens ook de andere scripts die ik hanteer. Het is door een oud collega van mij gemaakt, en ook gebruik ik een webshop die door hem gemaakt is, maar zijn kennis was toch nog niet zo groot. De meeste dingen worden simpelweg met $_GET's opgehaald uit de adresbalk en zijn niet beveiligd. Ik wil mijn klanten die veiligheid wel kunnen bieden, maar heb niet genoeg kennis om van nul te beginnen. En leren adhv een framework/voorbeeld gaat dan dus sneller.

Als ik komend schooljaar die ICT studie ga doen begin ik wel van nul en kan ik alles op mijn manier coderen. Tot die tijd is het handig om in ieder geval de login's en $_GET's en nog wat andere dingen veilig te hebben mbv iemand anders zijn script (framework).

Edit: een boek is trouwens ook een "soort" framework, of in ieder geval een naslagwerk met voorbeelden. Ik heb regelmatig met de boeken die ik heb op schoot gezeten om dingen op of uit te zoeken. En uit die boeken dus ook veel voorbeelden over genomen. Zo zie ik een compleet framework ook, als een groot voorbeeld. En daarvoor is Joomla dus veel te groot, uitgebreid en ingewikkeld voor een beginner.

Welke boeken zouden jullie mij aanraden dan? Of welke schrijver(s)?

[ Voor 13% gewijzigd door WingsOfFury op 11-05-2010 20:23 ]

[eghie]

Als je snel een beetje goede en veilige code wilt schrijven, kan ik je de volgende stappen aanraden.

Leer eerst veilig kale PHP te programmeren. Het handigst is om hier PDO voor te gebruiken, omdat deze methode toekomstig gezien gigantisch veel beter ligt dan de mysql(i)_* methodes en omdat hij minder fout gevoelig is en ook van nature uit (manier van programmeren) een stuk veiliger is.

Hier een paar tutorials die je door kunt lopen, om eens kaal naar PHP te kijken icm beveiliging:
• http://www.phpfreaks.com/tutorial/php-security
• http://www.addedbytes.com/writing-secure-php
• http://www.codeproject.co.../SqlInjectionAttacks.aspx
• http://www.php-security.o...ur-dynamic-php/index.html
• http://php-security.org/2010/05/01/article-php-web-security/

Als je dan een beetje weet hoe dat allemaal werkt en een beetje weet hoe PDO prepared statements werken, dan is het handig om op een framework over te stappen, zodat je een beetje met code structuur leert om te gaan en kunt kijken naar hun voorbeelden.

Voor een framework met goede documentatie voor beginners kun je eens kijken naar Yii Framework.
En loop dan de documentatie stap voor stap door: http://www.yiiframework.com/doc/guide/quickstart.what-is-yii

[ Voor 5% gewijzigd door eghie op 21-05-2010 16:21 ]

[WingsOfFury]

Thanks eghie, dit is echt een fijne tip! Als PDO de toekomst heeft en mysqli_ niet, dan ga ik inderdaad met PDO beginnen. Ik ga de tuts doornemen die je mij gegeven hebt en wil er meteen een boek bij bestellen. Ik weet niet of dit de bedoeling is van GoT, maar zou iemand mij een tip kunnen geven voor een goed boek?

Over Academic Service ben ik erg te spreken, met name de "Het complete handboek"-serie, maar iemand heeft al aangegeven dat de qualiteit alsnog per auteur kan verschillen, vandaar dat ik op een tipje hoop