Alle bedrijven slaan gegevens op van een eenvoudig dossierboek van een klein bedrijf, misschien zelfs in een dagboek of een stuk
papier tot enorme bedrijven zoals Amazon die computers nodig hebben om petabytes aan gegevens op te slaan.
Om deze informatie op te slaan, heeft vrijwel elk bedrijf en soms ook individuen iets nodig dat een
database wordt genoemd.
We zagen in de laatste sectie hoe moeilijk het was om onze server een nieuwe gebruiker te laten onthouden.
Elke keer dat de server crashte, wordt de variabele gereset en dan zou het helemaal opnieuw beginnen.
Of als we een login of een teken willen doen en de e-mails en wachtwoorden willen controleren en herhalen, een
lus door JavaScript maken, dat is inefficiënt.
Dat is waar database te hulp komt.
Dus laten we ons afvragen, wat is een database?
Een database is een verzameling gegevens.
En wat we bedoelen met gegevens, er zijn vele vormen van, juist, er kunnen cijfers
zijn, er kunnen datums zijn, er kunnen wachtwoordhashes zijn, er kunnen gebruikersinformatie zijn.
Databases stellen ons in staat om deze gegevens te ordenen op een manier die voor ons nuttig is, en het maakt het gegevensbeheer
eenvoudig.
En daar kwam iets uit, en het heet Database Management System, of kortweg DBMS.
Het is een verzameling programma's waarmee we toegang hebben tot databases en met gegevens kunnen werken,
en het biedt ook controletoegang voor databasegebruikers.
Dus een DBMS is iets in deze box.
Iets dat ons een hulpmiddel geeft, een stukje software waarmee we kunnen communiceren.
Met de database slaat informatie op die nuttig is voor ons en waarmee we ook kunnen bijwerken, invoegen, verwijderen, opzoeken, wat er ook in
de database staat, en dit idee van een DBMS begon echt vorm te krijgen in de jaren zestig en nu staat het
in de voorhoede van veel spannende dingen.
Er is een hele industrie van ingenieurs die gewoon met databases werken omdat het zo belangrijk is.
Nu zijn er twee soorten DBMS die op dit moment erg populair zijn en waar we het in deze cursus over
zullen hebben.
En deze twee typen worden heel goed weergegeven door postscripts en Mongo DB.
Laten we het hebben over de eerste, de relationele database.
En dit is waarschijnlijk de meest populaire.
Zoals je aan de rechterkant kunt zien.
Je ziet dat dit allemaal relationele databases zijn, postgraduaat Oracle, SQL Server.
Je hebt misschien gehoord van MySQL, Escorial Lite.
Dit zijn allemaal soorten databases die deze relationele databasetag hebben, en het mooie is dat ze allemaal vrij
veel op elkaar lijken.
Ze volgen allemaal hetzelfde standaardformaat.
Relationele databases bestaan uit twee of meer tabellen met kolommen en rijen.
Dus in dit geval is gebruikers een tabel en volledige naam, gebruikersnaamtekst gemaakt in onze kolommen en alle waarden
die ze hier hebben, zijn rijen.
Elke rij vertegenwoordigt een item in elke kolom.
Het is dus een heel specifiek type informatie, zoals naam, adres of telefoonnummers.
En dan de relatie tussen tabellen en veld.
Het wordt een schema genoemd in een relationele database, het schema moet duidelijk worden gedefinieerd voordat er informatie kan worden
toegevoegd.
En als dit op dit moment verwarrend is, maak je geen zorgen, we gaan deze databases echt maken, dus het
is logisch voor jou.
Als we bijvoorbeeld Twitter hadden, kun je hier zien welke soorten tabellen we zouden hebben en hoe we het
zouden organiseren.
We zouden een gebruikersstal hebben, een tweettabel, een volgende tabel.
En we kunnen al deze informatie met elkaar verbinden, bijvoorbeeld door verschillende delen van de tafel met elkaar te verbinden.
De gebruikersnaam zal bijvoorbeeld hetzelfde zijn in de gebruikerstabel als in de tweetstabel.
Op die manier kunnen we zeggen dat de gebruikersnaam en de tweetstabel de refererende sleutel is van de gebruikersnaam in de
gebruikerstabel en vervolgens van gebruiker.
Wordt de refererende sleutel van de gebruikersnaam in de volgende tabel.
Nu, zaken als de volledige naam of ID, iets dat elke rij in een tabel identificeert, wordt een primaire sleutel genoemd en we zullen
dat later in de sectie bespreken.
Oké, dus al deze databases die we gaan leren over postcrisis cual, maar ze zijn allemaal ongeveer
hetzelfde.
Dus als je er één kent, is het vrij eenvoudig om de andere op te pikken.
Hoe communiceren ze eigenlijk met een server met de back-end?
Welnu, alle relationele databases gebruiken iets dat obscure wordt genoemd.
En vraag jullie allemaal stelt ons in staat om te communiceren, net zoals HTP deed tussen de front-end
en de back-end, waarbij jullie allemaal konden communiceren met de database en konden wijzigen of ophalen of bijwerken zoals we wilden.
En we hebben ook een video over dit onderwerp.
Oke.
Dus dat zijn relationele databases.
Hoe zit het met de tweede soort?
Het tweede type wordt een niet-relationele database of een ESKIL-database genoemd, en nogmaals, er zijn heel veel verschillende soorten
databases met een aantal coole namen zoals Kotb en Hyper Table.
Nu kunt u met een Mongo DB of een niet-relationele database een toepassing bouwen zonder dat u eerst het
schema hoeft te definiëren, in tegenstelling tot een relationele database.
Als we teruggaan naar de relationele database, moeten dit schema of deze tabellen een beetje vooraf gedefinieerd zijn, toch?
We moeten weten hoe onze app eruit gaat zien, deze tabellen maken zodat zodra de app openbaar is,
we gebruikersinformatie en tweets en volgers kunnen invoeren.
Zonder excuus of niet-relationele database, kunnen we het gewoon definiëren als we gaan en ze hebben allemaal verschillende manieren om
deze informatie op te slaan.
Dus elk is heel, heel anders.
En dit is nog een belangrijke reden om een niet-relationele database te gebruiken. Als uw gegevensvereisten
aan het begin van uw project niet duidelijk zijn en u misschien een enorme hoeveelheid ongestructureerde gegevens hebt, heeft
u misschien niet de luxe om een relationele database te ontwikkelen. database met een duidelijk gedefinieerd schema.
Ze bieden in plaats daarvan een grotere flexibiliteit doordat een niet-relationele database meer op mappen lijkt en alleen
gerelateerde informatie van alle soorten verzamelt.
Nu is Mongo DB iets dat documentgeoriënteerd wordt genoemd, het slaat informatie op als documenten.
Laat me dit punt voor u illustreren.
Ik heb hier mijn bureaublad met twee mappen.
Een daarvan is een echt relationele database en hier hebben gebruikers tweets, profiel volgen.
En je kunt relationele databases bedenken met dit type opslag waar deze map ergens op een computer staat die
deze informatie opslaat, en elke keer dat we een database ergens om moeten vragen, pakken
we de gebruikers.
En als we ook de tweets van de gebruiker willen pakken, vinden we de gebruiker waarin we geïnteresseerd
zijn, en dan de tweets van de gebruiker waarin we ook geïnteresseerd zijn met de externe sleutel die naar de gebruikers linkt.
En we kunnen ook vinden hoeveel volgers die gebruiker heeft.
We pakken die informatie op en geven deze weer in onze web-app.
Mongo DB daarentegen zal elke gebruiker als een document hebben.
Dus als ik de eerste gebruiker wilde pakken, nou, ik pakte gewoon dit document en het heeft
alle volgers, de tweets, het profiel, alles staat in dit ene document.
En je zou kunnen denken dat Mongo DB een betere keuze lijkt dan dit te hebben.
Manier om dingen goed te doen.
Nou, het hangt af van uw behoefte, en daarom is databases zo'n complex onderwerp.
Het hangt echt heel erg van je situatie af.
Je kunt zien dat deze Mongo DB-manier erg handig is als je zoiets als een profiel hebt, misschien een
LinkedIn-profiel.
Maar als je iets nodig hebt waar je werkt met alleen het volgen van gegevens of alleen tweetgegevens,
misschien wil je bij de tweets zien wat de gemiddelde tweetgrootte is?
Welnu, het is heel eenvoudig om dit bestand te pakken en dat te berekenen versus op deze manier waar je
het misschien van elk van de gebruikers moet extraheren.
Het hangt dus echt af van uw behoeften.
Laat me je een ander diagram laten zien dat dat zou kunnen zijn.
Bruikbaar.
Als we kijken naar relationele versus niet-relationele databases, kun je denken aan relationeel, aangezien elke tabel
een blogpost, een blogtag, een blogcommentaar heeft en deze tabellen koppelt om je de bloginformatie te geven versus
een niet-relationele die dit geheel opslaat. blogpost in een item en heeft opmerkingen, belastingcategorieën en alle
andere gerelateerde gegevens op één plek.
Dus wat gebruikt Mongo DB om te communiceren?
Als we teruggaan naar ons voorbeeld hier, hadden we jullie allemaal gevraagd om relationele databases zoals postcrisis of
Mongo.
DB heeft zijn eigen wat we querytaal noemen, en het is gewoon de Mongo DB-querytaal.
Maar ze willen allebei hetzelfde doen, namelijk communiceren met de database, een gemakkelijke
manier bieden voor de server om met de database te communiceren.
En in deze sectie gaan we het daarover hebben en we gaan eindelijk de punten met elkaar verbinden en
je de kracht van databases laten zien zodra ze zijn verbonden met een server.
Ik zie je in de volgende.