[PHP/(My)SQL] voor dummies #110

Index

» digital corner

» development

actieve topics nieuwe topics
abonnement Unibet Coolblue Bitvavo
pi_128329074
quote:
0s.gif Op donderdag 27 juni 2013 13:39 schreef mstx het volgende:
Ik kwam net weer eens een prachtige query tegen van een oud-collega:
[ code verwijderd ]

_O_ (het is dezelfde tabel)
Als het nou op een ander veld was het helemaal niet zo gek geweest, voorbeeld is een werknemerstabel waarbij er een veld leidinggevende is welke correspondeerd met het werknemerId.
🕰️₿🕰️₿🕰️₿🕰️₿🕰️₿🕰️ TikTok next Block
pi_128421826
Ik wil temperatuur in een Mysql database opslaan, maar zit even te twijfelen wat ik het beste kan gebruiken. Float, Double, Decimal of Real?

Mijn eerste keuze zou een float zijn, maar ik weet dat als je geld opslaat in een DB dat je Decimal moet gebruiken, aangezien temperatuur aardig op geld lijkt (ook twee cijfers achter de komma [in ieder geval hoe ik het aangeleverd krijg]). Zou ik zeggen Decimal is een veilig keuze, maar ik ga niet rekenen met deze cijfers, dus Float zou volgens mij ook wel kunnen.

Kan iemand de beste keuze kunnen uitleggen en wat standaarden hiervoor zijn?
  † In Memoriam † zondag 30 juni 2013 @ 15:42:05 #63
159335 Boze_Appel
Vrij Fruit
pi_128422313
quote:
0s.gif Op zondag 30 juni 2013 15:29 schreef Pakspul het volgende:
Ik wil temperatuur in een Mysql database opslaan, maar zit even te twijfelen wat ik het beste kan gebruiken. Float, Double, Decimal of Real?

Mijn eerste keuze zou een float zijn, maar ik weet dat als je geld opslaat in een DB dat je Decimal moet gebruiken, aangezien temperatuur aardig op geld lijkt (ook twee cijfers achter de komma [in ieder geval hoe ik het aangeleverd krijg]). Zou ik zeggen Decimal is een veilig keuze, maar ik ga niet rekenen met deze cijfers, dus Float zou volgens mij ook wel kunnen.

Kan iemand de beste keuze kunnen uitleggen en wat standaarden hiervoor zijn?
Als je er niet mee gaat rekenen, waarom sla je ze dan op?

Anyway, gewoon een decimal (4,1) gebruiken. Tenzij je dik dure apparatuur hebt is temperatuur opslaan met twee decimalen vrij onzinnig.
Carpe Libertatem
pi_128425070
quote:
7s.gif Op zondag 30 juni 2013 15:42 schreef Boze_Appel het volgende:

[..]

Als je er niet mee gaat rekenen, waarom sla je ze dan op?
Niet mee rekenen in de zin van ik ga geen percentages er over heen gooien om daarna totalen te gaan berekenen. Meer datamining, zodat ik later kan kijken of ik ze kan gebruiken om beslissingen op te maken.
quote:
Anyway, gewoon een decimal (4,1) gebruiken. Tenzij je dik dure apparatuur hebt is temperatuur opslaan met twee decimalen vrij onzinnig.
Arduino zit er achter, vet dure apparatuur dus :P
pi_128441331
quote:
7s.gif Op zondag 30 juni 2013 15:42 schreef Boze_Appel het volgende:

[..]

Als je er niet mee gaat rekenen, waarom sla je ze dan op?

Anyway, gewoon een decimal (4,1) gebruiken. Tenzij je dik dure apparatuur hebt is temperatuur opslaan met twee decimalen vrij onzinnig.
Als je twee decimalen aangeleverd krijgt, waarom zou je er dan maar 1 opslaan?
fokstok.nl
  † In Memoriam † zondag 30 juni 2013 @ 23:38:39 #66
159335 Boze_Appel
Vrij Fruit
pi_128441546
quote:
0s.gif Op zondag 30 juni 2013 23:33 schreef Light het volgende:

[..]

Als je twee decimalen aangeleverd krijgt, waarom zou je er dan maar 1 opslaan?
Kan opzich natuurlijk wel, maar het is een beetje als een rondje hardlopen op de cm nauwkeurig opslaan. Het gaat om gemeten temperatuur door een apparaat van nog geen tientje. Ik denk dat je al blij moet zijn als dat ding hele graden nauwkeurig doet, laat staan honderdste graden.

Ik ben van mening dat je data op basis van relevantie en toepasbaarheid op moet slaan en niet data moet bewaren 'omdat het kan'.
Carpe Libertatem
pi_128441555
Gebruik gewoon een int en sla de temp. in honderdste graden celcius op.
zcflevo.nl
pi_128442945
quote:
7s.gif Op zondag 30 juni 2013 23:38 schreef Boze_Appel het volgende:

[..]

Kan opzich natuurlijk wel, maar het is een beetje als een rondje hardlopen op de cm nauwkeurig opslaan. Het gaat om gemeten temperatuur door een apparaat van nog geen tientje. Ik denk dat je al blij moet zijn als dat ding hele graden nauwkeurig doet, laat staan honderdste graden.

Ik ben van mening dat je data op basis van relevantie en toepasbaarheid op moet slaan en niet data moet bewaren 'omdat het kan'.
quote:
7s.gif Op zondag 30 juni 2013 23:38 schreef Boze_Appel het volgende:

[..]

Kan opzich natuurlijk wel, maar het is een beetje als een rondje hardlopen op de cm nauwkeurig opslaan. Het gaat om gemeten temperatuur door een apparaat van nog geen tientje. Ik denk dat je al blij moet zijn als dat ding hele graden nauwkeurig doet, laat staan honderdste graden.

Ik ben van mening dat je data op basis van relevantie en toepasbaarheid op moet slaan en niet data moet bewaren 'omdat het kan'.
Dat ligt er m.i. ook aan wat je meet. Kamertemperatuur in honderdste graden is niet echt zinnig maar bij een experiment kan die nauwkeurigheid wel nuttig zijn.
fokstok.nl
  † In Memoriam † maandag 1 juli 2013 @ 00:25:14 #69
159335 Boze_Appel
Vrij Fruit
pi_128443610
quote:
0s.gif Op maandag 1 juli 2013 00:09 schreef Light het volgende:

Dat ligt er m.i. ook aan wat je meet. Kamertemperatuur in honderdste graden is niet echt zinnig maar bij een experiment kan die nauwkeurigheid wel nuttig zijn.
Eens, maar als er al aangegeven wordt er niet mee te willen rekenen kan je 'experiment' meteen wel uitsluiten. ;)
Carpe Libertatem
pi_128446863
tvp, ben bezig met een site voor mn pa, dus ik ga jullie waarschijnlijk nog wel lastig vallen :)
pi_128529606
God wat is het toch vervelend om regexjes op grote bestanden af te sturen :{ :+

Heb een 2MB bestand en wilde deze eerst in 1x door preg_match_all halen, nou daar had PHP niet echt zin in en koste ruim een UUR!! lol, nu heb ik een benchmark gedaan om het bestand in stukken te verdelen en dat komt de snelheid ten goede..

stukken van 25000 (etc) + 500 extra (straks mis ik nog wat)

25500 bytes per keer - 709 seconden
10500 bytes per keer - 239 seconden
5500 bytes per keer - 130 seconden
3000 bytes per keer - 54 seconden
1500 bytes per keer - 22 seconden

:{ raar, kan iemand mij uitleggen waarom dit zo langzaam gaat? :@
The people who lost my respect will never get a capital letter for their name again.
Like trump...
  woensdag 3 juli 2013 @ 10:37:05 #72
178193 Juicyhil
Bekende FOK!ker
pi_128529695
quote:
5s.gif Op woensdag 3 juli 2013 10:33 schreef Chandler het volgende:
God wat is het toch vervelend om regexjes op grote bestanden af te sturen :{ :+

Heb een 2MB bestand en wilde deze eerst in 1x door preg_match_all halen, nou daar had PHP niet echt zin in en koste ruim een UUR!! lol, nu heb ik een benchmark gedaan om het bestand in stukken te verdelen en dat komt de snelheid ten goede..

stukken van 25000 (etc) + 500 extra (straks mis ik nog wat)

25500 bytes per keer - 709 seconden
10500 bytes per keer - 239 seconden
5500 bytes per keer - 130 seconden
3000 bytes per keer - 54 seconden
1500 bytes per keer - 22 seconden

:{ raar, kan iemand mij uitleggen waarom dit zo langzaam gaat? :@
Lees je hem tegelijkertijd van de harde schijf af? Dat gaat namelijk altijd langzaam. Eerst in het geheugen stoppen en daarna pas checken met regex.
Op dinsdag 9 augustus 2011 23:01 schreef SuperrrTuxxx het volgende:
Ik hou zoveel van jou, ik doe alles voor je! O+
pi_128529759
het hele document zit in het geheugen! :) dus dat is het probleem niet...

Sterker nog, het document wordt geladen in het geheugen vanaf een andere server (curl) en daarna pas door een foreach loopje bewerkt.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22		<?php
        $t = time();
        $parseCls  = new parse();
        $size = 1000;
        echo '<pre>';
        if (strlen($document) > $size)
        {
            $loop = ceil(strlen($document) / $size);
            $start = 0;
            for ($x = 0; $x < $loop; $x++)
            {
                echo date("Y-m-d H:i:s") . ' - ' . ($x * $size) . ' - ' . ($size + 500) . ' of ' . strlen($document) . '<br />';
                $start = substr($document, $x * $size, $size + 500);
                $parseCls->parse($start);
            }
        }
        else
        {
            print_r($parseCls->parse($document));
        }
        echo '</pre>';
?>


[ Bericht 41% gewijzigd door Chandler op 03-07-2013 10:46:37 ]
The people who lost my respect will never get a capital letter for their name again.
Like trump...
  woensdag 3 juli 2013 @ 11:34:08 #74
25889 Sitethief
Fulltime Flapdrol
pi_128531465
quote:
5s.gif Op woensdag 3 juli 2013 10:33 schreef Chandler het volgende:
God wat is het toch vervelend om regexjes op grote bestanden af te sturen :{ :+

Heb een 2MB bestand en wilde deze eerst in 1x door preg_match_all halen, nou daar had PHP niet echt zin in en koste ruim een UUR!! lol, nu heb ik een benchmark gedaan om het bestand in stukken te verdelen en dat komt de snelheid ten goede..

stukken van 25000 (etc) + 500 extra (straks mis ik nog wat)

25500 bytes per keer - 709 seconden
10500 bytes per keer - 239 seconden
5500 bytes per keer - 130 seconden
3000 bytes per keer - 54 seconden
1500 bytes per keer - 22 seconden

:{ raar, kan iemand mij uitleggen waarom dit zo langzaam gaat? :@
Some people, when confronted with a problem, think
“I know, I'll use regular expressions.” Now they have two problems.
Stroek: Sitethief, die is heel groot en sterk :Y.
Faat: *zucht* zoals gewoonlijk hoor Sitethief weer in de bocht &gt;:)
  woensdag 3 juli 2013 @ 11:37:31 #75
187069 slacker_nl
Sicko pur sang
pi_128531585
quote:
0s.gif Op woensdag 3 juli 2013 10:37 schreef Juicyhil het volgende:

[..]

Lees je hem tegelijkertijd van de harde schijf af? Dat gaat namelijk altijd langzaam. Eerst in het geheugen stoppen en daarna pas checken met regex.
Gewoon telkens een x-aantal blokken lezen, dan parsen, dan weer verder lezen, dan parsen, etc etc. http://php.net/manual/en/function.fread.php Welk even flocken, anders gaan er andere processen naar willen schrijven en gaat het (mogelijk) fout.
In theory there is no difference between theory and practice. In practice there is.
pi_128531706
Dat doe ik dus nu, plus ik voeg 500 bytes extra toe om niets te missen... :D
The people who lost my respect will never get a capital letter for their name again.
Like trump...
  Moderator / Redactie Sport / Devops woensdag 3 juli 2013 @ 11:50:21 #77
176766 zoem
zoemt
pi_128532007
quote:
5s.gif Op woensdag 3 juli 2013 10:33 schreef Chandler het volgende:
:{ raar, kan iemand mij uitleggen waarom dit zo langzaam gaat? :@
Ja en nee. Dat hangt compleet van de gebruikte regex af. Een inefficiente regex kan (onnodig) lang duren, zeker als het om veel karakters gaat (oa ivm backtracking). Wat voor regex pattern gebruik je?
pi_128532386
"/[a-z0-9]+([_\\.-][a-z0-9]+)*@([a-z0-9]+([\.-][a-z0-9]+)*)+\\.[a-z]{2,}/i"

Om emails te parsen! :) ik krijg links met documenten aangeleverd die ik moet omzetten naar een database tabel...
The people who lost my respect will never get a capital letter for their name again.
Like trump...
  Moderator / Redactie Sport / Devops woensdag 3 juli 2013 @ 12:15:46 #79
176766 zoem
zoemt
pi_128532931
Aha, de bekende email-regex :P

Ik zie een aantal nested quantifiers, wellicht is dit interessant leesvoer: Catastrophic backtracking.

Ik heb nu helaas niet de tijd om deze regex te optimaliseren, maar misschien wel een tip: probeer niet alles in een regex te vrotten. Je kunt ook ruwweg alle strings lijkende op emailadressen eruit halen en daarna de $matches array loopen voor een nadere validatiestap. Dus trek de filterstap en validatiestap wat uit elkaar.
  woensdag 3 juli 2013 @ 13:02:19 #80
187069 slacker_nl
Sicko pur sang
pi_128534603
quote:
0s.gif Op woensdag 3 juli 2013 12:00 schreef Chandler het volgende:
"/[a-z0-9]+([_\\.-][a-z0-9]+)*@([a-z0-9]+([\.-][a-z0-9]+)*)+\\.[a-z]{2,}/i"

Om emails te parsen! :) ik krijg links met documenten aangeleverd die ik moet omzetten naar een database tabel...
Alles achter de @ kan je hiertegen aangooien:

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		{                                                                                                                                                                         
    # The following is stolen from:
    # http://cpansearch.perl.org/src/CREIN/Regexp-Common-dns-0.00_01/lib/Regexp/Common/dns.pm
    # So we don't need to install the dependency which is not in the Debian repository
    #    
    sub _domain {
        my %flags = @_;

        my $sep = '\.';

        my $letter      = '[a-zA-Z]';
        my $let_dig     = '[a-zA-Z0-9]';
        my $let_dig_hyp = '[-a-zA-Z0-9]';

        my %labels = (
            1035   => "(?:$letter(?:$let_dig|$let_dig_hyp\{1,61}$let_dig)?)",
            1123   => "(?:(?:$let_dig|$let_dig$let_dig_hyp*$let_dig)$sep)*(?:$let_dig|$let_dig$let_dig_hyp*$let_dig)",
            2181   => '[^.]{1,63}',
            hybrid => '[a-zA-Z0-9_-]{1,63}'
        );   

        $flags{'-rfc'} ||= 1035;

        my $label = $labels{$flags{'-rfc'}} || die("Unknown DNS RFC: $flags{'-rfc'}");

        if ($flags{'-rfc'} ne 2181 && exists $flags{'-wildcard'} && not defined $flags{'-wildcard'}) {
            $label = "(?:\\*|$label)";
        }    

        my $quant = '*'; 
        if ($flags{'-minlabels'}) {
            $quant = '{' . ($flags{'-minlabels'} - 1) . ',}';
        }    

        return qr/^(?:$label$sep)$quant$label$sep?$/;
    }    

    my $fqdn_regexp = _domain(-rfc => 1123, -minlabels => 2);

    use constant VALID_FQDN => sub {
        my $fqdn = shift;
        if ($fqdn && $fqdn =~ m/$fqdn_regexp/) {
            $fqdn =~ s/\.$//;
            return 0 if (length($fqdn) > 255);
            return 0 if (grep { length($_) > 63 } split(/\./, $fqdn));
            return 1;
        }    
        return 0;
    };   
}

Je mag het zelf verphp'en. Dan kan je vervolgens alles voor de @ ook nog eens goed parsen en dan ben je klaar.
In theory there is no difference between theory and practice. In practice there is.
  Moderator / Redactie Sport / Devops woensdag 3 juli 2013 @ 13:54:15 #81
176766 zoem
zoemt
pi_128536936
En voor je het weet heb je zoiets: http://www.perlmonks.org/?node_id=393809 :X

Ik zou het lekker simpel houden. Als het even kan zou ik filter_var() (php >= 5.2.0) erbij betrekken voor de validatie.
pi_128540548
quote:
12s.gif Op woensdag 3 juli 2013 13:54 schreef zoem het volgende:
En voor je het weet heb je zoiets: http://www.perlmonks.org/?node_id=393809 :X

Ik zou het lekker simpel houden. Als het even kan zou ik filter_var() (php >= 5.2.0) erbij betrekken voor de validatie.
:D

filter_var gebruikt trouwens intern ook een enorme regex :P
..///
  maandag 8 juli 2013 @ 09:23:31 #83
25889 Sitethief
Fulltime Flapdrol
pi_128711732
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21		<?php
    public function compareValues($type,$compare1,$compare2){
        $count1 =0;
        $count2 =0;
        switch ($type) {
            case 'Doctype':
                $var = '\$v->data->doctype';
                break;

            default:
                break;
        }
        foreach($this->selectedData as $k=>$v){
            $val = 'empty';
            eval('$val = '.$var.';');
            if($val && $val === $compare1)++$count1;
            if($val && $val === $compare2)++$count2;
        }
        return $count1.$count2;
    }
?>

Ik wil deze functie gebruiken om dynamisch bepaalde waardes in een array met objecten te vergelijken. Het probleem is dat ik meerdere type data wil kunnen vergelijken die op meerdere plekken in het object zitten. Weet iemand of het mogelijk is om, met bijvoorbeeld eval, deze op een makkelijke manier dynamisch aan te maken? Anders moet ik die foreach in iedere case stoppen en dat vind ik toch niet een goede, beheersbare oplossing. Maar eval zelf is ook niet zo heel erg tof.

Wat ik tot nu toe kon vinden is dit alleen maar mogelijk bij statisch properties.
Stroek: Sitethief, die is heel groot en sterk :Y.
Faat: *zucht* zoals gewoonlijk hoor Sitethief weer in de bocht &gt;:)
pi_128855608
Ik heb een query die raar doet wanneer ik gebruik wil maken van ORDER BY.

Zonder order by is deze query 0.0043 seconden, met ORDER BY `failed` kost deze query ruim 23 seconden!?

1
2
3
4
5
6
7		SELECT  `spider`.`id` AS spiderID,  
`spider`.`url` AS spiderURL,  
`spider`.`failed` AS spiderFailed
FROM  `spider` 
WHERE  `spider`.`project_id` =7
AND  `spider`.`processed` =0
LIMIT 1

Als ik een URL laad wil ik het liefst URLS laden die ik nog niet heb gehad (processed = 0) maar liefst ook de URLS die nog niet gelezen en mislukt zijn. Met huidige query lees ik deze 3x achter elkaar alvorens processed op 1 te zetten, alleen nu wilde ik met ORDER BY 'failed' ASC de URLS met een waarde die groter is dan 0 achter aan zetten en de URLS met waarde van 0 natuurlijk vooraan... oftewel eerst uitlezen.

Tabel
1
2
3
4
5
6
7
8
9
10
11		CREATE TABLE IF NOT EXISTS `spider` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `project_id` bigint(20) unsigned NOT NULL,
  `url` varchar(255) NOT NULL,
  `processed` tinyint(1) NOT NULL DEFAULT '0',
  `failed` tinyint(4) NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`),
  UNIQUE KEY `project_id_2` (`project_id`,`url`),
  KEY `failed` (`failed`),
  KEY `project_id` (`project_id`,`processed`)
) ENGINE=InnoDB  DEFAULT CHARSET=latin1 AUTO_INCREMENT=103771614 ;

Iemand een idee? oh ik heb maar 17m regeltjes....
The people who lost my respect will never get a capital letter for their name again.
Like trump...
  Moderator / Redactie Sport / Devops donderdag 11 juli 2013 @ 23:46:09 #85
176766 zoem
zoemt
pi_128855743
Wat zegt EXPLAIN?
  donderdag 11 juli 2013 @ 23:49:58 #86
330295 Purplesparks
Lovercall baby
pi_128855903
quote:
0s.gif Op donderdag 11 juli 2013 23:42 schreef Chandler het volgende:
Ik heb een query die raar doet wanneer ik gebruik wil maken van ORDER BY.

Zonder order by is deze query 0.0043 seconden, met ORDER BY `failed` kost deze query ruim 23 seconden!?
[ code verwijderd ]

Als ik een URL laad wil ik het liefst URLS laden die ik nog niet heb gehad (processed = 0) maar liefst ook de URLS die nog niet gelezen en mislukt zijn. Met huidige query lees ik deze 3x achter elkaar alvorens processed op 1 te zetten, alleen nu wilde ik met ORDER BY 'failed' ASC de URLS met een waarde die groter is dan 0 achter aan zetten en de URLS met waarde van 0 natuurlijk vooraan... oftewel eerst uitlezen.

Tabel
[ code verwijderd ]

Iemand een idee? oh ik heb maar 17m regeltjes....
Natuurlijk niet het antwoord wat je zoekt. Maar je kan het via een omweg ook gewoon orderen binnen php lijkt me.
Touching from a distance ~
  donderdag 11 juli 2013 @ 23:51:32 #87
178193 Juicyhil
Bekende FOK!ker
pi_128855961
quote:
0s.gif Op donderdag 11 juli 2013 23:49 schreef Purplesparks het volgende:

[..]

Natuurlijk niet het antwoord wat je zoekt. Maar je kan het via een omweg ook gewoon orderen binnen php lijkt me.
Dat gaat je geheugen kosten _O-
Op dinsdag 9 augustus 2011 23:01 schreef SuperrrTuxxx het volgende:
Ik hou zoveel van jou, ik doe alles voor je! O+
  donderdag 11 juli 2013 @ 23:52:46 #88
330295 Purplesparks
Lovercall baby
pi_128856016
quote:
0s.gif Op donderdag 11 juli 2013 23:51 schreef Juicyhil het volgende:

[..]

Dat gaat je geheugen kosten _O-
True dat, maar een potentiėle mogelijkheid als chandler niet de oplossing weet te vinden van de lange order tijd.
Touching from a distance ~
  donderdag 11 juli 2013 @ 23:54:51 #89
178193 Juicyhil
Bekende FOK!ker
pi_128856114
quote:
0s.gif Op donderdag 11 juli 2013 23:42 schreef Chandler het volgende:
Ik heb een query die raar doet wanneer ik gebruik wil maken van ORDER BY.

Zonder order by is deze query 0.0043 seconden, met ORDER BY `failed` kost deze query ruim 23 seconden!?
[ code verwijderd ]

Als ik een URL laad wil ik het liefst URLS laden die ik nog niet heb gehad (processed = 0) maar liefst ook de URLS die nog niet gelezen en mislukt zijn. Met huidige query lees ik deze 3x achter elkaar alvorens processed op 1 te zetten, alleen nu wilde ik met ORDER BY 'failed' ASC de URLS met een waarde die groter is dan 0 achter aan zetten en de URLS met waarde van 0 natuurlijk vooraan... oftewel eerst uitlezen.

Tabel
[ code verwijderd ]

Iemand een idee? oh ik heb maar 17m regeltjes....
Neem anders eens failed op in je where-clause. Dan hoeft hij in wat minder rijen te sorteren.
Edit: oh never mind, niet goed gelezen :P
Op dinsdag 9 augustus 2011 23:01 schreef SuperrrTuxxx het volgende:
Ik hou zoveel van jou, ik doe alles voor je! O+
  Moderator / Redactie Sport / Devops vrijdag 12 juli 2013 @ 00:02:55 #90
176766 zoem
zoemt
pi_128856450
quote:
0s.gif Op donderdag 11 juli 2013 23:51 schreef Juicyhil het volgende:

[..]

Dat gaat je geheugen kosten _O-
Valt erg mee hoor als je het een beetje slim aanpakt, aangenomen dat er gewerkt wordt met een beperkte subset van de 17M rows (processed=0). Maar goed, de query optimaliseren heeft natuurlijk de voorkeur.

[ Bericht 0% gewijzigd door zoem op 12-07-2013 00:48:54 ]
actieve topics nieuwe topics
abonnement Unibet Coolblue Bitvavo
[PHP/(My)SQL] voor dummies #110
Index

» digital corner

» development

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