Er zijn veel andere aandoeningen waarover ik heb gehoord met niet-relationele systemen versus relationele. Ik geef de voorkeur aan deze terminologie boven sql/no-sql, omdat ik persoonlijk denk dat het de verschillen beter beschrijft, en verschillende van de "no-sql" -servers hebben sql-add-ons, dus hoe dan ook ... wat voor soort gelijktijdigheidspatroon of transactie-isolatie is vereist in uw systeem. Een van de vermeende verschillen tussen rel en niet-rel dbs is de "consistent-altijd", "consistent-meestal" of "consistent-uiteindelijk". Relatie dbs valt standaard in de categorie "consistent-meestal" en met wat werk, en een heleboel vergrendelings- en racevoorwaarden;) kan "consistent-altijd" zijn, dus iedereen kijkt altijd naar de meest correcte weergave van een gegeven gegeven. Het meeste van wat ik heb gelezen/gehoord over non-rel dbs is dat ze voornamelijk "consistent-uiteindelijk" zijn. Dit betekent dat er veel exemplaren van onze gegevens kunnen rondzweven, dus gebruiker "A" kan zien dat we 92 widgets in de inventaris hebben, terwijl gebruiker "B" er 79 kan zien, en ze worden mogelijk niet verzoend totdat iemand daadwerkelijk gaat spullen uit het magazijn halen. Een ander probleem is de veranderlijkheid van gegevens, hoe vaak moeten deze worden bijgewerkt? De specifieke niet-rel db's waaraan ik ben blootgesteld, hebben meer overhead voor updates, waarvan sommige de hele dataset opnieuw moeten genereren om eventuele updates op te nemen.
Let wel, ik denk dat non-rel/nosql geweldige tools zijn als ze echt passen bij je gebruiksscenario. Ik heb er een aantal waar ik nu naar aan het kijken ben voor projecten die ik heb. Maar je moet bij het nemen van de beslissing naar alle compromissen kijken, anders wordt het gewoon een meer cv-gestuurde ontwikkeling.