[PHP/(My)SQL] voor dummies - deel 60

Index

» digital corner

actieve topics nieuwe topics
abonnement Unibet Coolblue Bitvavo
pi_59435751
De laatse 60 gebruikers die online waren, gesorteerd op naam:
1
2
3
4
5
6		SELECT p.id, p.naam, p.leeftijd, o.id AS onlineID
FROM online o
LEFT JOIN profielen p ON p.naam = o.naam
WHERE p.naam IN (SELECT naam FROM online ORDER BY id DESC LIMIT 60)
ORDER BY p.naam
LIMIT 60        

Is de naam echt de key tussen online en profielen?

Het verschil in dagen tussen twee datums krijg je in één keer met DATEDIFF(dat1, dat2).
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
  maandag 16 juni 2008 @ 17:04:28 #102
181667 Strani
Beroemde influencer
pi_59436562
Kan je niet in plaats van in de query te vragen om online users, dat pas in de weergave doen?

Dus dat je een tijdsgrens stelt (bijvoorbeeld 1 dag) en dan per row 'vraagt' of de online timestamp groter is dan de door jou vastgestelde 'online-grens'. Als dat het geval is kan je dan 'online' weergeven, en anders 'offline'.
Op 02-02-2020 20:20:20 schreef Strani iets
2006 Time Person of the Year
pi_59438001
quote:
Op dinsdag 10 juni 2008 09:06 schreef ursel het volgende:
Ik heb er eerlijk gezegd ook nog niet eerder over gehoord. En jou PHP versie volgens mij ook niet
In Java is het wel mogenlijk.
Steam - SC2
pi_59438857
quote:
Op maandag 16 juni 2008 18:13 schreef super-muffin het volgende:

[..]

In Java is het wel mogenlijk.
Correct, maar Java is geen PHP
fokstok.nl
pi_59439133
quote:
Op maandag 16 juni 2008 16:34 schreef SuperRembo het volgende:
De laatse 60 gebruikers die online waren, gesorteerd op naam:
[ code verwijderd ]

Is de naam echt de key tussen online en profielen?

Het verschil in dagen tussen twee datums krijg je in één keer met DATEDIFF(dat1, dat2).
Bedankt voor je query SR, maar helaas support de host van mijn klantje geen subqueries... waarom stappen ze nou niet gewoon allemaal gelijktijdig over!!

en datediff wist ik wel maar ook weer niet tnx

En heeft iemand nog een antwoord op deze vraag?
[PHP/(My)SQL] voor dummies - deel 60
The people who lost my respect will never get a capital letter for their name again.
Like trump...
  maandag 16 juni 2008 @ 19:19:32 #106
107951 JortK
Immer kwaliteitsposts
pi_59439656
quote:
Op maandag 16 juni 2008 18:50 schreef Light het volgende:

[..]

Correct, maar Java is geen PHP
Daar valt geen speld tussen te krijgen nee
Overzicht van alle maandcijfers van het fokforum, voor de stats freaks!
Een goede Fok!search met de kracht van Google!
pi_59439770
ik snap het niet....
Je moet dus je users joinen op de online tabel, en alles wat daar niet in staat is dus offline?
pi_59441192
quote:
Op maandag 16 juni 2008 19:22 schreef Xcalibur het volgende:
ik snap het niet....
Je moet dus je users joinen op de online tabel, en alles wat daar niet in staat is dus offline?
Klopt 100%
The people who lost my respect will never get a capital letter for their name again.
Like trump...
pi_59442790
In dat geval denk ik niet dat het met een enkele query lukt, met twee moet geen probleem zijn....:)
Met een JOIN op IS NULL kan je de subquery omzeilen.
pi_59444148
quote:
Op maandag 16 juni 2008 19:00 schreef Chandler het volgende:
[..]
Bedankt voor je query SR, maar helaas support de host van mijn klantje geen subqueries... waarom stappen ze nou niet gewoon allemaal gelijktijdig over!!
Zeg dat dan meteen
Dan zou je eerst een temp tabel kunnen vullen met de laatste 60 online id's... maar dan is het eenvoudiger om eerst alle rows uit te lezen en ze dan in php te sorteren.
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
pi_59444329
quote:
Op maandag 16 juni 2008 11:18 schreef ursel het volgende:
Weet er iemand eigenlijk wat een beetje de limieten van MySQL zijn?
Voor aantal connecties heb ik ooit wel eens opgevangen dat MySQL beetje gaat hikken als die meer dan 100 connecties per seconde krijgt bijvoorbeeld.

Maar hoe zit het eigenlijk met de hoeveelheid data?
Weet dat we nu nog met 400 mb nog makkelijk niet aan de max zitten. Maar voor een project zijn we het een en ander aan het inventariseren om toch grotere hoeveelheden data op te gaan slaan.

Met het oog op de toekomst wel zo prettig om dan ook gelijk de database te evalueren.
hoe goed geindexeerd is die 400mb
  dinsdag 17 juni 2008 @ 00:12:34 #112
63192 ursel
"Het Is Hier Fantastisch!
pi_59449352
quote:
Op maandag 16 juni 2008 21:47 schreef morpheus_at_work het volgende:

[..]

hoe goed geindexeerd is die 400mb
Wat is de definitie van goed.
Kan beter, maar wel deels. Wat zal ik zeggen.

Er liggen op de belangrijkste en grootste tabellen wel indexen, maar is de engine momenteel nog myisam. Er liggen bijvoorbeeld geen foreign keys.
De engine zal in de nieuwe toevoer ook uitgezocht worden en denk momenteel innoDB hier voor te gebruiken.
Maar de nieuwe data opslag zal een ander process zijn dan de huidige. Eigenlijk willen we van een ander systeem maandelijks de data opslaan en deze doorzoekbaar maken voor slechts enkele gebruikers. De hoeveelheid queries zullen dus miniem zijn, de hoeveelheid te zoeken data groot.
  dinsdag 17 juni 2008 @ 01:49:23 #113
187069 slacker_nl
Sicko pur sang
pi_59450524
-edit-

Fixed.

[ Bericht 99% gewijzigd door slacker_nl op 17-06-2008 02:12:59 ]
In theory there is no difference between theory and practice. In practice there is.
pi_59452844
quote:
Op maandag 16 juni 2008 20:56 schreef Xcalibur het volgende:
In dat geval denk ik niet dat het met een enkele query lukt, met twee moet geen probleem zijn....:)
Met een JOIN op IS NULL kan je de subquery omzeilen.
Hoe bedoel je met IS NULL? ik heb geen ervaring met lege JOINS
quote:
Op maandag 16 juni 2008 21:41 schreef SuperRembo het volgende:
Zeg dat dan meteen
Dan zou je eerst een temp tabel kunnen vullen met de laatste 60 online id's... maar dan is het eenvoudiger om eerst alle rows uit te lezen en ze dan in php te sorteren.
Ja ik denk dat het laatste idd de oplossing is, ik ga er mee aan de slag! tnx!
The people who lost my respect will never get a capital letter for their name again.
Like trump...
pi_59453826
quote:
Op dinsdag 17 juni 2008 09:39 schreef Chandler het volgende:
[..]
Hoe bedoel je met IS NULL? ik heb geen ervaring met lege JOINS
Vaak kan je een WHERE IN (...) of WHERE NOT IN (...) sub query omzetten naar een JOIN. In dit geval lukt dat niet omdat in de sub query een ORDER BY en LIMIT zit.
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
pi_59453920
quote:
Op dinsdag 17 juni 2008 10:25 schreef SuperRembo het volgende:
Vaak kan je een WHERE IN (...) of WHERE NOT IN (...) sub query omzetten naar een JOIN. In dit geval lukt dat niet omdat in de sub query een ORDER BY en LIMIT zit.
Volgens mij kan je die ORDER BY en LIMIT in de gewone query doen?
Je krijgt sowieso alleen de resultaten van je JOIN, en die worden dan gesorteerd en gelimit.

Chandler: zie ook de uitleg hier: http://dev.mysql.com/doc/refman/4.1/en/join.html
4e bullet gaat over de IS NULL syntax
pi_59455078
quote:
Op dinsdag 17 juni 2008 10:29 schreef Xcalibur het volgende:

[..]

Volgens mij kan je die ORDER BY en LIMIT in de gewone query doen?
Je krijgt sowieso alleen de resultaten van je JOIN, en die worden dan gesorteerd en gelimit.
Het probleem is in dit geval dat je voor de LIMIT wil sorteren op online.id, maar voor de regels die daarmee gevonden worden wil je op profielen.naam gesorteerd hebben.
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
pi_59455273
Volgens mij is dat niet waar, aangezien uitsluitend de online users in de online tabel staan. Als je deze tabel joint krijg je dus alle online users. Als je deze met IS NULL joint krijg je alle offline users.

Er hoeft op die manier dus niet gelimit / gesorteerd te worden op de online tabel


Edit: je hebt dus wél twee queries nodig, 1 voor de online en 1 voor de offline users....
pi_59497259
quote:
Op zondag 15 juni 2008 01:19 schreef qu63 het volgende:
Dan moet die } op regel 19/20
Dit heeft helaas ook niet mogen baten. Ik houd het wel bij het oude script. Weinig spam tot nu toe .
  woensdag 18 juni 2008 @ 20:11:27 #120
62215 qu63
..de tijd drinkt..
pi_59497641
quote:
Op woensdag 18 juni 2008 19:58 schreef JJasperO het volgende:

[..]

Dit heeft helaas ook niet mogen baten. Ik houd het wel bij het oude script. Weinig spam tot nu toe .
Dan weet ik het ook niet
It's Time To Shine
[i]What would life be like without rhethorical questions?[/i]
pi_59501837
quote:
Op dinsdag 17 juni 2008 00:12 schreef ursel het volgende:

[..]

Wat is de definitie van goed.
Kan beter, maar wel deels. Wat zal ik zeggen.

Er liggen op de belangrijkste en grootste tabellen wel indexen, maar is de engine momenteel nog myisam. Er liggen bijvoorbeeld geen foreign keys.
De engine zal in de nieuwe toevoer ook uitgezocht worden en denk momenteel innoDB hier voor te gebruiken.
Maar de nieuwe data opslag zal een ander process zijn dan de huidige. Eigenlijk willen we van een ander systeem maandelijks de data opslaan en deze doorzoekbaar maken voor slechts enkele gebruikers. De hoeveelheid queries zullen dus miniem zijn, de hoeveelheid te zoeken data groot.
Dan zijn goede indices wel belangrijk. Zeker omdat je in een grote hoeveelheid data wilt zoeken.

Als je 1.000.000 unieke getallen hebt en je zoekt daar een specifiek getal zonder dat je weet hoe de rij gesorteerd is, dan heb je gemiddeld 500.000 pogingen nodig (gewoon vooraan beginnen, en steeds de volgende pakken tot je de goede hebt gevonden). Als je weet dat de rij oplopend gesorteerd is, heb je maximaal 20 pogingen nodig (aangenomen dat je nauwkeurig het midden kunt bepalen). Als je zoekt op een getal dat niet in de lijst staat, heb je in het eerste geval altijd 1.000.000 zoekpogingen nodig, in het tweede geval nog steeds niet meer dan 20.

Indices in MySQL werken vast iets anders, maar een goede index heeft een zeer groot effect op de snelheid. En hoe groter je dataset, hoe groter het voordeel.
fokstok.nl
pi_59547099
Een leuke ;)

Voor een bepaald script dat ik include moet ik weten waar het script staat (directory).

voorbeeld:

include("./templates/test/test.php");

nu moet het script (test.php) weten dat het pad ./templates/test/ is om daar zijn bestanden te kunnen benaderen.

Nu doe ik het zo

1$_SERVER['DOCUMENT_ROOT'] . pathinfo($_SERVER['SCRIPT_NAME'], PATHINFO_DIRNAME) . "/pixel.gif"


maar dat vind ik niet echt lekker werken en aangezien ik op een online webserver geen DOCUMENT_ROOT (denk ik) kan gebruiken ben ik opzoek naar een andere oplossing.

Iemand die mij kan helpen?
The people who lost my respect will never get a capital letter for their name again.
Like trump...
pi_59547233
1
2
3		<?php
include(dirname(__FILE__).'/templates/test/test.php');
?>
fokstok.nl
pi_59547522
@Light; het idee is goed, maar wil dat het script test weet waar het staat.

Gaat niet om het include script maar om het script dat geincluded wordt
The people who lost my respect will never get a capital letter for their name again.
Like trump...
pi_59547570
quote:
Op vrijdag 20 juni 2008 12:28 schreef Light het volgende:

[ code verwijderd ]
Zonder de /templates dir neem ik aan.
actieve topics nieuwe topics
abonnement Unibet Coolblue Bitvavo
[PHP/(My)SQL] voor dummies - deel 60
Index

» digital corner

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