Eventualmente coerenza significa che le modifiche richiedono tempo per propagarsi e che i dati potrebbero non essere nello stesso stato dopo ogni azione, anche per azioni identiche o trasformazioni dei dati. Ciò può causare cose molto brutte quando le persone non sanno cosa stanno facendo quando interagiscono con un tale sistema.
Si prega di non implementare archivi di dati aziendali critici fino a quando non si comprende bene questo concetto. Il rovinare l'implementazione di un archivio dati di documenti è molto più difficile da correggere rispetto a un modello relazionale perché le cose fondamentali che verranno rovinate semplicemente non possono essere riparate in quanto le cose necessarie per risolverlo non sono presenti nell'ecosistema. Il refactoring dei dati di un negozio in volo è anche molto più difficile delle semplici trasformazioni ETL di un RDBMS.
Non tutti gli archivi di documenti sono creati uguali. Alcuni in questi giorni (MongoDB) supportano transazioni di un tipo, ma la migrazione dei datastore è probabilmente paragonabile alle spese di reimplementazione.
ATTENZIONE: gli sviluppatori e persino gli architetti che non conoscono o comprendono la tecnologia di un archivio di dati documentali e hanno paura di ammetterlo per paura di perdere il lavoro, ma sono stati formati in modo classico in RDBMS e che conoscono solo i sistemi ACID (quanto può essere diverso ?) e chi non conosce la tecnologia o non si prende il tempo per impararla, mancherà progettare un archivio di dati di documenti. Potrebbero anche provare a usarlo come RDBMS o per cose come la memorizzazione nella cache. Abbatteranno quelle che dovrebbero essere le transazioni atomiche che dovrebbero operare su un intero documento in pezzi "relazionali" dimenticando che la replica e la latenza sono cose, o peggio ancora, trascinando sistemi di terze parti in una "transazione". Lo faranno in modo che il loro RDBMS possa rispecchiare il loro lago di dati, indipendentemente dal fatto che funzionerà o meno, e senza test, perché sanno cosa stanno facendo. Quindi agiranno sorpresi quando gli oggetti complessi memorizzati in documenti separati come "ordini" hanno meno "articoli ordine" del previsto, o forse nessuno. Ma non succederà spesso, o abbastanza spesso, quindi avanzeranno. Potrebbero anche non colpire il problema in fase di sviluppo. Quindi, anziché riprogettare le cose, genereranno "ritardi", "tentativi" e "controlli" per falsificare un modello di dati relazionali, che non funzionerà, ma aggiungerà ulteriore complessità senza alcun vantaggio. Ma ormai è troppo tardi: la cosa è stata implementata e ora l'azienda ci sta lavorando. Alla fine, l'intero sistema verrà espulso e il dipartimento sarà esternalizzato e qualcun altro lo manterrà. Non funzionerà ancora correttamente, ma possono fallire in modo meno costoso rispetto al fallimento attuale.
