Web-1/Server database: verschil tussen versies
k (Eelco heeft de pagina Web1/Server database hernoemd naar Web-1/Server database zonder een doorverwijzing achter te laten) |
|
(Een tussenliggende versie door dezelfde gebruiker niet weergegeven) | |
(geen verschil)
|
Huidige versie van 18 jan 2018 om 19:54
Inleiding
We hebben in een eerder hoofdstuk gebruik gemaakt van de NodeRed-contexten, voor het bijhouden van de server state. Een nadeel hiervan is dat deze toestand niet bewaard blijft als je NodeRed opnieuw opstart: deze contexten zijn niet persistent. Vormen van persistente opslag zijn het filesysteem en databases. In NodeRed kun je gegevens opslaan in het filesysteem: voor eenvoudige data (logfiles) kan dat een handige oplossing zijn, maar voor meer complexe data is een database vaak handiger. In dit hoofdstuk gebruiken we MongoDB als database-systeem. MongoDB biedt zogenaamde "document databases"; een document komt hierbij ongeveer overeen met een JavaScript-object zonder verwijzingen naar andere gemeenschappelijke JavaScript-objecten. Een document-database is een voorbeeld van een NoSQL-database.
In dit hoofdstuk behandelen we eerst een paar flows om met een database te experimenteren. Daarna gebruiken we MongoDB voor het opslaan van de gegevens van de gebruikers - in dit geval, de gebruikers en hun woonplaats.
MongoDB en het Internet of Things
Voor het IoT stel je andere eisen aan een database dan in het geval van traditionele toepassingen:
- sensor-data worden altijd toegevoegd aan de database; er worden geen gegevens bijgewerkt (er zijn geen updates nodig);
- omdat er geen updates nodig zijn, speelt redundantie een minder belangrijke rol dan in het geval van traditionele toepassingen.
- je moet eventueel wel snel kunnen zoeken in de database.
- sensordata hebben een eenvoudige structuur.
MongoDB
Als database gebruiken we MongoDB. Deze is eenvoudig in het gebruik; dit is geen SQL database, maar een "NoSQL" database. (MongoDB wordt ook wel een Document Database genoemd.)
We testen eerst de database.
- debug-node voor de output
Er zijn twee nodes:
- in: voor het opslaan van gegevens
- in-out: voor het opzoeken van gegevens (query). De input is de query voor de database.
- vooraf: installeren van MongoDB
- Cloud9: https://community.c9.io/t/setting-up-mongodb/1717
- opstarten van mongodb (moet steeds "met de hand"?): ./mongod (in aparte terminal, net als nodered)
Configureren van de database-node(s):
- kennelijk werkt 127.0.0.1 (ik weet ook niet hoe je anders het ip-adres zou moeten opgeven...)
Queries:
- kennelijk moet msg.limit gezet zijn, anders werkt de query (in-out node) niet.
- daarvoor heb je een functie (of een change-node) nodig.
mogelijke opdrachten
- database van gebruikers; per gebruiker een voorkeur bijhouden; mogelijk, wanneer deze ingelogd heeft; of, een motto (dat je steeds laat zien); of, de woonplaats - om het weer van die plek te laten zien.
- de woonplaats lijkt mij de handigste keuze; deze kunnen we dan in de volgende stap gebruiken om het weer in die plaats op te vragen.
- stap verder: bijhouden van een blog
- aanmaken van een nieuwe blog (via een tekst-blok)
- editen van een eerdere blog (bijv. door selecteren uit een lijst van blogs?)
- ophalen van meest recente blog (-> we hebben datum/tijd nodig)
- ophalen van alle blog(titels)
- een stap verder: formatteren van blog met markdown
- keuze: (i) server-side; (ii) client-side (dan moeten we eerst AJAX behandelen); (iii) uitbesteden aan een andere server (service)
Opmerkingen
- in de eenvoudige versie, voegen we de inhoud van het formulier gewoon toe aan de database; we houden geen rekening met gebruikers die zich eerder aangemeld hebben. Dit ligt aan de knoop die we gebruiken. Voor IoT-toepassingen is dit vaak voldoende: je voegt sensordata gewoon toe aan de database, je verandert geen eerder gegeven
- in een meer geavanceerde versie zorgen we dat een gebruiker maar 1 keer toegevoegd wordt; we zoeken de gegevens van de gebruiker (woonplaats) op aan de hand van de naam van de gebruiker.
- we hebben dan een andere node nodig; en we hebben mogelijk een twee-staps proces nodig, waarbij we eerst controleren of we al gegevens van deze gebruiker in de database hebben.