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

donderdag 27 juni 2013 @ 07:16:29 #51

Light

quote:
Op woensdag 26 juni 2013 11:30 schreef mstx het volgende:
Ik heb zelf ook een vraagje, deze (simpele) query is soms traag:
[ code verwijderd ]

De explain zegt dit:
[ code verwijderd ]

Kan dat sneller?

Ik zou hier in Inner Join gebruiken ipv een Left Join. Je zoekt expliciet naar rijen waar TabelB.KolomY een waarde heeft, dus voegt het gebruik van een left join niets toe.

fokstok.nl

donderdag 27 juni 2013 @ 08:04:40 #52

mstx

2x1/2 = 1/2 x 1/2

quote:
Op donderdag 27 juni 2013 00:47 schreef Boze_Appel het volgende:

[..]

Indexes erbij maken op type en isactive. Daar doe je de selecties op.

Die indexes zitten er al op.

quote:
Op donderdag 27 juni 2013 07:16 schreef Light het volgende:

[..]

Ik zou hier in Inner Join gebruiken ipv een Left Join. Je zoekt expliciet naar rijen waar TabelB.KolomY een waarde heeft, dus voegt het gebruik van een left join niets toe.

Maar dan selecteert 'ie toch ook rijen uit tabel B die niet gekoppeld zijn aan een rij uit tabel A?

Nog wat dingen geprobeerd maar het probleem zit hem echt in de COUNT() i.c.m. JOIN.

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

SELECT COUNT(*) FROM TabelA
= 0.0002 sec

SELECT COUNT(*) FROM TabelA LEFT JOIN TabelB.................
= 0.25 sec

SELECT COUNT(*) FROM TabelA INNER JOIN TabelB.................
= 0.4 sec

SELECT * FROM TabelA LEFT JOIN TabelB.................
= 0.001 sec

SELECT * FROM TabelA INNER JOIN TabelB.................
= 0.001 sec

SELECT * FROM TabelA
= 0.0004 sec

Ik denk dat ik maar gewoon de kolom van TabelB die ik in de WHERE gebruik kopieer naar TabelA zodat ik niet hoef te joinen.

Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾

donderdag 27 juni 2013 @ 08:09:55 #53

Light

quote:
Op donderdag 27 juni 2013 08:04 schreef mstx het volgende:

Maar dan selecteert 'ie toch ook rijen uit tabel B die niet gekoppeld zijn aan een rij uit tabel A?

Nee.
Bij een left join selecteer je alle rijen uit A en als er geen match in B gevonden kan worden (op basis van de ON clause) dan worden alle velden van B voor die rij gevuld met NULL.
Bij een inner join selecteer je alleen die rijen uit A waarvoor een match in B gevonden kan worden (op basis van de ON clause).

fokstok.nl

donderdag 27 juni 2013 @ 08:22:45 #54

mstx

2x1/2 = 1/2 x 1/2

Ho ik zat even niet op te letten, je hebt gelijk.

Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾

donderdag 27 juni 2013 @ 08:31:58 #55

slacker_nl

Sicko pur sang

quote:
Op donderdag 27 juni 2013 07:00 schreef Chandler het volgende:
Ik voer verder niets specifieks uit met curl, ik gebruik dezelfde opzet als die eerder door Slacker_nl is gegeven (DIG / [PHP/(My)SQL] voor dummies #109)

En het uitlezen van de DNS per URL zou een mogelijkheid zijn, al zou CURL deze url natuurlijk ook gewoon moeten kunnen vinden

Mijn code is altijd bugfree

In theory there is no difference between theory and practice. In practice there is.

donderdag 27 juni 2013 @ 08:33:07 #56

Cue_

Cuecumbergirl

Mensen hier ervaring/voorbeelden van een soap call naar een webservice met PL/SQL?

donderdag 27 juni 2013 @ 10:13:55 #57

Chandler

quote:
Op donderdag 27 juni 2013 08:31 schreef slacker_nl het volgende:

[..]

Mijn code is altijd bugfree

^{juist haha}

maar goed, blijkbaar doe ik iets verkeerd!? ik ga nu eens kijken hoe anderen het doen...

Just say hi!

donderdag 27 juni 2013 @ 13:39:43 #58

mstx

2x1/2 = 1/2 x 1/2

Ik kwam net weer eens een prachtige query tegen van een oud-collega:

1
2
3
4
5
6
7
8
9
10
11
12
13

SELECT
kolommen
FROM
tabel
WHERE
id IN (
          SELECT
            id
          FROM
            tabel
          WHERE
           voorwaarde=1
         )

(het is dezelfde tabel)

Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾

donderdag 27 juni 2013 @ 13:41:02 #59

Chandler

Prachtig! zo leer je sub selects

Just say hi!

donderdag 27 juni 2013 @ 16:00:42 #60

Crutch

Filantroop || Taalzwengel

Hallo! Wat vinden jullie van Symfony?

Je moeder is een hamster

donderdag 27 juni 2013 @ 17:45:14 #61

raptorix

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

(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

zondag 30 juni 2013 @ 15:29:34 #62

Pakspul

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

Boze_Appel

Vrij Fruit

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

zondag 30 juni 2013 @ 17:04:10 #64

Pakspul

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

zondag 30 juni 2013 @ 23:33:33 #65

Light

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

Boze_Appel

Vrij Fruit

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

zondag 30 juni 2013 @ 23:38:47 #67

KomtTijd...

Gebruik gewoon een int en sla de temp. in honderdste graden celcius op.

zcflevo.nl

maandag 1 juli 2013 @ 00:09:24 #68

Light

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

Boze_Appel

Vrij Fruit

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

maandag 1 juli 2013 @ 01:48:32 #70

randomo

tvp, ben bezig met een site voor mn pa, dus ik ga jullie waarschijnlijk nog wel lastig vallen

woensdag 3 juli 2013 @ 10:33:34 #71

Chandler

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?

Just say hi!

woensdag 3 juli 2013 @ 10:37:05 #72

Juicyhil

Bekende FOK!ker

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

woensdag 3 juli 2013 @ 10:39:16 #73

Chandler

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 ]

Just say hi!

woensdag 3 juli 2013 @ 11:34:08 #74

Sitethief

Fulltime Flapdrol

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

woensdag 3 juli 2013 @ 11:37:31 #75

slacker_nl

Sicko pur sang

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

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

» digital corner

» development

» digital corner

» development