Databasdesign

[Johannabacken]

Hej,

Skrotar mitt msure system och går till ett raspberry baserat OWFS system.
I samband med det skapar jag en ny mysql-databas men jag kan inte tillräckligt för att veta vilken design som är att föredra.

Vad har ni databaskunniga för tankar om följande två olika upplägg:

A. Många tabeller
Msure's sätt att ha en tabell (som är sensornamnet) per sensor med kolumner [Value] [TimeStamp]

ELLER

B. Två Tabeller
HA's(?) sätt med en sensortabell med [ID] [Namn]
och
EN tabell med all data, exempel [ID][Value][TimeStamp]

Konsekvenser i hanterbarhet, kompliceade söksträngar och performance?

Har 20-tal sensorer, behöver inte ta med de 8 åren av gammal data, har färdig visulaisering för msure's tabellstruktur.

Tacksam för alla synpunkter!
/Johan

[MotoX]

Nu är jag inte särskilt inläst på andra databaser än MySQL men att ha en tabell för varje instans (sensor) lät ju väldigt fel... Det lät liksom inte särskilt systematiskt.
För mig är en databas en styrka i att inte behöva upprepa sig mer än nödvändigt genom att låta varje tabell hålla flera rader med i sig likadana instanser. T ex en tabell för brytare, en för relän, en för dimmrar osv. där man kan lägga upp kopplingstabeller mellan dessa tabeller för att säga hur datan, eller instanserna, i systemet hänger ihop.
Säger inte så mycket om hur du praktiskt ska göra i just din applikation, men mina enkla tankar kring vad som är en bra databas och inte. Lycka till!

[kaaswe]

Båda sätten kan vara rätt. A om det inte blir för många, men B är nog det vanligaste och även Domoticz kör med ID och lagrar sen alla enheter i samma tabell.

Skulle jag byggt det skulle jag kört på B, enklare och snyggare.

[zyber]

Jag tycker att förslag A låter mindre genomtänkt. Det kräver ju att du ändrar databaslayouten var gång du lägger till eller tar bort en sensor. Extremt osmidigt.

Sen beror det ju också också på vad för data du vill åt. Behöver du verkligen åtta års minutsprecision? Isåfall, kör på det här!

Annars, kanske du vill titta på RRD?

[Malmgren]

Håller med ovanstående talare. Kör själv openHAB och databasstrukturen för persistence där bygger på en ny tabell för varje enhet. Jobbar mycket med SQL till vardags och det känns helt bakvänt med alla dessa tabeller som skapas. Nej, en tabell med enheter (som man sedan kan utöka med kolumner som man vill ha mer info om enheterna) och en tabell med mätvärden som refererar till enhetens ID, precis som du beskriver i ditt B-exempel, känns som det vettiga sättet.

/Daniel

[dargosch]

Håller med ovanstående talare. Kör själv openHAB och databasstrukturen för persistence där bygger på en ny tabell för varje enhet. Jobbar mycket med SQL till vardags och det känns helt bakvänt med alla dessa tabeller som skapas. Nej, en tabell med enheter (som man sedan kan utöka med kolumner som man vill ha mer info om enheterna) och en tabell med mätvärden som refererar till enhetens ID, precis som du beskriver i ditt B-exempel, känns som det vettiga sättet.

Jo, det är det vanliga sättet. Men, det finns ju poänger med strukturen en tabell per sensor också. Du lär ju ha ett större (och mindre effektiv) index på en tabell som har alla värden i sig, och du slipper hantera externa referenser (att alla värden som hör till en sensor kanske ska tas bort då om en sensors rad i en annan tabell tas bort).

Kanske är det ett problem att schemat ändras när du lägger till en sensor, men de många databashanterare (alla?) har väl en meta-tabell (tabell som håller reda på alla tabeller) som man kan gå igenom för att hålla koll på sina sensorer.

Jag har inte undersökt sakerna själv, men det slår mig att om databaser för tidsserier generellt verkar lägga data i separata tabeller på något sätt (det är väl typ så man använder RRD, och jag tror också influxDB har den strukturen (men nu är jag verkligen i tro-lådan och rotar)) så tänker jag att det kan vara bra att i alla fall fundera på om det finns vinster man missat. Speciellt om du vill hantera minut-data för 8 år..

[Malmgren]

Speciellt om du vill hantera minut-data för 8 år..

Hmmm, ja det är klart. Måste erkänna att jag mest resonerat ur hanteringssynpunkt, att det är mycket smidigare med allt i en tabell. Men du har verkligen en poäng där att börjar man komma upp i några miljoner rader så är det nog en poäng i att dela upp det i en databas per enhet. Kanske ska vara tacksam att de som har byggt databasstrukturen i openHAB har tänkt till

/Daniel