Podle mého názoru by měl být formát vašich dat primárním zájmem při výběru backendu úložiště. Máte data, která mají relační povahu? Pokud ano, může a je dobrý nápad modelovat data v dokumentech? Datové modelování je v databázi dokumentů stejně důležité jako v relační databázi, jen se to dělá jinak. Kolik typů objektů máte a jak spolu souvisí? Zvládnou DBrefs v Mongodb ten trik, nebo vám budou cizí klíče chybět tak moc, že to bude bolet? Jaké jsou vaše vzorce přístupu k datům? Načítáte pouze data jednoho typu filtrovaná podle hodnoty pole, nebo máte složité režimy načítání?
Potřebujete transakční integritu ACID? Vynucuje doména mnoho omezení na data? Potřebujete faktor škálovatelnosti databáze dokumentů nebo je to jen „cool“ věc?
Jaké jsou vaše požadavky na konzistenci a integritu dat? Některá řešení NoSQL a zejména MongoDB jsou poměrně volná v konzistenci zápisu, aby se dosáhlo výkonu. NoSQL není žádná jednotná krajina a další produkty, např. CouchDB má v tomto oddělení další vlastnosti. Některé jsou také laditelné.
To vše jsou otázky, které by měly jít do výběru úložiště.
Některé zkušenosti
- Vytváření rozsáhlých zpráv o uložených datech může být obtížnější při použití MongoDB nebo jakékoli databáze dokumentů a některé případy použití pro tento účel kombinují RDBMS a document-db.
- (Velmi) odlišný model dotazu. MongoDB se také liší od ostatních document-dbs.
- Flexibilní pro změnu formátu dat/schéma během vývoje
- Neznámé území
- různý stupeň vyspělosti ovladačů a rámců
- Rychlý
- Jednodušší (v mnoha ohledech) produkty a nástroje pro správu (ve srovnání s mnoha produkty RDBMS)
- Už žádný nesoulad impedance. Úložiště odpovídá datům, ne naopak.
- Menší třenice a přímější přístup k datům.
- Doména je více vázána na perzistenci (v závislosti na "úrovni" ORM NoRM, na tom, jak moc abstrahuje backend. Nepoužil jsem NoRM, takže na to nedokážu odpovědět.)