Du må være registrert og logget inn for å kunne legge ut innlegg på freak.no
X
LOGG INN
... eller du kan registrere deg nå
Dette nettstedet er avhengig av annonseinntekter for å holde driften og videre utvikling igang. Vi liker ikke reklame heller, men alternativene er ikke mange. Vær snill å vurder å slå av annonseblokkering, eller å abonnere på en reklamefri utgave av nettstedet.
  12 2204
Hei,
holder på med å lære meg php/mysql for tiden og det er top. Denne gangen er det ikke et problem jeg har kommet over, men heller et spørsmål dere her inne sikkert er kvalifisert til å besvare.
La oss si at jeg har en verdi, feks en valutta. og denne oppdaterer jeg en gang om dagen eller oftere, real-time kanskje? men jeg ønsker å ta vare på de eldre verdiene hver gang jeg oppdaterer, slik at jeg kan bruke det til å lage et historisk tilbakeblikk, bruke det til å regne ut gjennomsnitter over x dager/år etc? Hvordan løser man det mest effektivt? Jeg kommer til å lagre MYE slike verdier i lang tid, så må være det som er "best-practis" og ikke bare en home made hack for å få det til å rulle såvidt.

Håper jeg har gjort meg nogen lunde forstått. Hva kaller man det jeg prøver å få til? Er litt vanskelig å google når jeg ikke vet hva jeg skal søke på. Takker
Det er snakk om noe så enkelt som "timestamp", verdi (float) og noe som sier hvilken valutta det er. Burde virkelig ikke ta mye plass. Så som oftest vil det gå helt fint å bare putte det i en SQL-database. Hiv på en indeks på timestampen siden spørringene du gjør trolig vil gå ut på å hente ting i enkelte tidsintervaller, gruppere på tid og slikt.
Sist endret av etse; 15. oktober 2014 kl. 11:50.
som etse sier er indekser på timestamp det viktigste. Uten indeks er et between søk på timestampen O(n^2). Siden finansielle data i hovedsak vil ha økende datoer, oppnår du best case ved inserts også, så indeksen vil sannsynligvis ha minimal innvirkning på writes.

For å redusere datamengden kan du f.eks se på horizontal partitioning, men det går fint an å gjøre i ettertid. Relevant tråd http://dba.stackexchange.com/questio...s-sql-or-nosql
NOOOOOOOOOOOOOOOOOO-
robhol's Avatar
Jeg skjønner ikke hvor du får O(n²) fra? Burde det ikke da være O(n) vs noe nærmere O(log n)?
Sist endret av robhol; 15. oktober 2014 kl. 18:07.
Jo, sorry. Vet ikke hvorfor jeg tenkte O(n^2). Er vel kanskje det hvis man har et join predicate med between.
Altså har hver verdi sin egen table, hvor jeg kun legger til en ny entry i tablet hver gang jeg oppdaterer? Da vil jeg få svært mange tables... Eller har jeg misforstått det dere mener? thanks. jeg kan som sagt ikke så veldig mye. men prøver å lære
1 table. Hiv bare alt inn. Sett opp index på timetimestampen.
altså, at hver "ting" har sin egen tabel, og at hver row er en oppdatering av verdien? Jeg skjønner ikke hvordan jeg bare skal få slengt dette inn? Kan du gi et eksempel på hvordan du ville laget tabelen? La oss si at jeg har kordinater til noe, lat og lng, som oppdaterer seg hvert minutt. Sorry for at jeg er litt treg...

Jeg har en tabel med mange kjøretøy, jeg har masse informasjon om disse kjøretøyene, feks reg nr og mye annen info. Men jeg skal ha oppdaterte kordinatere for kjøretøyet hele veien, og hver row i tabellen er et kjøretøy. Så hvordan burde jeg kunne lagre historisk alle kordinatene kjøretøyet har hatt?

Jeg har en tabel med mange kjøretøy, jeg har masse informasjon om disse kjøretøyene, feks reg nr og mye annen info. Men jeg skal ha oppdaterte kordinatere for kjøretøyet hele veien, og hver row i tabellen er et kjøretøy. Så hvordan burde jeg kunne lagre historisk alle kordinatene kjøretøyet har hatt?
Sist endret av SecondLife; 15. oktober 2014 kl. 21:40. Grunn: Automatisk sammenslåing med etterfølgende innlegg.
Du lager første en tabell for kjøretøy hvor du har kolonner for id, regnr, og all annen mulig info

Så lager du en tabell for lokasjonsdata med kolonnene id, timestamp, lat, long og kjøretøy_id

Om dette virker veldig uklart anbefaler jeg å lese en bok om databaser, for dette er VELDIG basic.
Du kunne lese deg opp på funksjoner ,prosedyrer og triggere i MySQL. Lag en forretningslogikk som for hver gang det skal registreres nye koordinater, lagres de eksisterende koordinatene med f.eks timestamp i en annen tablell som holder på historiske data. Du kan f.eks sette triggeren til å trigge på "BEFORE UPDATE" i modertabellen.
<?php echo 'VIF'; ?>
datagutten's Avatar
Ved håndtering av tidspunkter er det lurt å bruke unix timestamp fremfor tidspunkt og datoer som er leselig for mennesker.
Da har du en numerisk verdi og kan enkelt se på verdier med større eller mindre enn uten å tenke på dager og måneder.
Sist endret av datagutten; 15. oktober 2014 kl. 21:54. Grunn: Automatisk sammenslåing med etterfølgende innlegg.
Sikkerhetsklarert
Sitat av Jurgen1337 Vis innlegg
Du kunne lese deg opp på funksjoner ,prosedyrer og triggere i MySQL. Lag en forretningslogikk som for hver gang det skal registreres nye koordinater, lagres de eksisterende koordinatene med f.eks timestamp i en annen tablell som holder på historiske data. Du kan f.eks sette triggeren til å trigge på "BEFORE UPDATE" i modertabellen.
Vis hele sitatet...
Hørtes avansert ut for noe så enkelt som dette.

Jeg anbefaler heller at han leser litt om normalisering.
Dvs lagre ting i egne tabeller, og heller lenke disse sammen.

f.eks table_kjøretøy:
id, regnr, merke, modell, eier, etc1,etc2

table_position
id,timestamp,lng,lat,kjoretøy_id

Så lagre ny posisjon for hver gang han oppdaterer denne. Trenger strengt tatt ikke skille ut dette i egen tabell heller. Evt bare flushe gamle data etter x antall dager.
Sitat av moridin Vis innlegg
Du lager første en tabell for kjøretøy hvor du har kolonner for id, regnr, og all annen mulig info

Så lager du en tabell for lokasjonsdata med kolonnene id, timestamp, lat, long og kjøretøy_id

Om dette virker veldig uklart anbefaler jeg å lese en bok om databaser, for dette er VELDIG basic.
Vis hele sitatet...
Nei, altså jeg er ikke så treg. Jeg når du forklarer det som du gjør her forstår jeg hva du mener helt fint takk