Web-1/Server database: verschil tussen versies

Uit Inf2019
Naar navigatie springen Naar zoeken springen
k (1 versie geïmporteerd)
k (Eelco heeft de pagina Web1/Server database hernoemd naar Web-1/Server database zonder een doorverwijzing achter te laten)
 
(geen verschil)

Huidige versie van 18 jan 2018 om 19:54

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.