Ci sono molte altre condizioni di cui ho sentito parlare con i sistemi non relazionali rispetto a quelli relazionali. Preferisco questa terminologia su sql/no-sql poiché personalmente penso che descriva meglio le differenze e molti dei server "no-sql" hanno componenti aggiuntivi sql, quindi comunque ... che tipo di modello di concorrenza o isolamento della transazione è richiesto nel tuo sistema. Una delle presunte differenze tra rel e non-rel dbs è "coerente-sempre", "coerente-per lo più" o "coerente-eventualmente". Relation dbs per impostazione predefinita di solito rientra nella categoria "per lo più consistente" e con un po' di lavoro e un sacco di condizioni di blocco e di gara,;) può essere "sempre coerente", quindi tutti cercano sempre la rappresentazione più corretta di un dato dato. La maggior parte di ciò che ho letto/sentito sui db non rel è che sono principalmente "alla fine coerenti". Con questo significa che potrebbero esserci molte istanze dei nostri dati in giro, quindi l'utente "A" potrebbe vedere che abbiamo 92 widget nell'inventario, mentre l'utente "B" potrebbe vederne 79 e potrebbero non essere riconciliati finché qualcuno non se ne va effettivamente per ritirare roba dal magazzino. Un altro problema è la mutabilità dei dati, con quale frequenza è necessario aggiornarli? I particolari db non rel a cui sono stato esposto hanno un sovraccarico per gli aggiornamenti, alcuni dei quali devono rigenerare l'intero set di dati per incorporare eventuali aggiornamenti.
Ora attenzione, penso che non rel/nosql siano ottimi strumenti se corrispondono davvero al tuo caso d'uso. Ne ho diversi che sto esaminando ora per i progetti che ho. Ma devi considerare tutti i compromessi quando prendi la decisione, altrimenti si trasforma semplicemente in uno sviluppo più guidato dal curriculum.
