Ostatecznie spójność oznacza, że propagacja zmian wymaga czasu, a dane mogą nie być w tym samym stanie po każdym działaniu, nawet w przypadku identycznych działań lub transformacji danych. Może to spowodować bardzo złe rzeczy, gdy ludzie nie wiedzą, co robią podczas interakcji z takim systemem.
Nie wdrażaj magazynów danych dokumentów o znaczeniu krytycznym, dopóki dobrze nie zrozumiesz tej koncepcji. Zepsucie implementacji magazynu danych dokumentu jest znacznie trudniejsze do naprawienia niż model relacyjny, ponieważ podstawowych rzeczy, które mają zostać schrzanione, po prostu nie można naprawić, ponieważ rzeczy, które są wymagane, aby to naprawić, po prostu nie występują w ekosystemie. Refaktoryzacja danych magazynu pokładowego jest również znacznie trudniejsza niż proste przekształcenia ETL w RDBMS.
Nie wszystkie magazyny dokumentów są takie same. Niektóre obecnie (MongoDB) obsługują pewnego rodzaju transakcje, ale migracja magazynów danych jest prawdopodobnie porównywalna z kosztem ponownej implementacji.
OSTRZEŻENIE: Programiści, a nawet architekci, którzy nie znają lub nie rozumieją technologii przechowywania danych dokumentów i boją się przyznać, że z obawy przed utratą pracy, ale zostali klasycznie przeszkoleni w zakresie RDBMS i znają tylko systemy ACID (jak bardzo może to być ?), a kto nie zna technologii lub nie ma czasu, aby się jej nauczyć, będzie tęsknił za zaprojektowaniem magazynu danych dokumentów. Mogą również spróbować użyć go jako RDBMS lub do rzeczy takich jak buforowanie. Rozbiją to, co powinno być atomowymi transakcjami, które powinny operować na całym dokumencie, na „relacyjne” części, zapominając, że replikacja i opóźnienie to rzeczy, lub, co gorsza, wciągając systemy stron trzecich w „transakcję”. Zrobią to, aby ich RDBMS mógł odzwierciedlać ich jezioro danych, bez względu na to, czy zadziała, czy nie, i bez testowania, ponieważ wiedzą, co robią. Wtedy będą zaskoczeni, gdy złożone obiekty przechowywane w oddzielnych dokumentach, takich jak „zamówienia”, będą miały mniej „pozycji zamówienia” niż oczekiwano, a może wcale. Ale nie będzie się to zdarzać często lub na tyle często, że po prostu maszerują naprzód. Mogą nawet nie napotkać problemu w rozwoju. Następnie, zamiast przeprojektowywać, będą rzucać „opóźnienia”, „ponowienia” i „sprawdzenia”, aby sfałszować relacyjny model danych, który nie zadziała, ale zwiększy złożoność bez żadnych korzyści. Ale teraz jest już za późno - rzecz została wdrożona i teraz firma na niej działa. Ostatecznie cały system zostanie wyrzucony, a dział zostanie zlecony na zewnątrz, a ktoś inny będzie go utrzymywał. Nadal nie będzie działać poprawnie, ale mogą zawieść mniej kosztownie niż obecna awaria.
