[php] dagen uit draaien van een tabel

[Verwijderd]

Hallo,

ik kom er maar weer eens niet wijs uit. ik heb een tabel met de volgende gegevens:

200901261000
200901261010
200901261020
200901261030
200901261040
200901261050
200901261100
200901261110
200901261120
200901261130
200901261140
200901261150
200901261200
200901261210

---

200901270220
200901270240
200901270250
200901270300
200901270310
200901270320
200901270330

enz


Zoals jullie zien is die opgebouwd uit jaar maand dag uur min.

nu wil ik een query maken dat ik alleen bijvoorbeeld alleen de dagen pak zonder dat de uren en minuten krijg uitgedraaid.:

20090126
20090127
20090128
20090129
20090130

kan dit strln() te gebruiken?

[Swaptor]

Absoluut!
Heb je de PHP-docs al gelezen?

[Verwijderd]

ja ken de functie wel, maar dan moet ik dan gewoon de uitdraai van alle tijden laten staan?

[soap]

substr() kan ook.

[Tiemez]

Als het om MySQL gaat, zou ik het eerst omzetten naar een DATE-type (met str_to_date) en dan met DATE_FORMAT() in het juiste formaat weergeven.

[Luqq]

Ik zou zeggen, probeer gewoon wat. Het feit dat je de correcte functies al weet, en toch hier post, vind ik een beetje apart. Trial and error, my friend, trial and error.

[Down]

Dat soort oplossingen zijn imho vrij ranzig en totaal niet onderhoudbaar.

Welke DMBS gebruik je? Ik neem aan MySQL aangezien je PHP gebruikt. MySQL heeft gewoon functies voor het selecteren van date/time gerelateerde zaken. Als het overigens je eigen DB is zou ik je aanraden om data en tijd op te slaan als date(time).

[swtimmer]

en met distinct zorg je dat de dubbele resultaten weg zijn :-)

[TheRookie]

Wat heb je zelf al geprobeerd, en waar loop je op vast ?
Staat die informatie in een tekst-veld of in een datetime veld ?
Je zou het groeperen op dag, afhankelijk van de overige randvoorwaarden, namelijk al door de database kunnen laten afhandelen ipv door php

[ Voor 21% gewijzigd door TheRookie op 11-02-2009 16:44 . Reden: moet sneller tikken! ]

[kalechinees]

das geen query maar een php functie eventueel kun je voor performancewinst de info direct vanuit de query strippen met de sql-functie substring

[Verwijderd]

ik gebruik idd mysql, mijn basiskennis is alleen in de database dumpen en beetje gegevens ophalen. ik heb geprobeert door middel van het opvragen van de gegevens where tijd='200901' enz, maar ja daar geef hij geen output en krijg ik bij tijd ='200901%%' (wildcards) ook niks eruit. was aan het rondneuzen bij phpfreakz in de artikelen maar das ook basis. ik krijg de gegevens van een xml pagina en zet ik de datum bv 25-01-2009 om naar 20090125 zodat ik een mooi nummeriek overzich krijg. eigenlijk voor dat gedeelte een uniek veld.

[trinite_t]

SQL:

WHERE tijd LIKE '200901%'

[Woy]

Verwijderd schreef op woensdag 11 februari 2009 @ 16:49:
ik gebruik idd mysql, mijn basiskennis is alleen in de database dumpen en beetje gegevens ophalen. ik heb geprobeert door middel van het opvragen van de gegevens where tijd='200901' enz, maar ja daar geef hij geen output en krijg ik bij tijd ='200901%%' (wildcards) ook niks eruit. was aan het rondneuzen bij phpfreakz in de artikelen maar das ook basis. ik krijg de gegevens van een xml pagina en zet ik de datum bv 25-01-2009 om naar 20090125 zodat ik een mooi nummeriek overzich krijg. eigenlijk voor dat gedeelte een uniek veld.

Ik zou de raad hierboven opvolgen om gewoon als datetime op te slaan.

Overigens klopt je wildcard klopt niet helemaal.

% staat voor 0 of meer caracters, het is dus nogal onzinnig om 2 maal % neer te zetten. Als je exact 1 characters wilt matchen moet je _ gebruiken ( In andere dbms'en ten minsten, MySql weet ik niet ). Verder werkt dat alleen als je LIKE gebruikt

dus dan krijg je iets van WHERE tijd LIKE '200901__' ( En dan dus meer dan 2 maal _ ), of gewoon een maal %

[ Voor 6% gewijzigd door Woy op 11-02-2009 16:57 ]

[Verwijderd]

@trinite_T> die functie was ik ook aan het zoeken.. maar dat werkt neit. ik krijg wel alles van januari. maar dus alleen de dagen met tijden.. ik ga testen met substr

[Verwijderd]

@woy> het like gedeelte gaat niet lukken,dit omdat ik dan alsnog de tijden erbij krijg.

[Woy]

Verwijderd schreef op woensdag 11 februari 2009 @ 16:56:
@trinite_T> die functie was ik ook aan het zoeken.. maar dat werkt neit. ik krijg wel alles van januari. maar dus alleen de dagen met tijden.. ik ga testen met substr

De where bepaalt ook niet de waarde die je selecteerd, maar filtert alleen de rows die je wilt selecteren.

dus je moet iets als het volgende doen ( Weet even de juiste parameters voor substr niet maar voor het idee )

SQL:

SELECT substr( tijd, 0, 6 )
FROM tabel
WHERE tijd LIKE '200901%'

Maar verder ben je dus eigenlijk verkeerd bezig omdat je datum/tijd informatie in een character field zit. Verder is het beter om de formatering van je data gewoon in je presentatie laag te doen.

[ Voor 14% gewijzigd door Woy op 11-02-2009 16:59 ]

[trinite_t]

Verwijderd schreef op woensdag 11 februari 2009 @ 16:56:
@trinite_T> die functie was ik ook aan het zoeken.. maar dat werkt neit. ik krijg wel alles van januari. maar dus alleen de dagen met tijden.. ik ga testen met substr

Voorkauwen is toch niet nodig:

SQL:

SELECT SUBSTR(tijd, 0, 6) FROM tabel WHERE tijd LIKE '200901%'

SUBSTR is uit m'n hoofd. kan iets andere syntax hebben. maar dacht dat het zo klopt

edit:
spuit11

[Verwijderd]

neej hoef ook niet dat het me voorgekauwd wordt, ik hoef infeite aanwijzingen. niet dat ik met iets bezig ben waar ik uren in zit (Want heb al niet echt een programmeer knobbel, al had ik die graag gehad:P) en ik moet in een andere richting zoeken. ik vind het al fijn dat jullie al reageren

[Woy]

Ik zou dan vooral eens goed opzoeken wat de verschillende delen van een Query doen.

Je hebt een aantal delen ( SELECT, FROM, JOIN, WHERE, GROUP BY, ORDER BY, etc.. ) en die hebben allemaal een andere functie.

Als je dat snapt, had je ook meteen begrepen dat iets in de WHERE clause geen invloed heeft op de representatie van de gegevens die uit een query komen.

[Verwijderd]

ja ik heb het ook gewoon bij een andere select query

code:

$query = mysql_query("SELECT tijd FROM gegevens");  
while ($r = mysql_fetch_object($query)){

$alledata = $r->tijd; 
$sub = substr("$alledata",0,8);




echo"$sub<Br>";

ik krijg nu wel bijna wat ik wil. maar kijg nu


20090128
20090128
20090128
20090129
20090129
20090129
20090130
20090130
20090130

dus ik heb wel bijna de dagen, maar alleen nog te veel van de zelfde dagen. dat komt omdat hij vast en zeker nog de tijden laat zien, maar dan afgekapt. ik ga verder ploetere

[Verwijderd]

swtimmer schreef op woensdag 11 februari 2009 @ 16:42:
en met distinct zorg je dat de dubbele resultaten weg zijn :-)

hier heb ik overheen gekeken.. ff kijken

edit: php kent de functie niet..? zelfs op php.net niet gevonden

[ Voor 13% gewijzigd door Verwijderd op 11-02-2009 17:29 ]

[roy-t]

Verwijderd schreef op woensdag 11 februari 2009 @ 17:26:
[...]

hier heb ik overheen gekeken.. ff kijken

edit: php kent de functie niet..? zelfs op php.net niet gevonden

Dat is geen php code maar mySQL code, je moet in je select aangeven dat alle waarden distinct moeten zijn, maar dat gaat alleen werken als je dus al in je MySQL code ervoor zorgt dat je de juiste waarden selecteerd (dus de query met een substring of dergelijke functie).

voor meer distinct info zie: http://newsourcemedia.com/home.php?view=115 .

Maar als je het op deze manier op haalt zul je zelf moeten filteren. (als de data op volgorde gesorteerd is kan dat bijvoorbeeld door een $previous var te hebben en telkens te kijken of de volgende die je output niet gelijk is aan de vorige )

[TeeDee]

Waarom wordt, zoals Imodium aangeeft, niet gebruik gemaakt van str_to_date om vervolgens in je where clause een goed predicate aan te leggen?

Gooi daar nog een distinct, of beter nog een group by overheen en je bent klaar.

De LIKE '200901%' oplossing is helemaal van de zotte. Het zijn datums, (al dan niet in een verkeerd datatype) behandel ze dan ook zo.

[ Voor 28% gewijzigd door TeeDee op 11-02-2009 17:45 ]

[CH4OS]

Verwijderd schreef op woensdag 11 februari 2009 @ 17:26:
[...]

hier heb ik overheen gekeken.. ff kijken

edit: php kent de functie niet..? zelfs op php.net niet gevonden

DISTINCT hoort dan ook in MySQL thuis, oftewel, in je query:

SQL:

SELECT DISTINCT ...

Overigens is het zo, dat als iets (ook) in SQL kan, om het dan via SQL te doen, dat maakt de pagina sneller dan als je dat met PHP doet.

[ Voor 17% gewijzigd door CH4OS op 11-02-2009 17:43 ]

[Woy]

TeeDee schreef op woensdag 11 februari 2009 @ 17:35:
De LIKE '200901%' oplossing is helemaal van de zotte. Het zijn datums, (al dan niet in een verkeerd datatype) behandel ze dan ook zo.

Eens, maar waarom zeg je dan

Waarom wordt, zoals Imodium aangeeft, niet gebruik gemaakt van str_to_date om vervolgens in je where clause een goed predicate aan te leggen?

Het zijn datums waarom zou je ze dan opslaan als strings en ze dan in je query omzetten naar date's? Sla ze dan gewoon op als date's en converteer ze naar de juiste strings op het moment dat dat nodig is.

GJtje schreef op woensdag 11 februari 2009 @ 17:36:
Overigens is het zo, dat als iets (ook) in SQL kan, om het dan via SQL te doen, dat maakt de pagina sneller dan als je dat met PHP doet.

Dat is natuurlijk onzin. Het is niet zo dat als iets ook in SQL kan dat het dan sneller is dan als met PHP.

Sommige dingen zijn sneller in SQL ( of eigenlijk het DBMS ) en sommige zijn sneller in PHP. SQL is vaak snel met set-based operaties, maar als je complexe berekeningen met die data wilt doen kun je het vaak beter in PHP doen.

Het is niet zo dat het ene sneller is dan het andere, maar je moet gewoon per case kijken. En bovendien is performance natuurlijk ook niet altijd de beste drijfveer om een bepaalde keuze te maken. Als MySql heel erg snel HTML kon renderen zou ik het nog niet zo snel gaan gebruiken om mijn front-end te renderen.

[ Voor 41% gewijzigd door Woy op 11-02-2009 18:49 ]

[Raynman]

roy-t schreef op woensdag 11 februari 2009 @ 17:33:
[...]

Maar als je het op deze manier op haalt zul je zelf moeten filteren.

Het is even geleden dat ik wat met SQL gedaan heb, maar kan DISTINCT niet gewoon ook op die SUBSTR(...) werken?

Woy schreef op woensdag 11 februari 2009 @ 18:45:Het zijn datums waarom zou je ze dan opslaan als strings en ze dan in je query omzetten naar date's? Sla ze dan gewoon op als date's en converteer ze naar de juiste strings op het moment dat dat nodig is.

Dat laatste is natuurlijk waar, maar als je nu eenmaal met datums opgeslagen als strings zit, kun je die beter wel converteren naar dates wanneer je er bewerkingen of vergelijkingen mee wilt uitvoeren (en dus niet allemaal trucs met strings uithalen om hetzelfde resultaat te verkrijgen).

[TeeDee]

Woy schreef op woensdag 11 februari 2009 @ 18:45:
[...]

Het zijn datums waarom zou je ze dan opslaan als strings en ze dan in je query omzetten naar date's? Sla ze dan gewoon op als date's en converteer ze naar de juiste strings op het moment dat dat nodig is.

Als ik de TS goed begrijp, zijn het al strings en is het datamodel al fout. Ga dan alsnog niet met strings aan de slag maar converteer de hele handel in de query naar het correcte datatype. Werkt makkelijker en dan voorkom je afaik de table-scan door de like. Mijn 2e paragraaf staat er een beetje krom.

1. Bij de invoer/import of wat dan ook: sla het op als een datum
2. Is dit niet het geval of niet mogelijk, converteer @ runtime naar een datum en voorkom de imo ranzige LIKE.

Edit: hmm, je hebt gelijk dat door het gebruik van de convert in de where (en afaik alleen in de where) een full table scan triggert. Neemt uiteraard niet weg dat het datamodel aangepast dient te worden.

[ Voor 11% gewijzigd door TeeDee op 11-02-2009 21:06 ]

[Woy]

TeeDee schreef op woensdag 11 februari 2009 @ 19:07:
[...]

Als ik de TS goed begrijp, zijn het al strings en is het datamodel al fout. Ga dan alsnog niet met strings aan de slag maar converteer de hele handel in de query naar het correcte datatype. Werkt makkelijker en dan voorkom je afaik de table-scan door de like. Mijn 2e paragraaf staat er een beetje krom.

1. Bij de invoer/import of wat dan ook: sla het op als een datum
2. Is dit niet het geval of niet mogelijk, converteer @ runtime naar een datum en voorkom de imo ranzige LIKE.

Volgens mij ga je juist door het converteren een table scan introduceren. De LIKE is perfect op te lossen door gebruik te maken van een index op die column ( als die er is natuurlijk ), aangezien de wildcard aan het einde staat.

En als zijn datamodel al fout is, kan je natuurlijk altijd overwegen om het alsnog aan te passen. Dat zal inderdaad niet altijd mogelijk zijn, maar als het niet al te veel moeite kost zou ik het zeker doen.

[ Voor 11% gewijzigd door Woy op 11-02-2009 20:23 ]

[roy-t]

Raynman schreef op woensdag 11 februari 2009 @ 19:02:
[...]
Het is even geleden dat ik wat met SQL gedaan heb, maar kan DISTINCT niet gewoon ook op die SUBSTR(...) werken?

Ik vermoed dat substr een tijdelijke tabel aan maakt met die substrs en dat DISTINCT dan inderdaad goed zou werken, maar zeker weten doe ik het niet.