Dowiedz się, dlaczego bazy dokumentowe pasują do szybko zmieniających się modeli danych: elastyczne schematy, szybsze iteracje, natywne przechowywanie JSON i kompromisy do rozważenia.
Baza dokumentowa przechowuje dane jako samodzielne „dokumenty”, zwykle w formacie podobnym do JSON. Zamiast rozdzielać jeden obiekt biznesowy na wiele tabel, pojedynczy dokument może zawierać wszystko o nim — pola, podpola i tablice — podobnie jak wiele aplikacji już reprezentuje dane w kodzie.
users albo orders).Dokumenty w tej samej kolekcji nie muszą wyglądać identycznie. Jeden dokument użytkownika może mieć 12 pól, inny 18, i oba mogą współistnieć.
Wyobraź sobie profil użytkownika. Zaczynasz od name i email. Za miesiąc marketing chce preferred_language. Potem customer success prosi o timezone i subscription_status. Później dodajesz social_links (tablica) i privacy_settings (zagnieżdżony obiekt).
W bazie dokumentowej zwykle możesz od razu zacząć zapisywać nowe pola. Starsze dokumenty mogą pozostać bez zmian aż do momentu, gdy zdecydujesz się je uzupełnić (lub nie).
Ta elastyczność może przyspieszyć pracę produktową, ale przesuwa odpowiedzialność na aplikację i zespół: potrzebne będą jasne konwencje, opcjonalne reguły walidacji i przemyślany projekt zapytań, żeby uniknąć bałaganu i niespójnych danych.
Przyjrzymy się, dlaczego niektóre modele tak często się zmieniają, jak elastyczne schematy zmniejszają tarcie, jak dokumenty mapują się na rzeczywiste zapytania aplikacji oraz jakie kompromisy warto rozważyć zanim wybierzesz magazyn dokumentów zamiast relacyjnego — albo podejście hybrydowe.
Modele danych rzadko pozostają statyczne, bo produkt rzadko jest stały. To, co zaczyna się od „po prostu przechowuj profil użytkownika”, szybko przeradza się w preferencje, powiadomienia, metadane płatnicze, informacje o urządzeniu, flagi zgód i tuzin innych szczegółów, których nie było w pierwszej wersji.
Większość zmian w modelu wynika z uczenia się. Zespoły dodają pola, gdy:
Zmiany te są często inkrementalne i częste — małe dodatki, które trudno zaplanować jako formalne „duże migracje”.
W prawdziwych bazach jest historia. Stare rekordy zachowują kształt, z którym zostały zapisane, podczas gdy nowe rekordy przyjmują najnowszy kształt. Możesz mieć klientów utworzonych zanim istniało marketing_opt_in, zamówienia sprzed wprowadzenia delivery_instructions albo zdarzenia zalogowane zanim zdefiniowano nowe pole source.
Więc nie „zmieniasz jednego modelu” — obsługujesz równocześnie wiele wersji, czasem przez miesiące.
Gdy wiele zespołów wypuszcza funkcje równolegle, model danych staje się wspólną powierzchnią. Zespół płatności może dodać sygnały antyfraudowe, a zespół growth dane atrybucyjne. W mikroserwisach każdy serwis może przechowywać koncepcję „klienta” z różnymi potrzebami, które ewoluują niezależnie.
Bez koordynacji „jeden idealny schemat” staje się wąskim gardłem.
Zewnętrzne systemy często wysyłają ładunki częściowo znane, zagnieżdżone lub niespójne: webhooki, metadane partnerów, formularze, telemetryka urządzeń. Nawet gdy normalizujesz ważne elementy, często chcesz zachować oryginalną strukturę do audytu, debugowania czy przyszłego użycia.
Wszystkie te siły skłaniają zespoły ku magazynom, które tolerują zmiany—szczególnie gdy szybkość wypuszczania ma znaczenie.
Gdy produkt dopiero się kształtuje, model danych rzadko jest „ukończony”. Pojawiają się nowe pola, stare stają się opcjonalne, a różni klienci mogą potrzebować nieco innych informacji. Bazy dokumentowe są popularne w takich momentach, bo pozwalają ewoluować dane bez zamieniania każdej zmiany w projekt migracyjny bazy danych.
W dokumentach JSON dodanie nowej właściwości może być tak proste, jak zapisanie jej w nowych rekordach. Istniejące dokumenty mogą pozostać nietknięte, dopóki nie zdecydujesz się je uzupełnić. Oznacza to, że mały eksperyment — np. zbieranie nowego ustawienia preferencji — nie wymaga koordynacji zmiany schematu, okna wdrożenia i zadania backfill, żeby zacząć zbierać dane.
Czasem faktycznie masz warianty: konto „free” ma mniej ustawień niż konto „enterprise”, albo jeden typ produktu potrzebuje dodatkowych atrybutów. W bazie dokumentowej może być dopuszczalne, żeby dokumenty w tej samej kolekcji miały różne kształty, jeśli aplikacja wie, jak je interpretować.
Zamiast zmuszać wszystko do jednej sztywnej struktury, możesz zachować:
id, userId, createdAt)Elastyczne schematy nie oznaczają „braku zasad”. Powszechny wzorzec to traktowanie brakujących pól jako „użyj wartości domyślnej”. Aplikacja może stosować sensowne wartości domyślne przy odczycie (lub ustawić je przy zapisie), dzięki czemu starsze dokumenty nadal działają poprawnie.
Flagi funkcji często wprowadzają tymczasowe pola i częściowe wdrożenia. Elastyczne schematy ułatwiają wprowadzenie zmiany dla małej kohorty, przechowywanie dodatkowego stanu tylko dla użytkowników z włączoną flagą i szybkie iterowanie — bez blokowania się na pracach schematu zanim zdążysz przetestować pomysł.
Wiele zespołów produktowych naturalnie myśli w kategoriach „rzeczy, które użytkownik widzi na ekranie”. Strona profilu, szczegóły zamówienia, dashboard projektu — każdy z tych widoków zwykle mapuje się na pojedynczy obiekt aplikacji o przewidywalnym kształcie. Bazy dokumentowe wspierają ten model mentalny, pozwalając przechować ten obiekt jako pojedynczy dokument JSON, z mniejszą liczbą tłumaczeń między kodem aplikacji a magazynem danych.
W relacyjnych tabelach ta sama funkcja często zostaje rozbita na wiele tabel, kluczy obcych i logikę join. Ta struktura jest potężna, ale może wydawać się zbędną ceremonią, gdy aplikacja już trzyma dane jako zagnieżdżony obiekt.
W bazie dokumentowej często można zapisać obiekt prawie tak, jak jest:
user, który odpowiada twojej klasie/typowi Userproject, który odwzorowuje stan ProjectMniej tłumaczeń zwykle oznacza mniej błędów mapowania i szybszą iterację, gdy pola się zmieniają.
Prawdziwe dane aplikacji rzadko są płaskie. Adresy, preferencje, ustawienia powiadomień, zapisane filtry, flagi UI — to wszystko naturalnie jest zagnieżdżone.
Przechowywanie zagnieżdżonych obiektów w dokumencie rodzicu trzyma powiązane wartości blisko siebie, co pomaga przy zapytaniach „jeden rekord = jeden ekran”: pobierz jeden dokument, wyrenderuj jeden widok. To może ograniczyć potrzebę joinów i niespodziewane problemy z wydajnością, które one powodują.
Gdy każdy zespół funkcjonalny odpowiada za kształt swoich dokumentów, odpowiedzialności stają się jaśniejsze: zespół, który wypuszcza funkcję, również ewoluuje jej model danych. To dobrze współgra z architekturą mikroserwisów lub modułową, gdzie niezależne zmiany są regułą, a nie wyjątkiem.
Bazy dokumentowe często pasują do zespołów, które często wypuszczają zmiany, ponieważ drobne dodatki do danych rzadko wymagają skoordynowanej zmiany schematu.
Jeśli PM poprosi o „jeszcze jeden atrybut” (np. preferredLanguage lub marketingConsentSource), model dokumentowy zwykle pozwala od razu zacząć zapisywać to pole. Nie zawsze trzeba planować migrację, blokować tabele czy negocjować okno wydania między wieloma serwisami.
To zmniejsza liczbę zadań, które mogą zablokować sprint: baza danych pozostaje użyteczna, podczas gdy aplikacja ewoluuje.
Dodanie opcjonalnych pól do dokumentów podobnych do JSON jest zwykle kompatybilne wstecz:
Ten wzorzec sprawia, że wdrożenia są spokojniejsze: możesz najpierw wypuścić ścieżkę zapisu (zacząć przechowywać nowe pole), a potem zaktualizować ścieżki odczytu i UI — bez konieczności natychmiastowej aktualizacji wszystkich dokumentów.
Systemy rzadko aktualizują wszystkich klientów jednocześnie. Możesz mieć:
W bazach dokumentowych często projektuje się pod „mieszane wersje”, traktując pola jako addytywne i opcjonalne. Nowsi pisarze mogą dodawać dane bez łamania starszych czytelników.
Praktyczny wzorzec wdrożeniowy wygląda tak:
To podejście utrzymuje wysoką prędkość rozwoju przy jednoczesnym zmniejszeniu kosztów koordynacji między zmianami w bazie a wydaniami aplikacji.
Jednym z powodów, dla których zespoły lubią bazy dokumentowe, jest to, że można modelować dane tak, jak aplikacja najczęściej je odczytuje. Zamiast rozdzielać pojęcie na wiele tabel i składać je później, możesz przechowywać „cały” obiekt w jednym miejscu (często jako dokumenty JSON).
Denormalizacja oznacza duplikowanie lub osadzanie powiązanych pól, aby typowe zapytania można było obsłużyć jednym odczytem dokumentu.
Na przykład dokument zamówienia może zawierać snapshot klienta (name, email z momentu zakupu) i osadzoną tablicę pozycji. Ten projekt może sprawić, że „pokaż moje ostatnie 10 zamówień” będzie szybkie i proste, bo UI nie potrzebuje wielu odczytów, żeby wyrenderować stronę.
Gdy dane dla ekranu lub odpowiedzi API mieszczą się w jednym dokumencie, często dostajesz:
To zwykle redukuje opóźnienie na ścieżkach odczytowych — szczególnie w feedach produktowych, profilach, koszykach i dashboardach.
Osadzanie jest pomocne, gdy:
Referencje są lepsze, gdy:
Nie ma uniwersalnie „najlepszego” kształtu dokumentu. Model zoptymalizowany pod jedno zapytanie może spowolnić inne (lub zwiększyć koszt aktualizacji). Najpewniejsze podejście to zaczynać od rzeczywistych zapytań — co aplikacja naprawdę potrzebuje pobierać — i kształtować dokumenty wokół tych ścieżek odczytu, a potem przeglądać model w miarę ewolucji użycia.
Schema-on-read oznacza, że nie musisz definiować każdego pola i struktury tabel zanim zaczniesz przechowywać dane. Zamiast tego aplikacja (lub zapytanie analityczne) interpretuje strukturę dokumentu przy odczycie. Praktycznie to pozwala wypuścić nową funkcję, która dodaje preferredPronouns lub nowe zagnieżdżone shipping.instructions bez uprzedniej migracji bazy.
Większość zespołów wciąż ma „oczekiwany kształt” w głowie — jest on po prostu egzekwowany później i bardziej selektywnie. Jeden dokument klienta może mieć phone, inny nie. Starsze zamówienie może przechowywać discountCode jako string, podczas gdy nowsze zamówienia mają bogatszy obiekt discount.
Elastyczność nie musi oznaczać chaosu. Popularne podejścia:
id, createdAt lub status i ogranicz typy dla pól wysokiego ryzyka.Trochę spójności robi dużą różnicę:
camelCase, znaczniki czasu w ISO-8601)schemaVersion: 3), żeby czytelnicy mogli bezpiecznie obsługiwać stare i nowe kształtyGdy model się stabilizuje — zwykle po tym, jak zrozumiesz, które pola są naprawdę kluczowe — wprowadź surowszą walidację tych pól i krytycznych relacji. Zachowaj elastyczność dla pól opcjonalnych i eksperymentalnych, żeby baza nadal wspierała szybkie iteracje bez ciągłych migracji.
Gdy produkt zmienia się co tydzień, nie liczy się tylko „aktualny” kształt danych. Potrzebna jest też wiarygodna historia tego, jak do tego doszło. Bazy dokumentowe dobrze pasują do przechowywania historii zmian, ponieważ trzymają samodzielne rekordy, które mogą ewoluować bez przepisywania wszystkiego, co było wcześniej.
Popularne podejście to przechowywanie zmian jako strumienia zdarzeń: każde zdarzenie to nowy dokument, który dopisujesz (zamiast nadpisywać stare wiersze). Na przykład: UserEmailChanged, PlanUpgraded, AddressAdded.
Ponieważ każde zdarzenie jest swoim własnym dokumentem JSON, możesz uchwycić pełny kontekst w tym momencie — kto to zrobił, co to wywołało i metadane, które będą przydatne później.
Definicje zdarzeń rzadko są stabilne. Możesz dodać source="mobile", experimentVariant lub nowy zagnieżdżony obiekt jak paymentRiskSignals. W magazynie dokumentów stare zdarzenia po prostu nie będą miały tych pól, a nowe będą je zawierać.
Twoi konsumenci (usługi, zadania, dashboardy) mogą bezpiecznie domyślać brakujące pola, zamiast wykonywać backfill milionów historycznych rekordów tylko po to, by dodać jedno pole.
Aby utrzymać przewidywalność konsumentów, wiele zespołów dodaje pole schemaVersion (lub eventVersion) w każdym dokumencie. To umożliwia stopniowe wdrażanie:
Trwała historia „co się wydarzyło” jest przydatna nie tylko do audytów. Zespoły analityczne mogą odtworzyć stan w dowolnym momencie, a wsparcie techniczne może prześledzić regresję, odtwarzając zdarzenia lub sprawdzając dokładne ładunki, które doprowadziły do błędu. Na przestrzeni miesięcy to przyspiesza analizę pierwotnej przyczyny i zwiększa zaufanie do raportów.
Bazy dokumentowe upraszczają zmiany, ale nie eliminują pracy projektowej — po prostu ją przesuwają. Zanim się zobowiążesz, warto być świadomym, za co wymieniasz tę elastyczność.
Wiele baz dokumentowych wspiera transakcje, ale transakcje obejmujące wiele dokumentów mogą być ograniczone, wolniejsze lub droższe niż w bazie relacyjnej — szczególnie na dużą skalę. Jeśli twój kluczowy przepływ wymaga aktualizacji „całego albo nic” kilku rekordów (np. aktualizacja zamówienia, stanu magazynu i wpisu księgowego razem), sprawdź, jak twoja baza to obsługuje i jaki ma to koszt wydajnościowy lub złożoności.
Ponieważ pola są opcjonalne, zespoły mogą niechcący stworzyć kilka „wersji” tego samego pojęcia w produkcji (np. address.zip vs address.postalCode). To może łamać funkcje zależne i utrudniać wykrywanie błędów.
Praktyczne złagodzenie to zdefiniowanie wspólnego kontraktu dla kluczowych typów dokumentów (nawet lekkiego) i dodanie walidacji tam, gdzie to najważniejsze — np. statusy płatności, ceny czy uprawnienia.
Jeśli dokumenty ewoluują swobodnie, zapytania analityczne stają się bardziej złożone: analitycy muszą uwzględniać różne nazwy pól i brakujące wartości. Dla zespołów opierających się mocno na raportowaniu warto mieć plan, np.:
Osadzanie powiązanych danych (np. snapshot klienta w zamówieniach) przyspiesza odczyty, ale duplikuje informacje. Gdy współdzielony fragment danych się zmieni, musisz zdecydować: aktualizować wszędzie, zachować historię czy tolerować tymczasową niespójność. Ta decyzja powinna być świadoma — inaczej ryzykujesz subtelny dryf danych.
Bazy dokumentowe świetnie nadają się, gdy zmiany są częste, ale nagradzają zespoły, które traktują modelowanie, nazewnictwo i walidację jako ciągłą pracę produktową — nie jednorazową konfigurację.
Bazy dokumentowe przechowują dane jako dokumenty JSON, co czyni je naturalnym wyborem, gdy pola są opcjonalne, często się zmieniają lub różnią się w zależności od klienta, urządzenia czy linii produktowej. Zamiast wciskać każdy rekord do tej samej sztywnej tabeli, możesz ewoluować model danych stopniowo, utrzymując tempo zespołów.
Dane produktów rzadko są statyczne: nowe rozmiary, materiały, flagi zgodności, bundlingi, opisy regionalne i pola specyficzne dla marketplace'ów pojawiają się non-stop. Dzięki zagnieżdżonym danym w dokumentach JSON „product” może trzymać pola bazowe (SKU, cena) i jednocześnie pozwalać na atrybuty specyficzne dla kategorii bez tygodniowych przebudów schematu.
Profile często zaczynają mało i rosną: ustawienia powiadomień, zgody marketingowe, odpowiedzi onboardingowe, flagi funkcji i sygnały personalizacji. W bazie dokumentowej użytkownicy mogą mieć różne zestawy pól bez łamania istniejących odczytów. Ta elastyczność sprzyja też zwinnej pracy, gdzie eksperymenty szybko dodają i usuwają pola.
Współczesna treść to często miks bloków i komponentów — sekcje hero, FAQ, karuzele produktów, embedy — każdy z własną strukturą. Przechowywanie stron jako dokumentów JSON pozwala redaktorom i deweloperom wprowadzać nowe typy komponentów bez natychmiastowej migracji każdej historycznej strony.
Telemetryka często różni się w zależności od wersji firmware, pakietu sensorów czy producenta. Bazy dokumentowe dobrze radzą sobie z takimi modelami: każde zdarzenie może zawierać tylko to, co urządzenie zna, a schema-on-read pozwala narzędziom analitycznym interpretować pola, gdy są obecne.
Jeśli zastanawiasz się między NoSQL a SQL, to scenariusze powyżej pokazują, gdzie bazy dokumentowe zwykle przyspieszają iteracje i zmniejszają tarcie.
Gdy model danych się ustawia, „wystarczająco dobry i łatwy do zmiany” bije „idealny na papierze”. Te praktyczne nawyki pomagają utrzymać tempo rozwoju bez zamieniania bazy w szufladę śmieci.
Na początku każdej funkcji wypisz najwyższe odczyty i zapisy, których spodziewasz się w produkcji: ekrany, które renderujesz, odpowiedzi API i aktualizacje, które wykonujesz najczęściej.
Jeśli jedna akcja użytkownika regularnie potrzebuje „zamówienie + pozycje + adres wysyłki”, zaprojektuj dokument, który obsłuży ten odczyt bez dodatkowych fetchy. Jeśli inna akcja potrzebuje „wszystkie zamówienia po statusie”, upewnij się, że możesz to zapytać lub zindeksować.
Osadzanie (nesting) jest świetne, gdy:
Referencje są bezpieczniejsze, gdy:
Możesz mieszać oba podejścia: osadź snapshot dla szybkości odczytu i trzymaj referencję do źródła prawdy dla aktualizacji.
Nawet przy elastycznym schemacie wprowadź lekkie reguły dla pól, na których polegasz (typy, wymagane ID, dozwolone statusy). Dodaj schemaVersion (lub docVersion), żeby aplikacja mogła obsługiwać starsze dokumenty i migrować je w czasie.
Traktuj migracje jako okresową konserwację, a nie jednorazowe zadanie. Gdy model dojrzeje, planuj małe backfille i porządki (usuwanie nieużywanych pól, zmiany nazw kluczy, denormalizowane snapshoty) i mierz wpływ przed i po. Prosta lista kontrolna i lekki skrypt migracyjny wiele ułatwią.
Wybór między bazą dokumentową a relacyjną to mniej pytanie „co jest lepsze”, a bardziej „jakie zmiany produkt przeżywa najczęściej”.
Bazy dokumentowe dobrze pasują, gdy kształt danych często się zmienia, różne rekordy mają różne pola, albo zespoły muszą wypuszczać funkcje bez koordynowania migracji co sprint.
Pasują też, gdy aplikacja naturalnie operuje na „całych obiektach” jak zamówienie (info klienta + pozycje + uwagi dot. dostawy) lub profil użytkownika (ustawienia + preferencje + informacje o urządzeniach), przechowywanych razem jako dokumenty JSON.
Relacyjne bazy błyszczą, gdy potrzebujesz:
Jeśli praca zespołu to głównie optymalizacja zapytań między tabelami i analityka, SQL często jest prostszym, długoterminowym rozwiązaniem.
Wiele zespołów używa obu: relacyjnie dla „systemu rejestrów” (billing, inwentarz, uprawnienia) i magazynu dokumentów dla szybko ewoluujących lub zoptymalizowanych pod odczyt widoków (profile, metadane treści, katalogi produktów). W mikroserwisach to często pasuje naturalnie: każdy serwis wybiera model magazynu dopasowany do swojej domeny.
Warto też pamiętać, że hybryda może istnieć wewnątrz relacyjnej bazy — np. PostgreSQL potrafi przechowywać półstrukturalne pola JSON/JSONB obok silnie typowanych kolumn — przydatne, gdy chcesz spójności transakcyjnej i jednocześnie miejsca na ewoluujące atrybuty.
Jeśli twój schemat zmienia się co tydzień, wąskim gardłem często jest pętla end-to-end: aktualizacja modeli, API, UI, migracje (jeśli w ogóle) i bezpieczne wdrożenie zmian. Koder.ai został zaprojektowany pod taką iterację. Możesz opisać funkcję i kształt danych w czacie, wygenerować działającą implementację web/backend/mobile, a potem ją dopracowywać, gdy wymagania ewoluują.
W praktyce zespoły często zaczynają od relacyjnego rdzenia (stack backendowy Koder.ai to Go z PostgreSQL) i stosują wzorce dokumentowe tam, gdzie mają sens (np. JSONB dla elastycznych atrybutów lub ładunków zdarzeń). Snapshoty i rollbacky w Koder.ai pomagają też, gdy eksperymentalny kształt danych trzeba szybko cofnąć.
Przeprowadź krótką ocenę zanim się zaangażujesz:
Jeśli porównujesz opcje, trzymaj zakres wąski i ogranicz czas — potem rozszerz, gdy zobaczysz, który model pozwala wypuszczać z mniejszą ilością niespodzianek. Dla więcej o ocenie kompromisów przechowywania danych zobacz /blog/document-vs-relational-checklist.
Baza dokumentowa przechowuje każdy rekord jako samodzielny dokument w formacie przypominającym JSON (w tym zagnieżdżone obiekty i tablice). Zamiast rozdzielać obiekt biznesowy na wiele tabel, często czytasz i zapisujesz cały obiekt w jednej operacji, zwykle w kolekcji (np. users, orders).
W szybko zmieniających się produktach ciągle pojawiają się nowe atrybuty (preferencje, metadane płatności, flagi zgód, pola eksperymentalne). Elastyczne schematy pozwalają od razu zapisywać nowe pola, pozostawić stare dokumenty bez zmian i opcjonalnie wykonać backfill później — dzięki temu małe zmiany nie zamieniają się w duże projekty migracyjne.
Niekoniecznie. Większość zespołów ma nadal „oczekiwany kształt”, ale egzekucja przesuwa się w stronę:
To daje elastyczność przy jednoczesnym ograniczeniu bałaganu i niespójnych dokumentów.
Traktuj nowe pola jako addytywne i opcjonalne:
To pozwala obsługiwać mieszane wersje danych w produkcji bez migracji wymagających przestojów.
Modeluj pod kątem najczęstszych odczytów: jeśli ekran lub odpowiedź API potrzebuje „zamówienie + pozycje + adres wysyłki”, przechowaj je razem w jednym dokumencie, gdy to praktyczne. To może zmniejszyć liczbę żądań i uniknąć złożonych łączeń, poprawiając opóźnienia na ścieżkach odczytu.
Używaj osadzania, gdy dane potomne są zwykle odczytywane z rodzicem i mają ograniczony rozmiar (np. do 20 pozycji). Używaj referencji, gdy powiązany element jest duży/nieograniczony, jest współdzielony przez wielu rodziców lub zmienia się często.
Możesz też mieszać oba podejścia: osadź snapshot dla szybkości odczytu i trzymaj referencję do źródła prawdy dla aktualizacji.
Pomaga to, bo wdrażanie „dodania pola” jest zwykle wstecznie kompatybilne:
To jest szczególnie przydatne, gdy wiele usług lub aplikacji mobilnych działa w starszych wersjach.
Wprowadź lekkie zabezpieczenia:
id, createdAt, status)Typowe podejścia to dokumenty append-only (każda zmiana to nowy dokument) i wersjonowanie (eventVersion/schemaVersion). Nowe pola można dodawać do przyszłych zdarzeń bez przepisywania historii, a konsumenci czytają wiele wersji podczas stopniowych wdrożeń.
Kluczowe kompromisy to:
Wiele zespołów przyjmuje hybrydę: relacyjne bazy dla systemu rejestrów, a magazyn dokumentów dla szybko ewoluujących lub zoptymalizowanych pod odczyt modeli.
camelCase, znaczniki czasu w ISO-8601)schemaVersion/docVersionTe kroki zapobiegają dryfowi typu address.zip vs address.postalCode.