Ämne: Databasmodulering MySQL och tempgivare/pulsräknare/etc

[Alexander Pettersson]

Vilken struktur ska jag ha på min nya SQL-databas?

Idag skriver jag en post i databasen varje minut med värdet på givarna och vad klockan är.
(D.V.S så som man skriver i en fil.)

IOM att jag är rudis när det gäller databasmodulering så undrar jag om någon kan hjälpa mig med hur strukturen ska se ut.
Så att det blir flexibelt osv...

[utopiazz]

Vad använder du för program till att hämta datat?

Själv kör jag numera RRDTool och Cacti. Då sparas datat i RRD databaser och inte i SQL. Cacti är sedan ett skal (webbaserat) för att hantera RRDTool.
Nackdelen med RRD databaserna är att dom är just Round Robin Databaser. När databsen är full så skrivs det äldsta värdet över. Fast å andra sidan sätter man att RRDTool ska spara data i 5-10år så är man rätt säker på att inget data kommer att skrivas över.

http://vplogger.mine.nu

/Johan

[Alexander Pettersson]

För att hämta PHP.
För att fylla Delphi.

Men nu var det själva strukturen i databasen som var frågan.

[utopiazz]

Även jag är en amatör på databasmodellering men lite tankar och ideer kanske kan komma till användning.
Skulle jag bygga upp en databas idag för loggningen så skulle den se ut som följer.

Den skulle bla. ha separata tabeler för varje givare. Det ger snabbhet i sökningarna samt möjligheten att ändra/lägga till nya tabeller vid behov.
Nackdelen kan vara om man vill ha samtliga värden från samtliga givare vid en viss tidpunkt. Då måste det göras en SELECT sats för varje tabell. Ett alternativ kan då vara att spara samtliga värden två gånger, både i en separat tabell för varje givare men även i en tabell som innhåller alla värden. Beroende på vilket man vill veta så görs sökningen i olika tabeller.

Varje tabell skulle ha ett automatiskt räkneindex som eg motsvarar radnummer. Datum och givarvärde separeras i olika kolumner. Sen kan man använda sig av olika typer av indatamasker för att säkerställa att inga felaktiga värden sparas. Det är ju orimligt att spara +45gr som KB temp tex. Det värdet ligger ju utanför godtagbara värden och borde filtreras bort i en indatamask. Ersätts lämpligen med NV (NoValue) eller liknande

INDEX:Räknare:Obligatoriskt
DATETIME:Datumtid:Obligatoriskt
Räknarid:ASCII:Obligatoriskt
VALUE:Flyttal:Ej Obligatoriskt (Se ovan)

Vet inte om du blev klokare av detta

/Johan

[Alexander Pettersson]

Det finns i alla fall ritverktyg(freeware) http://gnuwin.epfl.ch/apps/DDT/en/ som kan exportera i SQL format.

Har ritat ett utkast... 

Om man har en tabell per givare så måste man ju ändra strukturen på DB:en (precis som du skriver) och det är ju det jag inte vill göra.
Då det påverkar inta bara databasen i sig utan även program för in/ut matning av data.

I utkastet så blir en ny givare bara yttligare en post/minut i tabellen 'givare'.

Antar att det finns en och annan som skrattat käken ur led redan....  JAG ÄR HELRUTTEN på detta.

Finns det någon som känner till något forum som skulle kunna hjälpa till?

[mape17]

Hej
Är även jag nybörjare på databashantering men en accesskurs finns i botten sedan en massa år.

Jag skulle lägga upp tabeller enl följande (ihuvudsak som standard för thermometer men jag har lagt till tabellen sensor för att hålla reda på sensornamnen. I tabellen data skulle jag lagra både temp och elförbrukning etc och sen bara söka ut de jag vill ha. Ev skulle jag lägga till sensortyp i tabellen sensor för att kunna söka efter de olika typena.

Nodes
node_id
node_name
node_description

Sensor
Sensor_nameid
Sensor_id_fk
Sensor_name

data
data_sensorid
data_nodeid
data_time
data_temp

alarm
Alarm_nodeid
alarm_sensorid
alarm_text
alarm_type
alarm_time

Jag skulle inte använda datum/tid som nyckel då detta är ett värde som ändras.
Jag använder alltid ett extra värde som blir ett rent löpnummer för att få det helt unikt för posten.

Har kört nån månad med Mysql och det tar inte mång hundradels sekunder för att söka ut det man vill ha ur databasen.

(ändrad till tabellstruktur enl mysql och inte som jag hade det i huvudet när jag var på jobbet)

/mats

[UMH]

Har kört nån månad med Mysql och det tar inte mång hundradels sekunder för att söka ut det man vill ha ur databasen.
/mats

Det var en rätt bra tabellstruktur men jag är ändå lite tveksam till prestandan. Säg att du har lagrat 10 temperaturgivare i ett år med en minuts intervall.

Det ger 5,2 miljoner rader i loggtabellen. Ska du ställa en fråga på det datat och få ut ett års statistik så är risken stor att det blir långa svarstider.  Ska man då också min, max och medelberäkna samtidigt så blir det riktigt tungt. Jag rekommenderar att man med tiden minskar upplösningen i datat genom att aggregera till andra tabeller. Tex. att varje vecka så aggregeras datat till en vecko tabell som sedan kan aggregeras till en månads tabell varje månad. Detta ökar prestandan avsevärt. Nackdelen är att du inte kan se minut intervall några månader tillbaka i tiden. Man vill man det?

Minutintervall borde vara mest intressant i närstående tid då man håller på med intrimmning. Tex inom en månad.
Andra förslag?

/Peter

[mape17]

Gjorde ett litet test och sökte ut alla mätvärden ca 45000st tog in de i excel,  sorterade dem och räknade ut medelvärdet på alla givarna, vad jag nu ska med det medelvärdet til ;-) , det tog ca 1 sek.
En uppdatering med att köra frågan igen och räkna ut nytt medelvärde går "blixtsnabbt"
Loggar själv var 5:e minut och 12 givare.

Helt klart kommer accesstiden att stiga om nåt tag.
Håller med att det kan vara lämpligt att agregera datat till fler tabeller så småningom.
Kanske spara 5:min värden för de senaste kvartalet, sen spara dygns/vecko/månadsvärden kanske till
och med årsvärden om loggen får gå länge.

Får se vad det blir för beräkningar på det lagrade datat, just nu lagrar jag bara allt rakt av.

Först ska jag få till elmätarna på FTX och värmepannan och logga det i datorn också, sen får vi se vad det blir för beräkningar/weblösingar.

/mats