In principe kijk je naar wat nodig is en pas je daar je gereedschappen op aan.

In de praktijk blijken nogal veel mensen niet te snappen waarom SQL een goed idee is en pakken ze iets dat niet past, onegacht welk "kamp" ze het uit halen. Maar in het bijzonder valt nogal veel NoSQL-inzet daaronder, omdat je daar vaak minder harde garanties krijgt. Die vaak bewust losgelaten zijn om snelheid of "schaal" te winnen. Ook een pluspunt van "SQL": Het is gebouwd met de ideën van relationele algebra. Zo'n wiskundige grondslag heeft op zichzelf al vele voordelen, en "NoSQL" heeft dat niet eenduidig te bieden.

Dus ik heb zoiets van, als je het niet zeker weet pak dan een goede SQL-RDBMS. En oh ja, zorg dat je weet wat SQL je te bieden heeft. Zodat je tenminste de compromissen snapt. Je kan altijd nog een NoSQL pakken als dat nodig blijkt, en dan heb je gelijk zoveel incompatible keuze dat je echt heel goed moet weten waar je mee bezig bent wil je nog een redelijke afweging kunnen maken. Met "SQL" heb je dat probleem minder. Ook al kost het snappen van wat je echt aan SQL hebt al snel een semester, en wat de kosten en baten van NoSQL zijn al snel nog meer tijd daarbovenop.

Begin maar eens met je data-toegang te beschrijven. Hoeveel lees- en schrijfoperaties, mutaties, etc. per tijdseenheid? Of in ieder geval, zijn het er veel meer van een type dan een ander type? Hoeveel structuur heb je nodig, hoe ingewikkeld hangt je data aanelkaar? Verwijst het allemaal naarelkaar of zijn het losse ongerelateerde stukjes? Als je één ding wijzigt, moet dan gelijk iets anders meewijzigen, of hoeft dat niet? Hoe schadelijk is het als er perongeluk iets niet of niet volledig gewijzigd wordt en er dus onderlinge samenhang verloren gaat of zelfs een incorrect plaatje ontstaat? En zo verder.

Schrijf hoe je je data benaderd maar rustig een keertje op, en dan rolt er vanzelf een idee uit van wat je nodig hebt. En dan kun je daar geschikte gereedschappen bij gaan zoeken.

PHP-SQL en meer is er niet, is net zo simpel als echt geloven dat Facebook het hele internet is. Of Google.

Dat krijg je met al die bijles diploma's van tegenwoordig.

Veel lekken en veel updates. En het geloof dat dat ook normaal is.

HODOR

De correcte uitleg van nosql is not only sql.
Dataverwerking is meer dan wat sql statements.

Er wordt bedoeld het relationele database model. SQL is slechts een taal om daar mee te praten.

Geen idee. Als 'ie het maar doet.

Dat is bullshit. "Not only SQL" wordt wel eens geroepen maar is niet "de correcte uitleg van NoSQL"

"SQL" doet heel wat meer dan "wat statements verwerken".

Bijvoorbeeld, zoek op wat het acronym "ACID" betekent in de context van "SQL". "NoSQL" gooit vaak een of meerdere letters overboord om daarvoor andere, dus belangrijker gehouden, voordelen voor terug te krijgen. Of ze laten het complete relationele deel varen en doen alleen nog maar aan "document store" of "key/value store". Dat doen ze met een reden, maar dat wil niet zeggen dat de redenen waarom "SQL" uitgevonden is ineens niet meer gelden.

"SQL" is een verzameling database-management-systemen met een min of meer gemeenschappelijke featureset. "NoSQL" is alles dat ook "database management" zegt te doen maar dan het keurslijf van "SQL" achter zich latend. Een vreselijk heterogene verzameling.

Het maakt dus minder uit of je deze of een andere een SQL-RDBMS pakt dan of je de ene of de andere "NoSQL" pakt, want de kans dat de featuresets een beetje overeenkomen of dat ze een beetje hetzelfde werken is bij "SQL" veel groter dan bij "NoSQL".


Het probleem hier is dat "het doen" en "goed op je data passen" verschillende dingen zijn. Er zijn zelfs veelgebruikte SQL-"database systemen" die het maar verdomde lastig vinden om aan alle letters van ACID te voldoen, en dan kan'ie het prima (lijken te) doen maar dan kunnen er nog steeds hele rare dingen met je data gebeuren.

Het is dan ook niet makkelijk, en dat klopt want het is geen makkelijk probleem. Maar het betekent wel dat als je wil dat'ie het "gewoon doet" je een specialist nodig hebt die voor je regelt "dat'ie het maar doet". Zelfs veel programmeurs die soms zelfs dagelijks met databases werken hebben hier eigenlijk niet genoeg kennis in huis. Meestal lijkt het allemaal prima te gaan zolang er geen rare dingen gebeuren, maar dat is niet hetzelfde als goed werken.

Wat betekent HODOR?

Dat je niet snapt wat google doet.

Alweer? Nou, vooruit dan maar. Om het af te leren: HODOR!

Dat is iets van de serie game of thrones. blijkbaar is een medewerker van security.nl een GoT fan?

https://www.tottadatalab.nl/2017/10/11/wat-betekent-nosql/

Wat is NoSQL?

NoSQL is een verzamelnaam voor heel veel verschillende databases waar niet echt een overeenkomst tussen is. Een belangrijke overeenkomst is dat al deze databasemanagementsystemen op aanmerkelijke wijze verschillen van de klassieke relationele databases (RDBMS). NoSQL databases kunnen extreem grote hoeveelheden data verwerken, ook wel big data genoemd. Bovendien hoeft deze data van tevoren geen (semi)structuur te hebben.
Wat betekent NoSQL?

Wat opvalt, is dat de term NoSQL vaak niet goed wordt begrepen. Door het ‘no-gedeelte’ binnen dit woord, suggereert de term dat het NO SQL betekent (vertaling: GEEN traditionele database waarin men de Structured Query Language (SQL) gebruikt). Het staat echter niet voor ‘NO SQL’, maar voor ‘Not Only SQL’. Hiermee wordt bedoeld dat er meer dan één opslagmechanisme kan worden gebruikt voor de nodige behoeftes. NoSQL zit tussen SQL en Hadoop in. Bij SQL moet je structuur aanbrengen, bij Hadoop juist niet en NoSQL zit er ergens tussenin. We leven nu eenmaal niet meer in een tijdperk met one-size-fits-all databases, en dat is ook helemaal niet problematisch. NoSQL en SQL databases zijn geen concurrenten, aangezien ze allebei voor compleet andere doeleinden worden gebruikt.
De voordelen van NoSQL ten opzichte van SQL

De traditionele database SQL kent z’n voordelen, maar de NoSQL databases ook zeker:

Je hoeft de data van tevoren niet te modelleren en overzichtelijk te maken. NoSQL databases zijn ontzettend flexibel en kunnen alle soorten en maten data aan. Daarom stellen ze weinig eisen aan de organisatie en de structuur van de data.
Deze databases kunnen goed omgaan met big data.
Ze zijn goedkoper om te managen, omdat er simpelweg weinig te managen valt.
NoSQL databases zijn horizontaal schaalbaar. Dit betekent dat de data kan opgesplitst worden op diverse servers, wat de responstijd verhoogt. Schalen is ontzettend belangrijk, omdat de hoeveelheid data steeds blijft groeien.
Deze databases zijn eenvoudiger te gebruiken en heel simpel wat betreft design.
NoSQL komt voor in de vorm van kolommen, documenten, key-values, grafieken en multimodellen. Je kunt er dus letterlijk alle data in stoppen.

De nadelen

Eén groot nadeel van de NoSQL databases is de onnauwkeurigheid. Als het gaat om miljoenen gebeurtenissen in korte tijd, kun je prima kiezen voor dit type database. Het missen van enkele gebeurtenissen is in dit geval geen probleem. Dit stelt je in staat om de data schaalbaar te maken, wat uiteindelijk tijd- en kostenbesparend kan werken. Bij relationele databases zijn deze grote gegevens juist niet handig, en zijn kleine gegevens de beste input. Bij relationele databases gaat kwaliteit namelijk boven de kwantiteit en bij NoSQL databases is dit precies andersom.
What about the future?

Het is niet zo gek dat relationele databases eerst de standaard waren. Bij dit model stond de opbouw en de organisatie van de database los van de manier van opslag. Relationele databases bestaan al sinds de jaren 60 en zijn altijd overheersend geweest, totdat platformen zoals Facebook en Google werden gelanceerd. De hoeveelheid data was ineens enorm en relationele databases konden deze hoeveelheid data niet verwerken. De dominantie van relationele databases is dus aanzienlijk verminderd. Maar je weet het maar nooit in ons datatijdperk wat er later gaat gebeuren. Dit hangt ook compleet af van het soort data dat er de komende jaren bij gaat komen, en dit is heel onvoorspelbaar…

Hodor: intra-process isolation for high-throughput data plane libraries

Ik wacht wel op NoNoSQL

27% stemmen op het ene uiterste en 6% op het andere. m.i. is dit een van de minder zinvolle polls op deze site.

Dit is een stuk slinkse marketeering van het type "jamaar pentium heeft dan een CISC-instructieset, er zit een RISC-instructieset onder verborgen, hoor!" en dat heeft wel bijgedragen aan het kapotmaken van de RISC-processormarkt, maar heeft ons niet verlost van de limitaties van x86.

Klopt ook niet met de latere opmerking in hetzelfde stuk dat "SQL" en "NoSQL" elkaar niet in de weg zouden zitten. Hoezo wil "NoSQL" dan nog een superset van SQL zijn ("Not Only")?

Als je een verzameling onderling steekhoudende gestructureerde data wil bijhouden, heb je een RDBMS nodig. Wil je andere dingen, dan zoek je daar andere gereedschappen bij. Maar het helpt wel als je goed doorhebt wat je gereedschappen voor je kunnen doen en welke garanties ze je geven. "SQL" zit aan het stricte einde van het spectrum en als het goed is lost het niet alleen lastige problemen op, het geeft je er ook harde garanties over. Dat doet "NoSQL" minder of zelfs niet, dus volhouden dat het eigenlijk "Not Only SQL" betekent zet je makkelijk op het verkeerde been. Het doet juist allerlei dingen niet die je wel van een SQL RDBMS verwacht.

Het doet andere dingen dan weer wel. Dingen die passen bij "data lakes", "webscale", en meer van die buzzwords. Dingen waar de garanties van een RDBMS onnodig zijn en daarom de boel nodeloos ophouden, want zulke features zijn niet gratis. Dus vraag je zelf eerst eens, hoe erg is het als er eens wat gegevens kwijtraken? En ook, natuurlijk, hoe gehaast ben je?

"Hadoop", in het stuk gepresenteerd als het andere extremum van het "strictheidsspectrum" van data-opslag is een manier om stukjes code los te laten op een enorme databrij, wat simpel klinkt totdat je bedenkt dat het ook het opknippen van je databrij en verdelen van het werk over heel veel computers doet. Dat is dus niet eens meer een database. Daarmee zeer beperkt van nut als je een database nodig hebt, maar mischien wel nuttig om een database te vullen.