mysql unix timestamp

[ffgghh]

sveiki,

 

ir mysql datubaaze ar ailiiti laiks kuraa kraajas unix timestampi:

1123055364

1123055363

1123055362

1123055361

1123055360

 

Kaa ar mysql selectu var izselecteet tikai taas rindas kuraas laiks ir shodienas datumaa ???

 

resp ja vaka 23.59 - tad neskaitaas bet ja shodien 00.00 tad ok

 

>???

[bubu]

Šitais neder?

select * from tabule where timestapa_kolonna = NOW()

 

Edit: Ui sajaucu, vajag

WHERE date(timetampa_kolonna) = date(now())

:)

Edited August 16, 2005 by bubu

[Analgiins]

select *
from tabula
where DATE_FORMAT(FROM_UNIXTIME(timestapa_kolonna), '%Y-%m-%d') = DATE_FORMAT(NOW(), '%Y-%m-%d')

[v3rb0]

imo efectivak, bez liekam perveidosanaam, ir php pusee atrast shodienas datuma timestampus pulksten 00.00 un 23.59, lai datubazee atlasisanu pa timestampa kolonu varetu veiktu ar cipariskam vertibam no liidz.

[Analgiins]

to v3rb0:

nepiekriitu, ja ir iespeejams kaut ko izdariit jau vaicaajumaa, tad labaak taa dariit. Nevajag piesaarnjot PHP kodu, kursh jau taa parasti ir pied..sts :)

 

Edit: un nav ko baidiities no lieliem vaicaajumiem

Edited August 16, 2005 by Analgiins

[Roze]

to v3rb0:

nepiekriitu, ja ir iespeejams kaut ko izdariit jau vaicaajumaa, tad labaak taa dariit. Nevajag piesaarnjot PHP kodu, kursh jau taa parasti ir pied..sts :)

 

Edit: un nav ko baidiities no lieliem vaicaajumiem

21032[/snapback]

Nu tu vari nepiekrist.. Bet nu kaa jau v3rb0 rakstiija nav pareizi DB serverim taisiit visaadus SUBSTR, Uppercase lowercase u.c. datu transformaacijas (ko var izdariit jau pirms kverija sagatavoshanas), jo taa ir lieka noslodze un visi tabulas indexi kakjim zem astes (nedod dies ka veel jaataisa temporaaraas tabulas + filesorts + pilniiga datu paarlase visaa tabulaa).

 

Vizualais SQL kverija garums nav attiecinaams uz izpildes aatrumu un nepiecieshamajiem resursiem.

 

Protams ja nav redzeetas tabulas ar vairaak kaa 100 ierakstiem tad shaadus apgalvojumus var sviest pa labi un kreisi :)

 

EXPLAIN SELECT ...

[v3rb0]

Analgiins: kapec, ja datums tiek glabats kaa timesamps, njemt _katru_ ierakstu, to parveidot par datumu, _katru_ ierakstu taalak formeet par kaut kaada formata datumu, uz katru ierakstu panjemt tekoso datumu, to tad atkal formeet par kaut kaadu datumu, tad abus datums saliidzinaat lai noskaidrotu vai vajag shito datumu, ja var salidzinat ciparisku vertibu vai taa ir no A lidz B ?

 

un 3 rindas ne tuvu nav liels selects..

[des]

Nu tu vari nepiekrist.. Bet nu kaa jau v3rb0 rakstiija nav pareizi DB serverim taisiit visaadus SUBSTR, Uppercase lowercase u.c. datu transformaacijas (ko var izdariit jau pirms kverija sagatavoshanas), jo taa ir lieka noslodze un visi tabulas indexi kakjim zem astes (nedod dies ka veel jaataisa temporaaraas tabulas + filesorts + pilniiga datu paarlase visaa tabulaa).

 

Vizualais SQL kverija garums nav attiecinaams uz izpildes aatrumu un nepiecieshamajiem resursiem.

 

Protams ja nav redzeetas tabulas ar vairaak kaa 100 ierakstiem tad shaadus apgalvojumus var sviest pa labi un kreisi :)

 

EXPLAIN SELECT ...

21037[/snapback]

 

Atljaushos piebilst, ka eksistee gadiijumi, kad bez substr un citu funkciju izmantoshanas db pusee iztikt nevar (ja taadu gadiijumu nebuutu, tad attieciigaas dbps izstraadaataaji nebuutu puuleejushies taas funkcijas rakstiit). Bet taas gan paarsvaraa tiek izmantotas situaacijaas, kad tas querijs ir jaapilda ljoti reti, tipa reizi dienaa.

Bet ja tas ir querijs, kuram jaaizpildaas pie katra lapas pieprasiijuma, tad, protams, ka ir jaacenshas izvairiities no liekaam fjaam sql pusee. Arii no visaadiem SELECT COUNT..... , protams.

[Grey_Wolf]

nu nezinu es parasti datuma glabaashanai izmantoju MYSQL - DATATIME formaatu

IMPHO MYSQL ar sho formaatu straadaa daudz aatraak nekaa ar timestamp .....

-----

PHP pie ieraksta baazee parveidoju datumu vajadziigajaa formaa un tad tik uz priekshu....

arii datumu skjiroshana notiek daudz aatraak ja tiek izmantots MYSQL formaats...

- ne velti tiek izmantots tieshi sads formaats un ne savaadaaks (lai gan vairaak jau

prieksh taa lai vareetu pierakstiit VISUS datumus nevis no 1902 - 2036 :) )

 

arii atlasei velams veikt pieprasijumaa (ja vien tiek izmantots MYSQL formaats)

pashaa MYSQL - neba jau taapat vien taas f-jas ir rakstiitas :)

-------

teoreetiski ja izmanto MYSQL pieprasijumu teiksim atlasiit konkreeto datumu

vai saliidzinaat KATRU ierakstu vai tas atbilst konkreetam skaitlim (intervaalam) buus krietni aatraak :) -selektiivaa parlase izpildaas krietni leenaak

Iznjemums ja tie timestamp tiek regulaari indekseeti - tad gan izdeviigaak izmantot saliidzinaashanu :)

 

P.S. peec manaam domaam MYSQL f-jas straadaa krietni aatraak nekaa PHP f-jas

[bubu]

P.S. peec manaam domaam MYSQL f-jas straadaa krietni aatraak nekaa PHP f-jas

21041[/snapback]

Neizklausās bišķi stulbi.. salīdzināt divas dažādas lietas?

[Analgiins]

Vispaar jau jautaajums bija - Kaa ar mysql selectu var izselecteet tikai taas rindas kuraas laiks ir shodienas datumaa? Kaa tad var atrast visus ierakstus shodienaa peec sekundeem? Izmantot kaut kaadus intervaalus? Logjiski naak praataa to taimstampu paarveidot datuma formaataa/dienaa, resp., 2005-08-16 lai vareetu atrasts shodienas ierakstus. Vai tad tieshaam paarveidot taimstampu datumaa aiznjem milzoniigus resursus? Galu galaa, ko tad ir labaak noslogot - DB serveri vai webserveri? (Manupraat, te atkal iz seerijas stabs ar diviem galiem)

[bubu]

Pēc sekundēm vienkārši tak (man liekas v3rb0 jau teica): atrodi dienas 00:00:00 sekundi timestampa formātā=$a, atrodi dienas 23:59:59 sekundi timestampa formātā $b un tad kverijs ... WHERE t>=$a AND t<=$b

Webserveris te jau noslogojās minimāli - divas mazas operācijas, praktiski nekas.

Turpretī mysql ļoti maz, ja t lauks ir indeksēts - AND operācija māk izmantot indeksu.

Taču, ja meklēsi ar kautkādu funkciju pielietojumu t kolonnai WHERE daļā, tad gan indekss neizmantosies un tiks apskatīti visi tabulas ieraksti pēc kārtas - tas noteiki ir daaaudz vairāk, nekā tā minimālā webservera noslodze divu mainīgo izrēķināšanai.

[Roze]

Atljaushos piebilst, ka eksistee gadiijumi, kad bez substr un citu funkciju izmantoshanas db pusee iztikt nevar (ja taadu gadiijumu nebuutu, tad attieciigaas dbps izstraadaataaji nebuutu puuleejushies taas funkcijas rakstiit).

Tapēc arī minēju "ko var izdariit jau pirms kverija sagatavoshanas"

 

Un pamatoties tikai uz uz to ko izstradaataajs ir tādu funkciju iekļāvis manuprāt nav īsti korekti, jo tāda teiksim var nebūt pat SQL92 standartā :) MySQlam piemēram ir ļoti daudz eksotiskas funkcijas :)

 

 

glabaashanai izmantoju MYSQL - DATATIME formaatu

IMPHO MYSQL ar sho formaatu straadaa daudz aatraak nekaa ar timestamp .....

Atkarībā kā to izmanto timestamps pēc idejas aizņem mazāk vietas un ja datu apmaiņa notiek šādā datu tipā tad varētu būt aplams apgalvojums..

Datetime pretēji ir human readable ļoti ērti attēlot kā arī lai teiksim atrastu konkrētu gadu var izmantot stringa īpašißas aļa LIKE '2005-%'..

 

P.S. peec manaam domaam MYSQL f-jas straadaa krietni aatraak nekaa PHP f-jas

Pēc kā šis tiek secināts?

 

 

Vai tad tieshaam paarveidot taimstampu datumaa aiznjem milzoniigus resursus?

Nu nedaudz padomājam.. MySQLam ir tabula ar kaudzi ierakstiem kur lauks ir timestampā. MySQLam jāiet cauri katram ierakstam, tas jāpārveido par yyyy-mm-dd stringu (afaik date_format castoja selecteejamo lauku tieshi taa) un jaasaliidzina ar veel vienu stringu. Ja dati daudz teiksim normaala tabula > 100Mb MySQLam nākas wraitot temporāru tabulu uz diska un tas jau ir aaaafigenna lēnu..

 

Preteeji tam ka mees vareetu uztaisiit timetsampu kas buutu itkaa 2005-08-18 00:00:00 un otru 2005-08-18 23:59:59 un atselecteet vienkaarshi WHERE time => '$musutimestamps1' AND time <= '$musutimestamps2'

 

Kur $musutimestampus varam iegūt ar jauku php funkciju mktime() http://lv.php.net/mktime

 

$musutimestamps1 = mktime(0,0,0,date('m'),date('d'),date('y));

$musutimestamps2 = mktime(23,59,59,date('m'),date('d'),date('y));

 

Bet pie konkrētā gadījuma varbūt ir vērts padomāt par diviem atseviškiem DATE un TIME laukiem.. Datu apjoms palielināsīes bet noindeksējot DATE lauku un atselectējot WHERE datelauks = '2005-08-18' strādās rūkdams.. (vai datelauks = NOW())

 

Galu galaa, ko tad ir labaak noslogot - DB serveri vai webserveri?

Labāk ir lieki nenoslogot ne pirmo ne otro :) Taču manuprāt ir pieņemts saudzēt DB.

[PheliX]

kopsavilkumaa sanaak:

 

SELECT * FROM tabula WHERE taimstamps > UNIX_TIMESTAMP(CURDATE()) && taimstamps < UNIX_TIMESTAMP(CURDATE()) + 86400;

[Klez]

kopsavilkumaa sanaak:

 

SELECT * FROM tabula WHERE taimstamps > UNIX_TIMESTAMP(CURDATE()) && taimstamps < UNIX_TIMESTAMP(CURDATE()) + 86400;

21052[/snapback]

 

un kas notiek ja palaizh EXPLAIN SELECT ...