DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
De laatse 60 gebruikers die online waren, gesorteerd op naam:
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).
| 1 2 3 4 5 6 | 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? |
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
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'.
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'.
In Java is het wel mogenlijk.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
Bedankt voor je query SR, maar helaas support de host van mijn klantje geen subqueries... waarom stappen ze nou niet gewoon allemaal gelijktijdig over!!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).
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...
Like trump...
ik snap het niet....
Je moet dus je users joinen op de online tabel, en alles wat daar niet in staat is dus offline?
Je moet dus je users joinen op de online tabel, en alles wat daar niet in staat is dus offline?
Klopt 100%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?
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
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.
Met een JOIN op IS NULL kan je de subquery omzeilen.
Zeg dat dan meteenquote: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!!
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? |
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
hoe goed geindexeerd is die 400mbquote: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.
Wat is de definitie van goed.quote:Op maandag 16 juni 2008 21:47 schreef morpheus_at_work het volgende:
[..]
hoe goed geindexeerd is die 400mb
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.
-edit-
Fixed.
[ Bericht 99% gewijzigd door slacker_nl op 17-06-2008 02:12:59 ]
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.
Hoe bedoel je met IS NULL? ik heb geen ervaring met lege JOINSquote: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.
Ja ik denk dat het laatste idd de oplossing is, ik ga er mee aan de slag!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.
tnx!
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
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.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
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
Volgens mij kan je die ORDER BY en LIMIT in de gewone query doen?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.
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
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.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.
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
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....
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....
Dit heeft helaas ook niet mogen baten. Ik houd het wel bij het oude script. Weinig spam tot nu toequote:
.
Dan weet ik het ook nietquote: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
It's Time To Shine
[i]What would life be like without rhethorical questions?[/i]
[i]What would life be like without rhethorical questions?[/i]
Dan zijn goede indices wel belangrijk. Zeker omdat je in een grote hoeveelheid data wilt zoeken.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.
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.
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
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?
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 |
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...
Like trump...
@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
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...
Like trump...
