Dakle recimo primjer, radim statistiku nekih evenata za koje mi je kasnije bitno znati od kada do kada su trajali.
Mislio sam upisivati EVENT1 timestamp početka i timestamp završetka.
I kasnije preračunati trajenje te vrijeme početka i kraja. (samo što će biti puno početaka i završetaka istog eventa)
Tako i za ostale EVENT2, EVENT3 itd.
E sada me mući kako najbolje projektirati tablicu koja polja zadati i kako upisivati da mi je kasnije lakše doći do podataka i voditi evidenciju?
Napravi tablicu s atributima id, event_name, start, stop, time.
id sam ubacio tek toliko da imaš neki primarni ključ koji u ovom slučaju što se tiče logike dizajna baze i neigra neku bitnu ulogu.
Pod ‘event_name’ upisuješ naziv eventa.
‘time’ pokazuje razliku između početnog i završnog vremena.
Ako se jedan event ponovi više puta samo ga upisuješ u bazu pod istim imenom unutar (event_name), a u ostala polja upisuješ potrbne podatke za taj event.
Na kraju, kada izvlačiš podatke iz baze za npr event1, napraviš upit koji kaže:
Izvuci sve podatke iz tablice u kojoj stupac event_name ima vrijednost event1
ili ako je lakše…
SELECT * FROM naziv_tablice WHERE event_name = ‘event1’;
Onda dalje manipuliraš s podacima po želji i potrebi.
Ako sam pogodio bit pitanja, onda bi to trebalo biti to.
Jako JAKO ovisi o tome za sta ti podaci tribaju (kako ce se agregirat kasnije), koliko podataka ima, koliko cesto se citaju, a koliko cesto upisivaju.
Ako imas nebitno mali promet, onda je i nebitno kako ces ih zapisat. @dpolo je dao jednostavan primjer.
Samo sto, ako je podataka jako puno, ne zelis imat visak u bazi (time) koji se moze racunat na osnovu postojecih podataka. Ako se cesto cita “time”, recimo prosjek, min, max, whatever, onda je mozda bolje imat drugu tablicu sa agregiranim rezultatima. Mozda je dobro razmislit i da event_name ide u zasebnu tablicu, i da je vezana foreign keyom na listu vremena. Time citanje imena eventova ne parsira super-giga-ogromnu tablicu koja sadrzi sva start-end vremena ikad, samo da bi se dobila lista naziva evenata. Ili promjena imena eventa ne radi update preko cijele giga tablice. Itd itd. Dakle, bitno je sta radis sa podacima. Samo rec “da mi ih je lakse procitat” ne znaci puno. Sve podatke koje pisemo u bazu zelimo procitat kad tad. Inace ih ne bi pisali u bazu.
Hmm… pokušat ću više objesniti…
Inače skripta se učitava sa cron jobom i skuplja podatke sa json datoteke svakih 5 min. moguće je dnevno oko 5-30 unosa. Rezultate će pregledavati 1-2 korisnika oko 10-20 puta na dan.
@dpolo sviđa mi se jednostavnost ideje,
Jasno mi je tako da kada event počne unesem timestamp i još jednom kada završi. (trenutno mi nije jasno kako unesti razliku u time polje, ali proućit ću.)
@leffe objasnio sam na višlje uvodu obujam potreba, ja mislim da je to podosta upisa u talicu… a ne bih htio preopteretiti bazu. također statistika neće biti opsežna poput prosjeka, min-max. samo datumi sa trajanjem pojedinog eventa. koji trebaju biti dostupni za svaki event da se vidi kao neki history kada su eventi trajali.
Ovo je mikro promet; okej je bilo kakvo rjesenje.
Ja bi napravio tablicu A s poljima:
i tablicu B s poljima:
Date i duration bi izracunao prije unosa.
jedan row u tablici za event i onda start i end timestampove odvojit sa zarezom i kasnije u php-u pomoću explode-a se koriste sva vremena
To je loše, šta ako bi htio dobiti evente od do vremena ? npr koji počinju između 1. i 30. lipnja. Bolje neka odvoji početni datum i završni datum, a neka unese i vrijeme trajanja. Rješenje od @leffe mi se čini najboljim…
Ima jedna formula koliko se sjecam od prije
dan + mjesec100 + godina10000 probaj u to pretvorit pa oduzet broj
Pogledaj funkciju
DATEDIFF(mjera, početak,kraj)
tipa
DATEDIFF(minute, datum, datum)
dvi kolumne i u njih nek odvaja zarezom, tako moze radit ovo sto si ti naveo kao primjer
