Web-1/Server database

Uit Inf2019
< Web-1
Versie door Eelco (overleg | bijdragen) op 7 nov 2017 om 22:51 (1 versie geïmporteerd)
Naar navigatie springen Naar zoeken springen
Web1
Netwerken

Zie ook Regels en richtlijnen
Zie ook Artikelen bewerken

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.

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.