Databasekeuze sensordata

[jeroenk13]

Ik ben een klein projectje begonnen waarbij ik iedere 15 seconde 2 temperatuur sensoren uitlees dmv. een Arduino.

Ik ben nu op het punt aangekomen om de data op te gaan slaan in een database zodat er een frontend gemaakt kan worden.

Welke database zou het beste bij dit type data passen?

Gewoon MySQL of is wellicht MongoDB beter? De database zal lopen op een Synology NAS.

Ik denk eraan om 2 tables te maken, 1tje voor sensor 1 en 1tje voor sensor 2.
Per table heb je alleen het tijdstip en de temperatuur waarde.

Per dag worden er ~11500 entries aan de database toegevoegd. (Iedere 15s 2sensoren => 8per min => 480 per uur => 11520 per dag)


Uiteindelijk word de data uitgelezen en een grafiek gemaakt dmv van Highcharts oid.

[ Voor 9% gewijzigd door jeroenk13 op 25-07-2017 22:59 ]

[justahuman]

Als je puur sensor data wilt opslaan zou ik kijken naar iets als https://prometheus.io of https://graphiteapp.org deze tools zijn er voor gemaakt om sensor data over tijd op te slaan en hier grafieken van maken.

[Anoniem: 943161]

Als je je afvraagt 'MySQL' of 'Mongo' dan is de keuze dus relationeel of niet. "Mongo is big data".

De gegevensset waar je het over hebt, is zo relationeel als de pest. Je weet exact welke gegevens het om gaat, dat verandert ook niet, en de verhoudingen tussen de gegevens onderling liggen ook vast.

Dus is een relationele database de beste keuze.

Welke dan? Dat is een lastige volgende vraag. Ik denk eigenlijk dat het geen moer uitmaakt, en ik zou gewoon de database pakken die jij het best kent cq. prettigst vind werken, of welke het best samengaat met het ecosysteem waarop je het wil laten draaien (je NAS).

Dat zal dus ws. MySQL zijn. Ik zie geen performance-issues in je vraagstelling, dus sure er zullen beter performende oplossingen zijn (je zou bv. Redis kunnen overwegen), maar voor 2 waarden elke 15s lijkt mij dat zware overkill. Kun je je tijd beter elders besteden.

[ Voor 15% gewijzigd door Anoniem: 943161 op 25-07-2017 23:08 ]

[farlane]

jeroenk13 schreef op dinsdag 25 juli 2017 @ 22:56:
Ik denk eraan om 2 tables te maken, 1tje voor sensor 1 en 1tje voor sensor 2.
Per table heb je alleen het tijdstip en de temperatuur waarde.

[SlaadjeBla]

Je zou moeten kijken naar een database die timeseries van nature goed ondersteunt, zoals InfluxDB of prometheus. Jouw probleem is allang opgelost en je maakt het jezelf makkelijk als je de juiste tools selecteert.

[Compizfox]

jeroenk13 schreef op dinsdag 25 juli 2017 @ 22:56:
Gewoon MySQL of is wellicht MongoDB beter?

Geen van beide. Neem een DBMS die bedoeld is voor time series data, zoals InfluxDB of Graphite.

[Anoniem: 943161]

Hoewel jullie gelijk hebben, is het in dit voorbeeld overkill. En moet het ook draaien op die synology.

Keep it simple werkt in dit soort projecten beter.

Wat ik inderdaad gemist had, is het verhaaltje over 2 tabellen. Natuurlijk maak je geen twee dezelfde tabellen voor 2 sensoren. Je maakt dan één tabel met sensoren en één tabel met sensordata.

[SlaadjeBla]

Anoniem: 943161 schreef op dinsdag 25 juli 2017 @ 23:24:
En moet het ook draaien op die synology.

Persoonlijk zou ik die eis loslaten en het opslaan op een Raspberry pi in InfluxDB. Maakt je wat flexibeler.

[Anoniem: 943161]

SlaadjeBla schreef op dinsdag 25 juli 2017 @ 23:27:
Persoonlijk zou ik die eis loslaten en het opslaan op een Raspberry pi in InfluxDB. Maakt je wat flexibeler.

Wat maakt dat dan meer flexibel? Hij heeft een arduino, niet een raspberry pi

[johnkeates]

Elke willekeurige time series database gaat wel werken. MongoDB heeft hier niks mee te maken en is in nagenoeg alle gevallen een slechte keuze (tenzij je echt specifiek een onbeveiligde document store nodig hebt)

Je data is niet relationeel, maar timeseries. Je kan met eens per 15 seconden van slechts 2 sensoren bijna gewoon een CSV bestand maken en steeds de laatst binnengekomen regel er in pleuren. Stel dat je 'meer' of 'beter' wil, dan is de eerstvolgende stap toch echt een timeseries database. Als je daarna nog een tussenstap zou willen maken als je bijv. honderdduizend sensoren elke seconde twee keer will uitlezen, dan kan je iets als Redis er tussen zetten.

tl;dr: een time series database of een CSV bestand, MongoDB heeft er niks mee te maken en MySQL helpt niet.

[ Voor 7% gewijzigd door johnkeates op 25-07-2017 23:31 ]

[SlaadjeBla]

Anoniem: 943161 schreef op dinsdag 25 juli 2017 @ 23:28:
[...]


Wat maakt dat dan meer flexibel? Hij heeft een arduino, niet een raspberry pi

Flexibeler omdat je niet vastzit aan hetgeen wordt ondersteund door je Synology, al zie ik met een korte Google zoekopdracht dat daar ook mogelijkheden zijn met InfluxDB.

Ik dacht aan Sensor (Arduino) --> Storage (Raspberry pi met InfluxDB)
Voor visualisatie kun je dan zelf kiezen wat je wil gebruiken. Grafana zou een goede keuze kunnen zijn.

[Anoniem: 943161]

Dan zit je vast aan wat door de pi ondersteund wordt.

Ik zou het, gezien ook de vraagstelling, vooral simpel houden en niet te moeilijk gaan doen. Dit gaat niet om een heel tijdskritische toepassing. Het voordeel van dan een meer standaard database als MySQL te gebruiken, is dat je ook de rest van je toepassing daar gebruik van kunt maken.

Maar, eerlijk is eerlijk, als het zuiver om sensordata gaat, is Influx een nóg betere keuze.

[Anoniem: 943161]

johnkeates schreef op dinsdag 25 juli 2017 @ 23:31:
Je data is niet relationeel, maar timeseries.

De data is 100% relationeel. Daar is geen discussie over mogelijk. Het is óók timeseries. Het één sluit het ander niet uit.

Je kan met eens per 15 seconden van slechts 2 sensoren bijna gewoon een CSV bestand maken en steeds de laatst binnengekomen regel er in pleuren. Stel dat je 'meer' of 'beter' wil, dan is de eerstvolgende stap toch echt een timeseries database. Als je daarna nog een tussenstap zou willen maken als je bijv. honderdduizend sensoren elke seconde twee keer will uitlezen, dan kan je iets als Redis er tussen zetten.

tl;dr: een time series database of een CSV bestand, MongoDB heeft er niks mee te maken en MySQL helpt niet.

Hier ben ik het wél mee eens, mijn eerste gedachte was, gezien de lage hoeveelheid data en lage frequentie, ook om gewoon tekstgebaseerd (csv) te werken.

Echter een échte database geeft dan added functionaliteit welke hij wellicht in de rest van z'n applicatie kan gebruiken.

[johnkeates]

Anoniem: 943161 schreef op dinsdag 25 juli 2017 @ 23:49:
[...]

De data is 100% relationeel. Daar is geen discussie over mogelijk. Het is óók timeseries. Het één sluit het ander niet uit.

[...]

Hoe is de data relationeel? Het zijn eigenlijk tupels, Tijd+Waarde. Elke tijd kan maar 1 waarde hebben, en elke waarde kan maar 1 tijd hebben.

[Anoniem: 943161]

Je hebt sensor (die vergeet je!) , waarde, tijd. Waarbij meerdere sensors beiden tijd/waarde paren registreren.

Een tuple is een row in een relationele database.

[ Voor 6% gewijzigd door Anoniem: 943161 op 26-07-2017 00:45 ]

[Harrie_]

jeroenk13 schreef op dinsdag 25 juli 2017 @ 22:56:
Ik denk eraan om 2 tables te maken, 1tje voor sensor 1 en 1tje voor sensor 2.
Per table heb je alleen het tijdstip en de temperatuur waarde.

farlane schreef op dinsdag 25 juli 2017 @ 23:14:

code:

+--------+-------+------------+
| Sensor | Temp  | DateTimeU  |
+--------+-------+------------+
|      1 | 20,42 | 1501066290 |
|      2 | 19,89 | 1501066290 |
|      1 | 20,43 | 1501066275 |
|      2 | 19,88 | 1501066275 |
|      1 | 20,41 | 1501066260 |
|      2 | 19,88 | 1501066260 |
+--------+-------+------------+

[Stoelpoot]

Anoniem: 943161 schreef op woensdag 26 juli 2017 @ 00:45:
Je hebt sensor (die vergeet je!) , waarde, tijd. Waarbij meerdere sensors beiden tijd/waarde paren registreren.

Een tuple is een row in een relationele database.

TS heeft niet expliciet aangegeven dat de sensors ook aan elkaar gelinked zijn. Zoals ik de specificaties lees, is dit niet zo en is het dus gewoon een lijst aan waardes die wordt uitgelezen zonder enige relaties.

[farlane]

rikpro schreef op woensdag 26 juli 2017 @ 11:02:
[...]


TS heeft niet expliciet aangegeven dat de sensors ook aan elkaar gelinked zijn. Zoals ik de specificaties lees, is dit niet zo en is het dus gewoon een lijst aan waardes die wordt uitgelezen zonder enige relaties.

De sensoren zijn niet aan elkaar gelinked, maar de serie wel aan de sensor. Begrijp niet zo goed dat daar discussie over is.

[Stoelpoot]

farlane schreef op woensdag 26 juli 2017 @ 11:19:
[...]

De sensoren zijn niet aan elkaar gelinked, maar de serie wel aan de sensor. Begrijp niet zo goed dat daar discussie over is.

TS geeft ook aan van plan te zijn voor elke sensor een aparte table te maken. Als de data niet aan elkaar gelinked is, is dit waarschijnlijk ook de goede keuze in het geval dat later voor 1 sensor meer data moet worden opgenomen. Ik denk dat er ook van uit kan worden gegaan dat de datasets niet gelijktijdig worden opgevraagd.

[anboni]

Is iets als http://oss.oetiker.ch/rrdtool/ daar niet juist voor ontwikkeld?

[Creepy]

Dus voor elke nieuwe sensor een nieuwe tabel aanmaken? Sorry, maar dan heb je het echt niet begrepen. Dat kan de TS wel willen in eerste instantie, maar dat klopt gewoon niet. Ik denk dat jeroenk13 dat nu wel inziet.

[Anoniem: 943161]

Eh, rikpro, alsjeblieft, ga nu geen onzin verkondigen.

Je hebt twee exact dezelfde gegevens met dezelfde tuples. Datum en gemeten waarde. Dan ga je GEEN aparte tabellen maken.

Deze gegevens zijn gewoon relationeel. Zelfs al was het alleen tijd + waarde geweest voor één sensor.

[Merethil]

rikpro schreef op woensdag 26 juli 2017 @ 11:34:
[...]


TS geeft ook aan van plan te zijn voor elke sensor een aparte table te maken. Als de data niet aan elkaar gelinked is, is dit waarschijnlijk ook de goede keuze in het geval dat later voor 1 sensor meer data moet worden opgenomen. Ik denk dat er ook van uit kan worden gegaan dat de datasets niet gelijktijdig worden opgevraagd.

Als er meerdere typen data uit één sensortype komt lijkt het me nog steeds nutteloos om dit in een aparte tabel te doen. Ik zou dan nog eerder opten om de data op te slaan in één tabel en er een "datatype" (o.i.d.) kolom aan toe te voegen; zo kan je alles in je ene tabel kwijt en hoef je niet later als je meer sensoren wil toevoegen ook meer tabellen te raadplegen.
Dan kan je gewoon al je sensoren data laten dumpen en zet je in de datatype-kolom neer wat voor data uit de sensor is gekomen. Niet geweldig netjes, maar het voorkomt dat je constant grotere tabellen moet maken alleen omdat je een sensor hebt die twee waarden wil rapporteren ipv één.
De datatype-kolom kan je dan weer uitnormaliseren naar een andere stamtabel waar je in bijhoudt dat bijvoorbeeld alles met datatype 1 temperatuur is, maar alles met datatype 2 is hoogte. Of vochtigheid. Of wat dan ook.

[ Voor 25% gewijzigd door Merethil op 26-07-2017 11:42 ]

[Anoniem: 943161]

Harrie_ schreef op woensdag 26 juli 2017 @ 10:56:

code:

+--------+-------+------------+
| Sensor | Temp  | DateTimeU  |
+--------+-------+------------+
|      1 | 20,42 | 1501066290 |
|      2 | 19,89 | 1501066290 |
|      1 | 20,43 | 1501066275 |
|      2 | 19,88 | 1501066275 |
|      1 | 20,41 | 1501066260 |
|      2 | 19,88 | 1501066260 |
+--------+-------+------------+

Met alle respect, maar tenzij die sensor een ID is welke verwijst naar een andere tabel, is dit slecht design.

code:

sensor
id    naam
1     sensor 1
2     sensor 2

measurements

id  sensor_id  tijd    waarde
1       1            a      b
2       1            c       d
3       2            a       x

Srry ik werk het niet ff zo netjes uit in ascii, maar het is wel duidelijk zo denk ik.

Verder begrijp ik niet helemaal waarom het relationeel zijn van deze data (in de context: welke database gebruik ik?) ter discussie wordt gesteld. Dit is gewoon 100000000000% relationele data.

[712641]

Ik heb zelf voor zoiets gewoon een simpel binair bestand gebruik, want de data is toch zo statisch als wat en je leest het alleen maar uit...

[Anoniem: 943161]

Merethil schreef op woensdag 26 juli 2017 @ 11:40:
Als er meerdere typen data uit één sensortype komt lijkt het me nog steeds nutteloos om dit in een aparte tabel te doen. Ik zou dan nog eerder opten om de data op te slaan in één tabel en er een "datatype" (o.i.d.) kolom aan toe te voegen; zo kan je alles in je ene tabel kwijt en hoef je niet later als je meer sensoren wil toevoegen ook meer tabellen te raadplegen.

Een recept voor rommel. Het is handig om dit soort developers/DBA vragen ook aan developers/DBA's over te laten om te beantwoorden. Zaken maar tegen heug en meug in in één tabel willen stoppen, is gewoon gepruts.

[Merethil]

Anoniem: 943161 schreef op woensdag 26 juli 2017 @ 11:44:
[...]


Een recept voor rommel. Het is handig om dit soort developers/DBA vragen ook aan developers/DBA's over te laten om te beantwoorden. Zaken maar tegen heug en meug in in één tabel willen stoppen, is gewoon gepruts.

Check vooral even mijn uitbreiding. Het gaat mij hier om normalisatie en die data die uit de sensor zal komen zal altijd wel een integer/string zijn, dus gewoon dumpen in een varchar-kolom. Het is geen rocketscience, het is geen gigantische bron aan data, het is een sensor. Die dingen zijn dom en leveren één of twee waarden die daarna in een statistiekje getoond moeten worden. Alles nog verder uitnormaliseren of wat dan ook slaat helemaal nergens op in een project van dit niveau.

Daarnaast doel ik er wel op dat je je sensoren in een aparte tabel bijhoudt en een foreign key in je measurements op sensor_id oid legt he. Ik zeg niet alles letterlijk in één tabel te stouwen. Excuus als het zo overkwam.

[ Voor 11% gewijzigd door Merethil op 26-07-2017 11:48 ]

[Anoniem: 943161]

Je gaat geen sensordate in een varchar gooien, tenzij het een varchar is.

Ik geef toe het is een simpel project dus je kunt bochten afsnijden, maar besef je wel dat wat er hier nu allemaal voorgesteld wordt vanuit professioneel developersoptiek ronduit gepruts is en bochten afsnijden.

Doe het gewoon goed. Als je een timebased DB kunt gebruiken, is dat een goede. Kan dat niet, pak dan een relationele database en maak gewoon op de juiste wijze tabellen aan.

[Merethil]

Anoniem: 943161 schreef op woensdag 26 juli 2017 @ 11:48:
Je gaat geen sensordate in een varchar gooien, tenzij het een varchar is.

Ik geef toe het is een simpel project dus je kunt bochten afsnijden, maar besef je wel dat wat er hier nu allemaal voorgesteld wordt vanuit professioneel developersoptiek ronduit gepruts is en bochten afsnijden.

Doe het gewoon goed. Als je een timebased DB kunt gebruiken, is dat een goede. Kan dat niet, pak dan een relationele database en maak gewoon op de juiste wijze tabellen aan.

Wat voor kolom zou jij kiezen voor sensordata in het algemeen dan? Ik zou niet aanraden voor alle sensoren aparte kolommen te maken omdat sensor 1 een int teruggeeft terwijl sensor 2 een varchar teruggeeft. Lijkt me een heel slechte tabel worden als je dan overal lekker kolommen mag toevoegen omdat je eens een sensortype toevoegt.

Ben ook heel benieuwd hoe jouw "professioneel developersoptiek" hier naar kijkt dan.

[ Voor 4% gewijzigd door Merethil op 26-07-2017 11:51 ]

[Stoelpoot]

Anoniem: 943161 schreef op woensdag 26 juli 2017 @ 11:39:
Eh, rikpro, alsjeblieft, ga nu geen onzin verkondigen.

Je hebt twee exact dezelfde gegevens met dezelfde tuples. Datum en gemeten waarde. Dan ga je GEEN aparte tabellen maken.

Deze gegevens zijn gewoon relationeel. Zelfs al was het alleen tijd + waarde geweest voor één sensor.

Voor performance is het apart moeten filteren van de tabel puur omdat je maar de helft van de data wilt hebben dan weer compleet onnodig (de impact zal verwaarloosbaar zijn, maar het heeft enige impact). Bij dit soort projecten is het gebruik van 2 tabellen geen doodzonde. Ongebruikelijk, maar dat is elke maatoplossing, anders hoeft het geen maatoplossing te zijn.

Ik hoop dat ik de punten tegenover de laatste zin niet hoef te beargumenteren... Anders zou ik even het begrip 'relatie' opzoeken.

Anoniem: 943161 schreef op woensdag 26 juli 2017 @ 11:42:
[...]


Met alle respect, maar tenzij die sensor een ID is welke verwijst naar een andere tabel, is dit slecht design.

[...]

Srry ik werk het niet ff zo netjes uit in ascii, maar het is wel duidelijk zo denk ik.

Verder begrijp ik niet helemaal waarom het relationeel zijn van deze data (in de context: welke database gebruik ik?) ter discussie wordt gesteld. Dit is gewoon 100000000000% relationele data.

Op de manier zoals het daar is opgesteld wel ja. Maar zonder die extra tabel voor de sensor is het gewoon een lijst met waardes. En om een relatie toe te voegen in dit geval lijkt me erg veel overengineeren voor een simpel project.

712641 schreef op woensdag 26 juli 2017 @ 11:43:
Ik heb zelf voor zoiets gewoon een simpel binair bestand gebruik, want de data is toch zo statisch als wat en je leest het alleen maar uit...

Dit zou ik ook sterk overwegen ja. Het ligt eraan hoe veel gegevens je wilt en hoe snel je ze wilt, dan zou je eventueel indexing nodig hebben. Maar anders is een database al ietwat overkill voor dit soort data.

[Anoniem: 943161]

Merethil schreef op woensdag 26 juli 2017 @ 11:50:
[...]


Wat voor kolom zou jij kiezen voor sensordata in het algemeen dan? Ik zou niet aanraden voor alle sensoren aparte kolommen te maken omdat sensor 1 een int teruggeeft terwijl sensor 2 een varchar teruggeeft. Lijkt me een heel slechte tabel worden als je dan overal lekker kolommen mag toevoegen omdat je eens een sensortype toevoegt.

Ben ook heel benieuwd hoe jouw "professioneel developersoptiek" hier naar kijkt dan.

Je maakt de juiste waardetypes aan voor bepaalde waardes. Of een EAV model, al zou ik die kant al niet op willen gaan.

Verder; het gaat hier om de keuze database. Ik zou een tekstbestand of .csv ook overwegen, zoals eerder aangegeven.

Dus in de vraagstelling wat voor database dan. Timebased of relationeel. Is het enige mogelijke juiste antwoord.

Als je het over performance wilt hebben, wat volgens mij bij 2 waarden per 15s helemaal geen issue is, dan is het in een varchar stoppen óók bar slecht voor je performance. Een int wordt sneller geindexeerd en gevonden dan een varchar.

[ Voor 11% gewijzigd door Anoniem: 943161 op 26-07-2017 11:55 ]

[712641]

@rikpro Ik heb een socket gemaakt voor directe data. Die toont dan de laatste twintig metingen direct uit geheugen, zodat je realtime kan zien wat er gebeurd. Voor data-analyse heb ik toch geen instantane data nodig, dus hij slaat ook de data op in een textbestand. Het is één thread in één programma, dus ik zie daar geen enkel probleem in. Voordeel is ook dat de instantane data een hogere resolutie kan hebben. Dat opslaan zou ondoenbaar zijn geweest want ik heb nu al zo'n 1 mb per maand aan data... En dat is dan een meting elke minuut...

[ Voor 22% gewijzigd door 712641 op 26-07-2017 11:58 ]

[Merethil]

Anoniem: 943161 schreef op woensdag 26 juli 2017 @ 11:54:
[...]


Je maakt de juiste waardetypes aan voor bepaalde waardes. Of een EAV model, al zou ik die kant al niet op willen gaan.

Verder; het gaat hier om de keuze database. Ik zou een tekstbestand of .csv ook overwegen, zoals eerder aangegeven.

Dus in de vraagstelling wat voor database dan. Timebased of relationeel. Is het enige mogelijke juiste antwoord.

Lijkt me leuk, hoe verwacht jij in een tekstbestand/.csv dan de juiste datatypes mee te geven? Daar staat het allemaal als String in.
Ja, je wilt de juiste waardetypes aanmaken voor bepaalde waardes, maar als je zo'n lijstje van sensoren hebt, en de één geeft een float voor temp, de andere een double voor vochtigheid, de ander een integer voor lichtsterkte, de andere een true/false voor een deur die openstaat. Ga jij dan werkelijk vertellen dat jij je kolommen gaat uitbreiden tot een structuur waar elk van deze waarde een eigen kolom is? Lijkt me heel onhandig alles moeten ombouwen mocht je eens een sensor toevoegen waar weer een ander type uit komt.

Maar goed, in een professionele omgeving zou je inderdaad een timebased database gebruiken, neemt niet weg dat dit totaal geen professioneel gebruik is en het erom gaat hoe het enigszins uitgenormaliseerd kan worden zodat je makkelijk sensoren kan toevoegen/verwijderen zonder ombouwen van je app/website/watdanook.

Als je het over performance wilt hebben, wat volgens mij bij 2 waarden per 15s helemaal geen issue is, dan is het in een varchar stoppen óók bar slecht voor je performance. Een int wordt sneller geindexeerd en gevonden dan een varchar.

Ja, sneller, maar moet het snel geindexeerd worden? En hoe vaak ga je zoeken op een bepaalde waarde in die lijst? Je indexeert toch gewoon op sensor_id en timestamp? Dan kan je namelijk per sensor een grafiekje maken met resultaten over time. Als je wil gaan zoeken op specifieke waardes dan moet je sowieso gaan kijken naar een andere aanpak, dan wil je inderdaad verder gaan uitbouwen omdat je niet een gecombineerde kolom kan maken.

[ Voor 19% gewijzigd door Merethil op 26-07-2017 11:59 ]

[Anoniem: 943161]

Jongens blijf nu even reeel. Als je het tekstgebaseerd opslaat, geef je natuurlijk geen datatype mee en sla je het op als binair.

Uitnormaliseren van allemaal verschillende types sensorwaardes zijn verschillende oplossingen voor, waarbij EAV de meest elegante maar ook de minst performende is.

[TheBorg]

Waarom zo moeilijk. Het lijkt me een hobby project. Dan moet je ook kijken wat je in de toekomst met de opgedane kennis wil doen. Wil je nu veel tijd steken in het leren van InfluxDB of installeer je gewoon iets simpels als SQLite of MySQL dat waarschijnlijk met één druk op de knop op de NAS is geïnstalleerd.

Daarnaast is binair bestand ook een goede oplossing maar dan ben je denk ik net wat langer bezig.

[Merethil]

Anoniem: 943161 schreef op woensdag 26 juli 2017 @ 11:59:
Jongens blijf nu even reeel. Als je het tekstgebaseerd opslaat, geef je natuurlijk geen datatype mee en sla je het op als binair.

Uitnormaliseren van allemaal verschillende types sensorwaardes zijn verschillende oplossingen voor, waarbij EAV de meest elegante maar ook de minst performende is.

Ja, maar ga dan ook geen discussie lopen houden over hoe dit een "slechte" oplossing zou zijn; het is duizend keer beter dan in een bestandje wegstoppen want nu kan je tenminste indexeren/queryen/inserten/updaten zonder dat het meerdere minuten duurt omdat je alles op een niet-geoptimaliseerde manier ophaalt, wegschrijft en omzet.

Lekker handig als jouw .csv straks 10 miljoen rijen bevat en je wil alles van sensor 1 hebben, maar toevallig is 8+ miljoen sensor 1 en dus ga je lekker alles in memory lopen doorzoeken.

Even tussendoor. EAV is mijn oplossing dus. Meest elegant maar toch een slechte oplossing volgens jou. Spreek je jezelf nou niet helemaal tegen? Performt trouwens nog steeds een stuk lekkerder dan een .csv file of een "binair bestandje".

[ Voor 11% gewijzigd door Merethil op 26-07-2017 12:03 ]

[712641]

@TheBorg Ik heb vooral voor binair gekozen omdat het ruimte scheelt (toch al gauw 40% t.o.v. een plain text file). Op zo'n microcomputertje heb je maar weinig ruimte... Het is een kwestie van het bereik vaststellen dat de data gebruikt.

@Merethil Is het sowieso niet sneller om een bestand naar je normale computer te kopiëren i.p.v. op een trage Rasberry te gaan werken...

[ Voor 32% gewijzigd door 712641 op 26-07-2017 12:06 ]

[Anoniem: 943161]

EAV was niet jouw oplossing. Jij vrot alles in een varchar. Dat is NIET EAV.

Ik ben het eens met TheBorg. We moeten wel redelijk blijven. Er is sprake van 2 sensoren, niet een miljoen. Er is geen performance issue, want 2 waardes in 15s. Er staat nog helemaal niet vast dat de sensoren in kwestie verschillende datatypes waarde retourneren.

Dan moet je redelijk blijven. Topicstarter vraag waarin dat op te slaan en geeft aan een beginner te zijn.

Dan is MySQL ws het makkelijkst en zou een timebased oplossing nog mooier zijn.

Tekstgebaseerd kan zeker, maar is complexer te realiseren voor een beginner. Big data zou in dit verband Big nonsense zijn.

[ Voor 15% gewijzigd door Anoniem: 943161 op 26-07-2017 12:12 ]

[Merethil]

712641 schreef op woensdag 26 juli 2017 @ 12:04:
@TheBorg Ik heb vooral voor binair gekozen omdat het ruimte scheelt. Op zo'n microcomputertje heb je maar weinig ruimte... Het is een kwestie van het bereik vaststellen dat de data gebruikt.

@Merethil Is het sowieso niet sneller om een bestand naar je normale computer te kopiëren i.p.v. op een trage Rasberry te gaan werken...

Ligt er heel erg aan wat je doet; ik kan op een raspberry best een prima performende MySQL\SQLite krijgen, maar hij wil het zelf op zijn NAS doen. Ik weet niet wat voor NAS hij heeft; zou zomaar kunnen zijn dat daar een prima processor en wat geheugen in zit en dan draait MySQL ook prima.

Maar sowieso; als je ook iets wil doen met die sensordata buiten een statische bron ophalen en eenmaal bekijken (zeg, je wil er een website omheen hebben bijvoorbeeld), dan is een database sowieso sneller dan een bestandje. Zeker met 115200 records per dag. Hebben we het nog niet gehad over locking e.d.; wat gebeurt er met dat bestande als jouw website probeert alle data uit te lezen van de afgelopen drie dagen, terwijl jouw sensoren willen bijschrijven?

[712641]

@Merethil Ik heb bewust geen website, dus in mijn geval is dat niet van toepassing.

[Merethil]

Anoniem: 943161 schreef op woensdag 26 juli 2017 @ 12:06:
EAV was niet jouw oplossing. Jij vrot alles in een varchar. Dat is NIET EAV.

Ik ben het eens met TheBorg. We moeten wel redelijk blijven. Er is sprake van 2 sensoren, niet een miljoen. Er is geen performance issue, want 2 waardes in 15s. Er staat nog helemaal niet vast dat de sensoren in kwestie verschillende datatypes waarde retourneren.

Dan moet je redelijk blijven. Topicstarter vraag waarin dat op te slaan en geeft aan een beginner te zijn.

Dan is MySQL ws het makkelijkst.

Lees even goed wat ik voorstel. Ik stelde dit voor:

code:

sensors

id    name
1    sensor_1
2    sensor_2

code:

sensor_data_type

id    name
1    temperature
2    height
3    air_density
4    door_open

code:

measurements

id    sensor_id    timestamp    value    data_type
1    1              12570127     "12.3"   1
2    1              12575126     "312"    2
3    2              12575127     "12.8"   1
4    2              12575127     "true"    4

Dit is nagenoeg letterlijk EAV zoals beschreven hier: Wikipedia: Entity–attribute–value model

712641 schreef op woensdag 26 juli 2017 @ 12:10:
@Merethil Ik heb bewust geen website, dus in mijn geval is dat niet van toepassing.

Dan is een binair bestand prima imo, geef ik je groot gelijk in!

[ Voor 11% gewijzigd door Merethil op 26-07-2017 12:14 ]

[Anoniem: 943161]

Merethil: dat is niet EAV. Bij EAV maak je wel degelijk per datatype een aparte tabel en laat je op basis van het datatype de waarde uit de juiste tabel halen.

Wat is in jouw measurementstabel het type van het veld 'value' ?

[Anoniem: 200498]

Eav is onzin in dit geval; er is namelijk maar één attribuut...
Waarom niet als volgt

code:

id    sensor_id    timestamp    value_int  value_varchar value_decimal value_boolean
1    1              12570127                                        12.1
2    2              12575126         123
3    3              12575127                         blabla

Zo kan iedere kolom zijn eigen index gebruiken en is de opslag altijd optimaal.

[ Voor 11% gewijzigd door Anoniem: 200498 op 26-07-2017 12:16 ]

[Merethil]

Anoniem: 943161 schreef op woensdag 26 juli 2017 @ 12:14:
Merethil: dat is niet EAV. Bij EAV maak je wel degelijk per datatype een aparte tabel en laat je op basis van het datatype de waarde uit de juiste tabel halen.

Wat is in jouw measurementstabel het type van het veld 'value' ?

Varchar(max) of varchar(255) (gezien indexing die laatste, waardes zullen niet makkelijk groter worden). Ik ging trouwens even volledig uit van het voorbeeld in mijn EAV-link, daar doen ze exact dit.

Anoniem: 200498 schreef op woensdag 26 juli 2017 @ 12:15:
Eav is onzin in dit geval; er is namelijk maar één attribuut...
Waarom niet als volgt

code:

id    sensor_id    timestamp    value_int  value_varchar value_decimal value_boolean
1    1              12570127                                        12.1
2    2              12575126         123
3    3              12575127                         blabla

Omdat je in dit geval altijd moet uitbouwen als je een nieuw datatype meekrijgt. Stel je wil een extra sensor aankoppelen, waarom zou je dan eerst weer al je code moeten aanpassen om die sensor erin te krijgen?

Dat je het anders uitbouwt in een professionele omgeving ben ik het trouwens mee eens; ben daar er zelf nog nooit tegenaan gelopen.

[ Voor 43% gewijzigd door Merethil op 26-07-2017 12:17 ]

[Anoniem: 943161]

twicejr: verdiep je eens in waar EAV voor bedoeld is. Google op de term 'sparse data'.

EAV is juist bedoeld om te voorkomen wat jij doet, allemaal lege kolommen toevoegen. In jouw database heb je voor elke waarde slechts 1 veld in gebruik, maar tig lege kolommen. Dat heet sparse data. Juist daarvoor is EAV ontwikkeld.

Maar goed, we maken het nu veel te complex.

[Anoniem: 200498]

Anoniem: 943161 schreef op woensdag 26 juli 2017 @ 12:16:
twicejr: verdiep je eens in waar EAV voor bedoeld is. Google op de term 'sparse data'.

EAV is juist bedoeld om te voorkomen wat jij doet, allemaal lege kolommen toevoegen. In jouw database heb je voor elke waarde slechts 1 veld in gebruik, maar tig lege kolommen. Dat heet sparse data. Juist daarvoor is EAV ontwikkeld.

Maar goed, we maken het nu veel te complex.

Waar, maar natuurlijk niet sneller als er maar één attribuut is...
Dan is mijn oplossing toch eenvoudiger.

[Anoniem: 943161]

Merethil schreef op woensdag 26 juli 2017 @ 12:16:
[...]


Varchar(max) of varchar(255) (gezien indexing die laatste, waardes zullen niet makkelijk groter worden). Ik ging trouwens even volledig uit van het voorbeeld in mijn EAV-link, daar doen ze exact dit.

Ze doen het dan ook exact fout. Het is leuk om het principe van EAV uit te leggen, maar die implementatie is fout. Bij een correct uitgevoerde EAV implementatie staat elk gegeven in een voor dat type bedoeld formaat in de database.

[emnich]

Merethil schreef op woensdag 26 juli 2017 @ 12:12:
[...]


Lees even goed wat ik voorstel. Ik stelde dit voor:

code:

sensors

id    name
1    sensor_1
2    sensor_2

code:

sensor_data_type

id    name
1    temperature
2    height
3    air_density
4    door_open

code:

measurements

id    sensor_id    timestamp    value    data_type
1    1              12570127     "12.3"   1
2    1              12575126     "312"    2
3    2              12575127     "12.8"   1
4    2              12575127     "true"    4

toon volledige bericht

Je moet die data_type gewoon bij de sensor opslaan, er is geen reden om die in de measurements tabel te stoppen. Een sensor geeft toch altijd maar één waarde? Hoewel in jouw voorbeeld een sensor meerdere waarden geeft maar volgens mij zijn dat dan meerdere sensoren.

[Merethil]

Anoniem: 943161 schreef op woensdag 26 juli 2017 @ 12:17:
[...]


Ze doen het dan ook exact fout. Het is leuk om het principe van EAV uit te leggen, maar die implementatie is fout. Bij een correct uitgevoerde EAV implementatie staat elk gegeven in een voor dat type bedoeld formaat in de database.

Ik heb inderdaad bronnen gevonden die aangeven tabellen te maken per type data, maar dat is dan weer veel te zwaar uitgebouwd voor dit type project. Dat is wat ik probeer aan te geven. De manier waarop ik het aanvloog is de "basis" van EAV volgens nagenoeg alles wat ik kan vinden op het internet. Waarom dat opeens "slecht" is in dit geval, snap ik niet. Ja, er zijn betere manieren om een integer in een database op te slaan, die wil je liever niet in een varchar, maar laten we dit nou niet nóg verder gaan uitbouwen.

Ik blijf erbij dat een bestandje trouwens nog dommer is, daar is technisch gezien letterlijk alles een varchar, inclusief je referenties als sensor_id, timestamp etc.

emnich schreef op woensdag 26 juli 2017 @ 12:20:
[...]

Je moet die data_type gewoon bij de sensor opslaan, er is geen reden om die in de measurements tabel te stoppen. Een sensor geeft toch altijd maar één waarde? Hoewel in jouw voorbeeld een sensor meerdere waarden geeft maar volgens mij zijn dat dan meerdere sensoren.

Ergens tussendoor werd een keer geopperd dat dit kon gebeuren, daarna begon ik pas mee te praten.

Zie hier:

TS geeft ook aan van plan te zijn voor elke sensor een aparte table te maken. Als de data niet aan elkaar gelinked is, is dit waarschijnlijk ook de goede keuze in het geval dat later voor 1 sensor meer data moet worden opgenomen. Ik denk dat er ook van uit kan worden gegaan dat de datasets niet gelijktijdig worden opgevraagd.

[ Voor 28% gewijzigd door Merethil op 26-07-2017 12:22 ]

[TheBorg]

Dat MySQL geen timeranges ondersteund is heel makkelijk omheen te werken. Vooral als de exacte tijd niet zo belangrijk is. Je kan dan bij het inserten de timestamp afronden naar 15 seconden. Dus timestamp 100008 word timestamp 100015. Je kan dan een select doen die het aantal datapunten reduceert in je grafiek: WHERE timestamp % 3600 = 0. Op die manier heeft een jaaroverzicht niet een miljoen punten.

De tabel zou ik super simpel maken:
timestamp (int)
sensor (tinyint)
value (double/int/decimal)

EAV? We gaan heer geen CRM bouwen wtf...

[Anoniem: 943161]

Ik denk dat e.e.a. wel duidelijk is en ben het met je eens dat full-blown EAV in dit geval ook overcomplex is.

Zoals anderen in dit draadje, zou ik zelf gewoon voor een file gaan en helemaal geen database gebruiken, maar dat is wellicht wat lastiger te implementeren voor een beginner.

Dan blijven als goede opties over MySQL of een timebased database.

[Merethil]

Anoniem: 943161 schreef op woensdag 26 juli 2017 @ 12:23:
Ik denk dat e.e.a. wel duidelijk is en ben het met je eens dat full-blown EAV in dit geval ook overcomplex is.

Zoals anderen in dit draadje, zou ik zelf gewoon voor een file gaan en helemaal geen database gebruiken, maar dat is wellicht wat lastiger te implementeren voor een beginner.

Dan blijven als goede opties over MySQL of een timebased database.

Eens en eens

[farlane]

rikpro schreef op woensdag 26 juli 2017 @ 11:52:
[...]
Voor performance is het apart moeten filteren van de tabel puur omdat je maar de helft van de data wilt hebben dan weer compleet onnodig (de impact zal verwaarloosbaar zijn, maar het heeft enige impact). Bij dit soort projecten is het gebruik van 2 tabellen geen doodzonde. Ongebruikelijk, maar dat is elke maatoplossing, anders hoeft het geen maatoplossing te zijn.

Ik hoop dat ik de punten tegenover de laatste zin niet hoef te beargumenteren... Anders zou ik even het begrip 'relatie' opzoeken.

Op de manier zoals het daar is opgesteld wel ja. Maar zonder die extra tabel voor de sensor is het gewoon een lijst met waardes. En om een relatie toe te voegen in dit geval lijkt me erg veel overengineeren voor een simpel project.

Niet simpel genoeg om je te laten inzien dat jouw idee gepruts is. Als er een sensor wordt bijgeplaatst (en die kans is aanwezig) moet de ts een derde tabel gaan maken?

Anoniem: 943161 schreef op woensdag 26 juli 2017 @ 12:23:
Ik denk dat e.e.a. wel duidelijk is en ben het met je eens dat full-blown EAV in dit geval ook overcomplex is.

Zoals anderen in dit draadje, zou ik zelf gewoon voor een file gaan en helemaal geen database gebruiken, maar dat is wellicht wat lastiger te implementeren voor een beginner.

Dan blijven als goede opties over MySQL of een timebased database.

Ik denk dat SQLite in dit geval veel meer op zijn plaats is dan een flat-file.

[ Voor 21% gewijzigd door farlane op 26-07-2017 12:30 ]

[Anoniem: 943161]

farlane schreef op woensdag 26 juli 2017 @ 12:28:
Niet simpel genoeg om je te laten inzien dat jouw idee gepruts is. Als er een sensor wordt bijgeplaatst (en die kans is aanwezig) moet de ts een derde tabel gaan maken?

Dat jij een oplossing niet begrijpt, maakt van een algemeen geaccepteerd en bekend systeem nog geen gepruts.

Overigens begrijp ik je vraag niet. Nergens zeg ik dat hij per sensor een tabel moet maken? Sterker nog; ik zeg juist dat hij dat níet moet doen.

Wellicht moet je wat beter gaan lezen.

[BramV]

pff wat maakt het nou uit of je 3 tabellen doet met een union of 1 tabel met id... Voor dit hobby project. Stel je voor zeg dat het verkeerd is. Nou nou nou... Maar goed:
Als Mysql makkelijk is te installeren op QNAP dan zou ik dat lekker gebruiken. Simpel.

http://www.instructables....nd-humidity-on-MySQL-wit/

[Merethil]

Anoniem: 943161 schreef op woensdag 26 juli 2017 @ 12:39:
[...]


Dat jij een oplossing niet begrijpt, maakt van een algemeen geaccepteerd en bekend systeem nog geen gepruts.

Overigens begrijp ik je vraag niet. Nergens zeg ik dat hij per sensor een tabel moet maken? Sterker nog; ik zeg juist dat hij dat níet moet doen.

Wellicht moet je wat beter gaan lezen.

Hij had het over rikpro die dit zei:

TS geeft ook aan van plan te zijn voor elke sensor een aparte table te maken. Als de data niet aan elkaar gelinked is, is dit waarschijnlijk ook de goede keuze in het geval dat later voor 1 sensor meer data moet worden opgenomen. Ik denk dat er ook van uit kan worden gegaan dat de datasets niet gelijktijdig worden opgevraagd.

Daar ging het over; jouw oplossing zei hij niets over voor zover ik kan zien, behalve dat SQLite > flat file; waar ook wat over valt te zeggen, maar dan zou ik MySQL nog eerder pakken (ook i.v.m concurrency) zoals jij had aangedragen.

BramV schreef op woensdag 26 juli 2017 @ 12:40:
pff wat maakt het nou uit of je 3 tabellen doet met een union of 1 tabel met id... Voor dit hobby project. Stel je voor zeg dat het verkeerd is. Nou nou nou... Maar goed:
Als Mysql makkelijk is te installeren op QNAP dan zou ik dat lekker gebruiken. Simpel.

http://www.instructables....nd-humidity-on-MySQL-wit/

Goh stel je toch eens voor dat we iemand de juiste (voor zover mogelijk in zoiets kleins, echt goed aanpakken is wel heel erg omslachtig voor zoiets) manier willen aanleren ipv weer iemand hebben die alles naar hartelust aanpakt en weer een zwaar onbeveiligde spaghetti-code-website neerzet waardoor mensen hun wachtwoorden weer overal naartoe uitlekken.

Ik chargeer, maar als je begint met zoiets al verkeerd uit te leggen, dan krijg je al gauw dat mensen aanmodderen, en dat is geen goed begin met programmeren. Als je iets gaat automatiseren moet je dat tegen een bepaalde standaard aan houden, en die standaard haal je niet als je bijvoorbeeld niet leert normaliseren.

[Anoniem: 200498]

Nog een interessante slideshow over Time Series en eventueel gebruik van het JSON datatype in MySQL 5.7 met indexes per 'json kolom'.
https://www.percona.com/r...ysql-all-things-open-2016

[ Voor 30% gewijzigd door Anoniem: 200498 op 26-07-2017 12:49 ]

[BramV]

Merethil schreef op woensdag 26 juli 2017 @ 12:47:
Ik chargeer, maar als je begint met zoiets al verkeerd uit te leggen, dan krijg je al gauw dat mensen aanmodderen, en dat is geen goed begin met programmeren. Als je iets gaat automatiseren moet je dat tegen een bepaalde standaard aan houden, en die standaard haal je niet als je bijvoorbeeld niet leert normaliseren.

Er zijn 1001 standaarden, protocollen en manieren om zaken op te lossen. Er is geen beste manier of eenduidige manier. Van fouten te maken kun je ook heel veel leren. Van de angst om fouten te maken leer je zeker niets.

Ik hanteer KISS, werkt altijd voor mij.

[Merethil]

BramV schreef op woensdag 26 juli 2017 @ 12:52:
[...]


Er zijn 1001 standaarden, protocollen en manieren om zaken op te lossen. Er is geen beste manier of eenduidige manier. Voor fouten te maken kun je ook heel veel leren. Van de angst om fouten te maken leer je zeker niets.

Ik hanteer KISS, werkt altijd voor mij.

Van het fout voorgezegd krijgen leer je sowieso niets Ga er maar vanuit dat er zeker "best practices" zijn, die dus overeenkomen met onderling afgesproken "beste manier" van aanpakken van dit soort zaken. Laten we die dan in ieder geval zoveel mogelijk opperen, en niet aangeven dat er per sensor een tabel komt o.i.d. Dat is gewoon zwaar misbruik maken van een database.

Als je altijd op deze manier werkt wil ik weten waar je werkt. Dan kom ik daar niet werken

[ Voor 16% gewijzigd door Merethil op 26-07-2017 12:55 ]

[CurlyMo]

Merethil schreef op woensdag 26 juli 2017 @ 12:47:
[...]
Ik chargeer, maar als je begint met zoiets al verkeerd uit te leggen, dan krijg je al gauw dat mensen aanmodderen, en dat is geen goed begin met programmeren. Als je iets gaat automatiseren moet je dat tegen een bepaalde standaard aan houden, en die standaard haal je niet als je bijvoorbeeld niet leert normaliseren.

Veel beginnende hobbyisten haken juist af als je hier direct mee begint, omdat het theoretisch blijft. Als TS nu probeert sensordata om te slaan op een verkeersader te automatiseren, dan is het een ander verhaal.

Laat TS dus gewoon lekker beginnen met aanklooien, laat het in 1 tabel zijn per sensor of 10. Zo lang er niks is is er ook nog niks fout gegaan. Van daaruit kan TS weer vragen gaan stellen.

Begin gewoon met MySQL. Daar zijn genoeg tutorials voor, daar leer je het niet perfect mee, maar zolang het werkt is het prima. Als er maar geen levens vanaf hangen

[BramV]

Merethil schreef op woensdag 26 juli 2017 @ 12:54:
[...]
Van het fout voorgezegd krijgen leer je sowieso niets Ga er maar vanuit dat er zeker "best practices" zijn, die dus overeenkomen met onderling afgesproken "beste manier" van aanpakken van dit soort zaken. Laten we die dan in ieder geval zoveel mogelijk opperen, en niet aangeven dat er per sensor een tabel komt o.i.d. Dat is gewoon zwaar misbruik maken van een database.

Zwaar misbruik ???? Pfff de hoeveelheid data is lachwekkend klein, stelt niks voor... Dat is nou wat ik precies bedoel: door 'zware woorden' te gebruik wek je indruk dat er iets verschrikkelijks gaat gebeuren....

[Zebby]

Wat betreft het gebruik van een tekstbestand, is dat wel handig wat betreft gezien er toch snel miljoenen records in komen? Nu is dit ook niet heel schokkend, maar voor de performance wil je meestal tekstbestanden kleiner dan 250mb houden. Volgens mij ga je dan lastigere code introduceren dan bij het gebruik van een database.

Wat betreft de database, hou het makkelijk. Je gaat geen honderden tabellen met complexe referentiële data creëren. Of je het nou in 1 tabel gooit en MongoDB als vervanger van je tekstbestand gebruikt, of iets "netter" gaat werken met een Postgres/sqlite/mysql db en 3 tabellen, gaat geen wezenlijk verschil maken. Ik zou eigenlijk zeggen - kies degene waar je wat van wilt leren.

[Merethil]

CurlyMo schreef op woensdag 26 juli 2017 @ 12:56:
[...]

Veel beginnende hobbyisten haken juist af als je hier direct mee begint, omdat het theoretisch blijft. Als TS nu probeert sensordata om te slaan op een verkeersader te automatiseren, dan is het een ander verhaal.

Laat TS dus gewoon lekker beginnen met aanklooien, laat het in 1 tabel zijn per sensor of 10. Zo lang er niks is is er ook nog niks fout gegaan. Van daaruit kan TS weer vragen gaan stellen.

Begin gewoon met MySQL. Daar zijn genoeg tutorials voor, daar leer je het niet perfect mee, maar zolang het werkt is het prima. Als er maar geen levens vanaf hangen

Ik denk dat het voor een beginner juist prima te behappen is als je maar uitlegt waarom je het zo doet. Mensen die dan niet verder "durven" kan ik niet over praten; ben ze zelf nog niet tegengekomen. Wel merk ik dat TS hier al lang niet meer is geweest, maar gok dat dat misschien ligt aan werk/geen tijd om op Tweakers te zitten, niet zozeer omdat hij het niet snapt (want anders hadden er vast wel vragen geweest).

BramV schreef op woensdag 26 juli 2017 @ 12:57:
[...]

Zwaar misbruik ???? Pfff de hoeveelheid data is lachwekkend klein, stelt niks voor... Dat is nou wat ik precies bedoel: door 'zware woorden' te gebruik wek je indruk dat er iets verschrikkelijks gaat gebeuren....

Ik zeg helemaal niet dat er iets verschrikkelijks gaat gebeuren, maar wil je dat zijn projectje niet verder kan uitgroeien? Als je nu een sensor wil toevoegen, moet hij applicatie en database aan gaan lopen passen. Als hij het iets generieker opzet is het in ieder geval veel makkelijker in gebruik. Wat we aangeven zijn best practice tips, gewoon uit het feit dat duizenden mensen deze fouten al eens hebben gemaakt. Het is goed om te leren van je fouten, maar niet leren van fouten van duizenden anderen is gewoon dom.

"Zwaar misbruik" duidde in mijn geval dan ook alleen op het feit dat het gewoon not-done is om voor relationele zaken niet-relationeel te werken. Het is omslachtig, nutteloos en naar mijn mening gebruik je je database dan als veredelde flat file.

[ Voor 5% gewijzigd door Merethil op 26-07-2017 13:01 ]

[Kalentum]

jeroenk13 schreef op dinsdag 25 juli 2017 @ 22:56:
Gewoon MySQL of is wellicht MongoDB beter? De database zal lopen op een Synology NAS.

Als je voor een relationale database gaat: PostgreSQL. Dat staat al op je Synology.

[gekkie]

Met postgresql kun je ook nog redelijk (storage) efficiente index type voor timeseries gebruiken (BRIN index).
Afhankelijk van je queries kun je er een paar aan maken op basis van een getrunc't timestamp.

Maar goed ik zie voor de rest alle problemen niet zo, begin simpel, je data, ook uit een flat table is altijd nog prima om te zetten in iets anders.

[farlane]

Anoniem: 943161 schreef op woensdag 26 juli 2017 @ 12:39:
[...]
Dat jij een oplossing niet begrijpt, maakt van een algemeen geaccepteerd en bekend systeem nog geen gepruts.

Overigens begrijp ik je vraag niet. Nergens zeg ik dat hij per sensor een tabel moet maken? Sterker nog; ik zeg juist dat hij dat níet moet doen.

Wellicht moet je wat beter gaan lezen.

Zoals Merethil al aangaf is dat geen reactie op jou.

[Cloud]

rutgerw schreef op woensdag 26 juli 2017 @ 13:09:
[...]


Als je voor een relationale database gaat: PostgreSQL. Dat staat al op je Synology.

Is die standaard wel zo eenvoudig in gebruik? Volgens mij staat die db standaard dicht voor gebruik van buitenaf en kun je dat alleen oplossen door met ssh + root dingen op je Synology aan te passen.

Volgens mij is MariaDB installeren als package op je Synology (eventueel samen met phpMyAdmin) wellicht een iets praktischere manier Al vind ik PostgreSQL wel de mooiere database van die twee.

[incaz]

farlane schreef op woensdag 26 juli 2017 @ 12:28:
Niet simpel genoeg om je te laten inzien dat jouw idee gepruts is. Als er een sensor wordt bijgeplaatst (en die kans is aanwezig) moet de ts een derde tabel gaan maken?

Afhankelijk van wat je ermee doet, ja, waarom niet? Tabellen zijn niet inherent slecht, moeten niet ten koste van alles voorkomen worden - wat centraal moet staan is of het in de context van wat je ermee doet meer hetzelfde is, of meer verschillend.

Zo heeft bijna ieder project op een bepaald moment een heleboel tabellen met het basisformaat id-shortname-description-active. Het abstracte type is dus vergelijkbaar voor al die tabellen, maar de functie kan heel anders zijn: binnen een bugtracker bijvoorbeeld zijn reportType en reportStatus vaak in de praktijk zo'n keuzelijstje, maar hun functie is anders. Die zet ik liever in aparte tabellen neer dan in 1 tabel met een kolom 'typeType.'

Terug naar de temperaturen: het maakt vooral uit welke queries je daarop wilt doen. Gaat het ene over de buitentemperatuur en de andere over de oventemperatuur (en die illustere derde 'cpu-temp') dan is er weinig onderlinge relatie, en is het te verantwoorden om aparte tabellen te gebruiken totdat het niet meer werkt.

Er is overigens ook een redelijke vuistregel voor wanneer je beter een type-kolom kunt opnemen: zodra je de neiging hebt om tabelnamen in een variabele te stoppen. Dat is het punt dat de overeenkomst blijkbaar belangrijk genoeg wordt, en dat is het moment dat je dus beter even extra tijd kunt nemen om (heel Agile) je db en je code te herschrijven naar 1 tabel met alle waarden. (Overigens: is niet buitengewoon ingewikkeld dus het is helemaal niet erg om eerst iets te hardcoden en het daarna aan te passen.)

[Harrie_]

Anoniem: 943161 schreef op woensdag 26 juli 2017 @ 11:42:
[...]


Met alle respect, maar tenzij die sensor een ID is welke verwijst naar een andere tabel, is dit slecht design.

code:

sensor
id    naam
1     sensor 1
2     sensor 2

measurements

id  sensor_id  tijd    waarde
1       1            a      b
2       1            c       d
3       2            a       x

Srry ik werk het niet ff zo netjes uit in ascii, maar het is wel duidelijk zo denk ik.

Verder begrijp ik niet helemaal waarom het relationeel zijn van deze data (in de context: welke database gebruik ik?) ter discussie wordt gesteld. Dit is gewoon 100000000000% relationele data.

toon volledige bericht

Ik stel niet ter discussie dat het relationeel is, want dat is het inderdaad.

Maar ik snap niet zo goed waarom het slecht design is?
Ik reageerde slechts op de OP en de post van @Creepy dat het inderdaad een slecht idee is om voor elke sensor een aparte tabel aan te maken en wilde eigenlijk alleen maar een 'proof of concept' van 1 tabel laten zien. Of je vervolgens een sensorID als foreign key laat verwijzen naar de sensortable of gewoon een nummer/naam in je meetwaardentable mikt om de sensors uit elkaar te houden dat doet in deze usecase toch niet zozeer ter zake?

Het ging er uiteindelijk om dat je de meetwaarden van beide sensors in 1 tabel kunt mikken om vervolgens

code:

SELECT [...] FROM meetwaarden WHERE sensor = 1

[farlane]

incaz schreef op woensdag 26 juli 2017 @ 15:07:
[...]
Afhankelijk van wat je ermee doet, ja, waarom niet?
.. meer verhaal ...

Whut? Ik heb het over de situatie zoals de TS 'em schetst : 2 sensoren die beide "een" temperatuur aangeven. In welk universum is het beter om daar 2 tabellen voor te nemen ipv 1 tabel met daarin een kolom welke sensor het om gaat (al dan niet gekoppeld met een "sensoren" tabel)?

De man is duidelijk een beginner, wil je hem dan echt die manier van werken gaan aanleren?

[Anoniem: 943161]

Harrie_ schreef op woensdag 26 juli 2017 @ 15:17:
Ik stel niet ter discussie dat het relationeel is, want dat is het inderdaad. Maar ik snap niet zo goed waarom het slecht design is?

Ik kan mij voorstellen dat je dat afvraagt, zeker omdat de query, bij zo'n simpel voorbeeld, hetzelfde zal zijn.

Het gaat te ver om het hier helemaal uit te gaan diepen, maar het komt er op neer dat de data in een tabel afhankelijk moet zijn van de key, en alleen van de key. Dat is één van de principes achter normaliseren.

De key is daarmee een abstracte waarde. Door eigelijk de sensornaam als key te gebruiken, gebruik je een soort van foreign key als primary key, en da's niet netjes.

Wikipedia: Databasenormalisatie

[gekkie]

Anoniem: 943161 schreef op woensdag 26 juli 2017 @ 16:38:
[...]


Ik kan mij voorstellen dat je dat afvraagt, zeker omdat de query, bij zo'n simpel voorbeeld, hetzelfde zal zijn.

Het gaat te ver om het hier helemaal uit te gaan diepen, maar het komt er op neer dat de data in een tabel afhankelijk moet zijn van de key, en alleen van de key. Dat is één van de principes achter normaliseren.

De key is daarmee een abstracte waarde. Door eigelijk de sensornaam als key te gebruiken, gebruik je een soort van foreign key als primary key, en da's niet netjes.

Wikipedia: Databasenormalisatie

De theorie is goed.. , maat ben je er ook al wel eens tegen aan gelopen dat je in sommige gevallen ook kunt "over-normaliseren" ?
(met als mogelijk gevolg een zuigende performance, of zoals in dit geval een wat ge-over-engineerde oplossing? (uiteraard is het omgekeerde ook mogelijk, daarom is het te kijken naar het doel en de nabije toekomst van je project en de mogelijkheden en moeite die het kost om het later eventueel als nog aan te passen.)

[Anoniem: 943161]

gekkie schreef op woensdag 26 juli 2017 @ 16:43:
[...]

De theorie is goed.. , maat ben je er ook al wel eens tegen aan gelopen dat je in sommige gevallen ook kunt "over-normaliseren" ?
(met als mogelijk gevolg een zuigende performance, of zoals in dit geval een wat ge-over-engineerde oplossing? (uiteraard is het omgekeerde ook mogelijk, daarom is het te kijken naar het doel en de nabije toekomst van je project en de mogelijkheden en moeite die het kost om het later eventueel als nog aan te passen.)

Er bestaat niet zoiets als overnormalisatie. Er bestaat wél zoiets als mensen die niet kunnen normaliseren en dan vastlopen.

De derde normaalvorm is geen overnormaliseren. Dat is gewoon in elk project een minimumvereiste.

Pas bij performanceproblemen kun je er voor kiezen op sommige velden te denormaliseren, maar dat is dan ook alles.

De kunst van goed databasedesign is verloren aan het gaan. De opkomst van Big Data is niet omdat er zoveel big data is, maar omdat dan prutsers die niet kunnen normaliseren, een andere oplossing hebben.

[gekkie]

Anoniem: 943161 schreef op woensdag 26 juli 2017 @ 16:53:
[...]


Er bestaat niet zoiets als overnormalisatie. Er bestaat wél zoiets als mensen die niet kunnen normaliseren en dan vastlopen.

De derde normaalvorm is geen overnormaliseren. Dat is gewoon in elk project een minimumvereiste.

Pas bij performanceproblemen kun je er voor kiezen op sommige velden te denormaliseren, maar dat is dan ook alles.

De kunst van goed databasedesign is verloren aan het gaan. De opkomst van Big Data is niet omdat er zoveel big data is, maar omdat dan prutsers die niet kunnen normaliseren, een andere oplossing hebben.

Big data is min of meer vooraf je (gewenste) relaties niet vooraf kunnen of willen vastleggen.

Ik begrijp dat je daar met je theorie van alles van kan vinden, als je de capaciteit bezit om ietsjes pragmatiser te denken dan zie dat dat soms om zeer uiteenlopende redenen ook gewoon nuttig kan zijn.

En ja het is nuttig om je van normalisatie bewust te zijn, en ja het is nuttig om het (zeker bij projecten en data van enige omvang waar relaties bekend zijn ook toe te passen, echter we hebben het hier over iets wat prima in een platte tabel kan, met een hobbyist als developer, op beperkte hardware, voor een hobby project, met nog prima mogelijkheden om de data te herverbouwen mocht dat in de toekomst nodig zijn (er gaat dan niets verloren en de benodige operatie zijn eenvoudig). Kortom iets met over-engineren.

Maar goed ik neem aan dat jij ook formule 1 slicks op je fiets hebt gebouwd .. je weet immers maar nooit ..

[emnich]

Anoniem: 943161 schreef op woensdag 26 juli 2017 @ 16:53:
[...]


Er bestaat niet zoiets als overnormalisatie. Er bestaat wél zoiets als mensen die niet kunnen normaliseren en dan vastlopen.

De derde normaalvorm is geen overnormaliseren. Dat is gewoon in elk project een minimumvereiste.

Pas bij performanceproblemen kun je er voor kiezen op sommige velden te denormaliseren, maar dat is dan ook alles.

De kunst van goed databasedesign is verloren aan het gaan. De opkomst van Big Data is niet omdat er zoveel big data is, maar omdat dan prutsers die niet kunnen normaliseren, een andere oplossing hebben.

Als je gaat denormaliseren dan heb je toch te veel genormaliseerd?

Natuurlijk heb je voor een heel groot deel gelijk maar afhankelijk van het soort project maak je andere keuzes.

[CurlyMo]

Ik ben in ieder geval blij dat ik de kans kreeg om gewoon met rekenen te beginnen en mijn lerares niet direct met fundamentele wiskunde begon.

Oftewel, wat een discussie voor een vraag waarvan de vraagsteller duidelijk een beginner is.

[Anoniem: 943161]

gekkie schreef op woensdag 26 juli 2017 @ 17:00:
Big data is min of meer vooraf je (gewenste) relaties niet vooraf kunnen of willen vastleggen.

Nee, daar is big data dus niet voor. Big data is voor grote niet relationele datasets. Daarom heet het ook big data.

Kortom iets met over-engineren.

Dit heeft niets met overengineering te maken maar met de basis. Als je op de basis al gaat zitten prutsen, zul je nooit verder komen dan gepruts. Overengineering is een 5e normaalvorm eisen. Dat doe ik niet.

emnich schreef op woensdag 26 juli 2017 @ 17:04:
Als je gaat denormaliseren dan heb je toch te veel genormaliseerd?

Nee. Daar heeft het niets mee te maken. Normaliseren is niet bedacht vanuit overengineerings-perspectief of het mensen lastig te maken. Er is gewoon, al sinds de jaren 70, in de praktijk gebleken dat het werkt. Idealiter wil je dus netjes genormaliseerd werken.

Echter, soms kan het hierdoor ontstaan dat je teveel lees/schrijfbewerkingen krijgt of er andere performance-issues optreden. Omwille van de performance kun je er dan voor kiezen om te denormaliseren, maar ook alleen met dat doel.

Voorbeeld stel je maakt een NAW database waarin mensen meerdere telefoonnummers kunnen hebben. Dan komt er dus een andere tabel voor telefoonnummers. Nu kan het zijn dat je gigantisch veel data in die tabel krijgt en de join met de telefoonnummertabel daarin problemen geeft, terwijl je eigenlijk altijd alleen het hoofdnummer nodig hebt. Je zou in zo'n situatie ervoor kunnen kiezen om toch een kolom 'hoofdtelefoonnummer' in je naw tabel op te nemen.

Dat heeft dus niets met overnormalisatie of overengineering te maken.

Dit zijn vaak de foute denkwijzes die je bij jonge developers ziet. Pas na een 10 jaar werken en ervaring opdoen, ga je leren waarom normaliseren wél goed is.

Vergelijk het met het beginnen met het gebruiken van een agenda. Jonge mensen zullen ook zeggen dat dat veel te ingewikkeld is, teveel werk, enzovoort. Tot ze (door school) gedwongen worden het een tijdje te doen, en 3 jaar later gaan ze huilen als je ze hun agenda afpakt.

//nav moderator hieronder, heb ik een stuk uit mijn posting verwijderd. Dank voor de moderatie!

[ Voor 8% gewijzigd door Anoniem: 943161 op 26-07-2017 17:20 ]

[Creepy]

Hou het netjes en niet op de man spelen. Ik heb nu een reactie al verwijderd en het zou zonde zijn om het topic op slot te gooien..

[emnich]

Anoniem: 943161 schreef op woensdag 26 juli 2017 @ 17:12:
[...]
Dat heeft dus niets met overnormalisatie of overengineering te maken.

Dit zijn vaak de foute denkwijzes die je bij jonge developers ziet. Pas na een 10 jaar werken en ervaring opdoen, ga je leren waarom normaliseren wél goed is.

Vergelijk het met het beginnen met het gebruiken van een agenda. Jonge mensen zullen ook zeggen dat dat veel te ingewikkeld is, teveel werk, enzovoort. Tot ze (door school) gedwongen worden het een tijdje te doen, en 3 jaar later gaan ze huilen als je ze hun agenda afpakt.

Je gaat compleet voorbij aan het doel van dit project. Natuurlijk moet je normaliseren maar gezien de informatie die we hebben is er echt helemaal niets mis mee om gewoon één tabel te maken met daarin een sensor nummer die niet direct gelinkt is aan een sensor tabel.

Je kan best klein beginnen en het langzaam uitbouwen en zeker als je een beginner bent op dit gebied.

Als het een kritisch project is, vindt ik de keuze voor hosting op z'n NAS een veel groter probleem dan het ontbreken van een aparte sensor tabel....

[gekkie]

Anoniem: 943161 schreef op woensdag 26 juli 2017 @ 17:12:
[...]
Nee, daar is big data dus niet voor. Big data is voor grote niet relationele datasets. Daarom heet het ook big data.

Kortom met mijn:

Big data is min of meer vooraf je (gewenste) relaties niet vooraf kunnen of willen vastleggen.

Ik miste dus vooral woordje "grote" ?
Of wou je beweren dat je bij bigdata nooit relaties bevat ?
Dat zou wonderlijk zijn aangezien de meesten met de verzamelde big data nou net allerlei relaties gaat proberen aan te tonen.

Dit heeft niets met overengineering te maken maar met de basis. Als je op de basis al gaat zitten prutsen, zul je nooit verder komen dan gepruts. Overengineering is een 5e normaalvorm eisen. Dat doe ik niet.

Het heeft in het onderhavige geval van de TS alles met overengineering te maken.

[farlane]

1 Tabel, met een sensor nummer die later een FK zou kunnen worden. Klaar.

Meer dan 1 tabel voorstellen voor de series data hier (of niet afraden) = broddelwerk.

Hobbyprojectes zijn ervoor om dingen te leren, dus ga het aub niet fout aanleren.

[ Voor 4% gewijzigd door farlane op 26-07-2017 17:32 ]

[Anoniem: 943161]

Met alle respect, nu al iets inbouwen wat je later moet omzetten naar FK, dát is fout aanleren.

2 tabellen, 1 voor sensoren, 1 voor sensordata, dát is juist aanleren.

En ja, het kan ook met één tabel. Maar als je dan gaat afvragen of dat juist is, nee dat is het niet.

Het gaat mij helemaal niet om dat hij moet overengineeren of aan industriele standaarden moet houden. Dat is niet aan de orde.

Wat ik probeer te doen, is alvast een goede richting mee te geven. Dus juist aanleren. En je leert meer van het maken van een database met 2 tabelletjes, wat ook gelijk de puristisch juiste manier van opslaan is. Win/Win dus.

Het zal ongetwijfeld zijn dat ik dingen stellig stel en daarmee mensen in de haren strijken die zich daarom geroepen voelen er maar tegenin te blijven gaan, maar komop zeg. Dit is zó basis. Prima als je mij niet mag, ik ben ook een eikel, maar laat dat je adviezen op een forum niet beinvloeden, daar heeft niemand wat aan en door aan de foute kant te gaan staan, verlies je de discussie ook nog eens. Lose/Lose.

[CurlyMo]

Anoniem: 943161 schreef op woensdag 26 juli 2017 @ 17:44:
Met alle respect, nu al iets inbouwen wat je later moet omzetten naar FK, dát is fout aanleren.

Dat heet gewoon iteratief werken

[Anoniem: 943161]

CurlyMo schreef op woensdag 26 juli 2017 @ 17:45:
Dat heet gewoon iteratief werken

In dit geval niet. Een FK als PK in een tabel zetten is niet iteratief werken, maar onjuist werken.

[CurlyMo]

Anoniem: 943161 schreef op woensdag 26 juli 2017 @ 17:48:
[...]


In dit geval niet. Een FK als PK in een tabel zetten is niet iteratief werken, maar onjuist werken.

Er wordt nergens gestelt dat de FK als PK moet dienen. @farlane geeft alleen een suggestie voor een minimale vereiste. Net als de timestamp. Die mist nu ook in het voorbeeld.

Een ander voorbeeld. Stel je hebt data waarbij je het land moet opslaan. De betreffende codes kan je ophalen bij de overheid zoals 6030 voor Nederland. Dat elk land een bepaalde schrijfwijze, afkorting, geldigheidsduur heeft is niet persé nu van belang. Zolang die landcodes maar goed kloppen en consequent worden toegepast, dan kan je er later altijd nog een landentabel naast zetten. Prima manier van iteratief werken.

[gekkie]

Anoniem: 943161 schreef op woensdag 26 juli 2017 @ 17:44:
Met alle respect, nu al iets inbouwen wat je later moet omzetten naar FK, dát is fout aanleren.

2 tabellen, 1 voor sensoren, 1 voor sensordata, dát is juist aanleren.

En ja, het kan ook met één tabel. Maar als je dan gaat afvragen of dat juist is, nee dat is het niet.

Het gaat mij helemaal niet om dat hij moet overengineeren of aan industriele standaarden moet houden. Dat is niet aan de orde.

Wat ik probeer te doen, is alvast een goede richting mee te geven. Dus juist aanleren. En je leert meer van het maken van een database met 2 tabelletjes, wat ook gelijk de puristisch juiste manier van opslaan is. Win/Win dus.

Het zal ongetwijfeld zijn dat ik dingen stellig stel en daarmee mensen in de haren strijken die zich daarom geroepen voelen er maar tegenin te blijven gaan, maar komop zeg. Dit is zó basis. Prima als je mij niet mag, ik ben ook een eikel, maar laat dat je adviezen op een forum niet beinvloeden, daar heeft niemand wat aan en door aan de foute kant te gaan staan, verlies je de discussie ook nog eens. Lose/Lose.

Je kunt ook iemand de kans geven om te leren door eerst een projectje te hebben, vervolgens data te hebben (en een beloningsmoment) en ergens tegen aan te lopen. Vervolgens komt er een leermomentje.

Er gaan in dit geval niets verloren door dat traject te volgen.

Wie nooit een alter table heeft gedaan of zaken later verder genormaliseerd werpe de eerste steen zou ik zo zeggen (TS excluded ).

[Anoniem: 943161]

gekkie schreef op woensdag 26 juli 2017 @ 17:55:
[...]

Je kunt ook iemand de kans geven om te leren door eerst een projectje te hebben, vervolgens data te hebben (en een beloningsmoment) en ergens tegen aan te lopen. Vervolgens komt er een leermomentje.

Er gaan in dit geval niets verloren door dat traject te volgen.

Wie nooit een alter table heeft gedaan of zaken later verder genormaliseerd werpe de eerste steen zou ik zo zeggen (TS excluded ).

Ik heb al 20 jaar geen alter table statements nodig gehad. Goed database-design is een zwaar onderschat iets, dat ten eerste, maar ten tweede, heel kinderachtig, een beetje ORM neemt je dat uit handen

[Anoniem: 943161]

CurlyMo schreef op woensdag 26 juli 2017 @ 17:55:
[...]

Er wordt nergens gestelt dat de FK als PK moet dienen. @farlane geeft alleen een suggestie voor een minimale vereiste. Net als de timestamp. Die mist nu ook in het voorbeeld.

Een ander voorbeeld. Stel je hebt data waarbij je het land moet opslaan. De betreffende codes kan je ophalen bij de overheid zoals 6030 voor Nederland. Dat elk land een bepaalde schrijfwijze, afkorting, geldigheidsduur heeft is niet persé nu van belang. Zolang die landcodes maar goed kloppen en consequent worden toegepast, dan kan je er later altijd nog een landentabel naast zetten. Prima manier van iteratief werken.

Nogmaals, dat is een FK als PK gebruiken en gewoon onjuist.

Ik ben het wél met je eens dat het een pragmatische keuze kan zijn om iets simpel te houden. Ik ben er dan ook niet zozeer op tegen dat TS dat zou doen (sowieso moet ie zelf weten wat ie moet doen) maar hecht er belang bij om wél uit te leggen dát het fout is, en waarom het fout is, inclusief onderbouwing en links naar informatie. Naar mijn mening is TS daarmee gediend.

Laat ik dat voorop stellen; ik begrijp best dat jullie uit de pragmatische hoek komen en als eerste project moet je niet te kritisch zijn. Zijn we het allemaal wel over eens. Net zoals dat een time based database in dit geval waarschijnlijk de meest optimale keuze zou zijn, en dat, als je handig bent, een platte tekstfile óók een goede keuze zou zijn.

[gekkie]

Anoniem: 943161 schreef op woensdag 26 juli 2017 @ 17:56:
[...]


Ik heb al 20 jaar geen alter table statements nodig gehad. Goed database-design is een zwaar onderschat iets, dat ten eerste,

Knap, al jouw projecten zijn van te voren altijd volledig uitgekristaliseerd en behoeven nooit en te nimmer uitbreiding ?

maar ten tweede, heel kinderachtig, een beetje ORM neemt je dat uit handen

Ah je laat alles aan je ORM over .. wat niet weet wat niet deert qua alter tables
Misschien TS dan ook maar een ORM, framework en iets van erlang aanraden, je weet maar nooit wat voor multicore HA oplossing hij in de toekomst nog nodig zou kunnen hebben.

[CurlyMo]

Anoniem: 943161 schreef op woensdag 26 juli 2017 @ 17:59:
[...]
Nogmaals, dat is een FK als PK gebruiken en gewoon onjuist.

De toekomstige PK van een tweede tabel ja, niet van de oorspronkelijke. Daar is niks mis mee.

[CH4OS]

Anoniem: 943161 schreef op woensdag 26 juli 2017 @ 11:42:
Met alle respect, maar tenzij die sensor een ID is welke verwijst naar een andere tabel, is dit slecht design.

code:

sensor
id    naam
1     sensor 1
2     sensor 2

measurements

id  sensor_id  tijd    waarde
1       1            a      b
2       1            c       d
3       2            a       x

Srry ik werk het niet ff zo netjes uit in ascii, maar het is wel duidelijk zo denk ik.

Verder begrijp ik niet helemaal waarom het relationeel zijn van deze data (in de context: welke database gebruik ik?) ter discussie wordt gesteld. Dit is gewoon 100000000000% relationele data.

toon volledige bericht

An sich hoef je voor measurements geen ID te hebben. Voor de terugvindbaarheid is dat eventueel makkelijk, maar een combinatie van sensor_id en timestamp lijken mij ruim voldoende om de waarde te krijgen.

Anoniem: 943161 schreef op woensdag 26 juli 2017 @ 17:56:
Ik heb al 20 jaar geen alter table statements nodig gehad. Goed database-design is een zwaar onderschat iets, dat ten eerste, maar ten tweede, heel kinderachtig, een beetje ORM neemt je dat uit handen

Tja, dan doet de ORM wel het alter table statement voor je, zo kan ik ook wel zeggen dat ik nooit alter table statements gebruik.

[ Voor 19% gewijzigd door CH4OS op 26-07-2017 18:10 ]

[Anoniem: 943161]

gekkie schreef op woensdag 26 juli 2017 @ 18:01:
Knap, al jouw projecten zijn van te voren altijd volledig uitgekristaliseerd en behoeven nooit en te nimmer uitbreiding ?

HEt is hier offtopic, maar wat uitgebreider dan. Doorgaans is je databaseontwerp aan functionaliteit gebonden. Je bouwt wat er nodig is. In de meeste gevallen zijn er dan voor latere uitbreidingen extra tabellen nodig, en geen alter statements.

Voorbeeld dan maar weer, een NAW database. Wat daarin moet, staat wel redelijk vast, er zijn gewoon ISO normeringen voor velden en veldlengtes en types in die situatie. Als je dat gelijk van begin af aan goed opzet, zal er amper tot nooit een alter table op nodig zijn, omdat NAW gegevens nu eenmaal niet van aard veranderen, men gaat niet eens een nog een extra postcode toevoegen ofzo.

Zaken als URL's, mobieltjes, enzovoort, die zorgen dan voor extra tabellen, omdat dat bijna altijd one to many of zelfs many to many relaties zijn.

Dus ja, als je je databases goed ontwerpt, zijn er doorgaans bar weinig alter tables zaken nodig en behelst het meer create tables bij nieuwe functionaliteit.

Ah je laat alles aan je ORM over .. wat niet weet wat niet deert qua alter tables
Misschien TS dan ook maar een ORM, framework en iets van erlang aanraden, je weet maar nooit wat voor multicore HA oplossing hij in de toekomst nog nodig zou kunnen hebben.

Je bent bekend met het concept van een grapje hoop ik?

[The Eagle]

Iedere 15 sec 2 inserts trekt een simpele mysql DB wel.
Ga je een stuk verder, dan kom je al gauw op OpenTSB uit. Daarvoor heb je Hadoop en Hbase nodig. Wil je dat op een synology draaien dan zul je iets met docker (containerization) moeten gaan doen.

Om overigens een discussie plat te slaan: Big Data is een verzamelnaam. Het kan zowel gestructureerde als ongestructureerde data bevatten. Big data kenmerkt zich door een hoog Volume, Variety of Velocity. Van geen van drieen is hier sprake.

[Anoniem: 943161]

The Eagle schreef op woensdag 26 juli 2017 @ 18:07:
Iedere 15 sec 2 inserts trekt een simpele mysql DB wel.
Ga je een stuk verder, dan kom je al gauw op OpenTSB uit. Daarvoor heb je Hadoop en Hbase nodig. Wil je dat op een synology draaien dan zul je iets met docker (containerization) moeten gaan doen.

Ach welnee. Er zijn amper tot geen situaties in NL waar OpenTXB Hadoop en Hbase nodig zijn. Dit forum zou er één van kunnen zijn. MYSQL performed prima, ook met 5k inserts per seconde.

Ik kom in mijn werk veel met performance zaken in aanraking (kwaliteit en performance zijn mijn stokpaardjes, zou je kunnen zeggen) en in zeker 75% van de gevallen komt de slechte performance uit slecht database design, slechte indexen, het niet laten explainen van een query, niet kijken naar wat een query doet, verkeerd itereren in de code, enzovoort.

Om overigens een discussie plat te slaan: Big Data is een verzamelnaam. Het kan zowel gestructureerde als ongestructureerde data bevatten. Big data kenmerkt zich door een hoog Volume, Variety of Velocity. Van geen van drieen is hier sprake.

Big data gaat per definitie over grote datasets. Ongestructureerd zeker, of gestructureerd daar ook onder valt, kun je over discusseren. Het heet niet big data omdat ze dat zo leuk vinden, maar omdat het letterlijk over big datasets gaat. Ik ben er niet van overtuigd dat je voor een grote gerelateerde en vastliggende dataformats, big data nodig hebt. Een NAW database met 5 mlrd records, hoeft NIET in een big data database.

Wil je bv. dingen als hele twitterfeeds importeren, facebook, google links, enz, bv. voor je doelgroepsegmentatie, dat soort zaken, ja dan pak je een van de vele Big Data databases. De meeste ervaring heb ik persoonlijk daarbij met Marklogic, een dure commerciele variant die de meeste mensen niet kennen. Mongo is ook prima.

[ Voor 15% gewijzigd door Anoniem: 943161 op 26-07-2017 18:13 ]

[Kalentum]

Cloud schreef op woensdag 26 juli 2017 @ 14:00:
[...]

Is die standaard wel zo eenvoudig in gebruik? Volgens mij staat die db standaard dicht voor gebruik van buitenaf en kun je dat alleen oplossen door met ssh + root dingen op je Synology aan te passen.

Volgens mij is MariaDB installeren als package op je Synology (eventueel samen met phpMyAdmin) wellicht een iets praktischere manier Al vind ik PostgreSQL wel de mooiere database van die twee.

Ik weet het niet, hangt van de handigheid van TS af. Maar er zijn vrij krap bemeten Synology's (qua geheugen) en dan is een tweede DBMS installeren wellicht wat veelgevraagd.

[Anoniem: 943161]

Ik vermoed dat topicstarter al huilend is weggerend na mijn (en andermans) gezever

[gekkie]

Anoniem: 943161 schreef op woensdag 26 juli 2017 @ 18:15:
Ik vermoed dat topicstarter al huilend is weggerend na mijn (en andermans) gezever

Die heeft C.J Date uit de virtuele kast getrokken en is thans de komende 10 jaar bezig om uit theorie te komen waar die weinig van snapt omdat hij nog nooit live met een tabel met data heeft geklooid .

[u_nix_we_all]

Anoniem: 943161 schreef op woensdag 26 juli 2017 @ 18:15:
Ik vermoed dat topicstarter al huilend is weggerend na mijn (en andermans) gezever

Ik denk het ook. Als hij slim is laat hij de hele discussie voor wat het is en dan lekker met rrdtool aan de gang. Was al genoemd door @anboni , en lijkt mij perfect voor deze klus, alleen helemaal niemand die daarop reageerde.

De goede tips sneeuwen onder door een veel te diepgravende, nog-net-niet-offtopic discussie IMHO.

[incaz]

Anoniem: 943161 schreef op woensdag 26 juli 2017 @ 18:07:
HEt is hier offtopic, maar wat uitgebreider dan. Doorgaans is je databaseontwerp aan functionaliteit gebonden. Je bouwt wat er nodig is. In de meeste gevallen zijn er dan voor latere uitbreidingen extra tabellen nodig, en geen alter statements.

Dat kan ik echt niet beamen hoor. Het toevoegen van velden aan datatypes (/kolommen aan bestaande tabellen) is echt wel iets wat veel voorkomt, juist omdat functionaliteit zich uitbreidt. Een deel daarvan gaat via nieuwe one-to-many relations, maar veel is ook gewoon een aanpassing en uitbreiding van de bestaande types.

Zaken als URL's, mobieltjes, enzovoort, die zorgen dan voor extra tabellen, omdat dat bijna altijd one to many of zelfs many to many relaties zijn.

Juist contactopties zijn volgens mij een goed voorbeeld waar EAV wel geschikt voor is. En denk ik dat je vaak juist geen many-to-many wilt hebben, zelfs niet als je meerdere keren hetzelfde telefoonnummer op zou geven, omdat het lang niet altijd betekent dat als het nummer op de ene plek wijzigt, het ook op alle plekken gewijzigd mag worden. (Zo wel, dan zal dit meestal verlopen via een tussenpersoon-entiteit/tabel. Maar dus niet slechts een many-to-many-koppeltabel.)

[gekkie]

u_nix_we_all schreef op woensdag 26 juli 2017 @ 18:24:
[...]

Ik denk het ook. Als hij slim is laat hij de hele discussie voor wat het is en dan lekker met rrdtool aan de gang. Was al genoemd door @anboni , en lijkt mij perfect voor deze klus, alleen helemaal niemand die daarop reageerde.

De goede tips sneeuwen onder door een veel te diepgravende, nog-net-niet-offtopic discussie IMHO.

Hangt er een beetje vanaf of het acceptabel is dat de data vanaf een bepaald moment geaggregeerd wordt.
Voordeel van RRD is dat je dat inderdaad bij het aanmaken van je DB definieerd en vervolgens ben je er vanaf en hoef je zelf geen aggregatie functies meer te proggen. Benodige storage wordt ook gelijk vastgelegd en gereserveerd kan ook een voordeel zijn van "least surprises".
En zal prima op een synology kunnen draaien en er zullen vast opkg's voor zijn (in tegenstelling tot andere timeserie DB's). Het is een SQL DB wel een stuk flexibeler en is het bij rrd zeker noodzakelijk om goed na te denken over wat je nodig hebt alvorens je de DB aanmaakt.

Elk voordeel heb z'n nadeel zij een groot Neerlands wijsgeer ooit ... of was het nou omgekeerd .. ach in dit geval beide geldig .

[ Voor 26% gewijzigd door gekkie op 26-07-2017 18:34 ]