Enligt min åsikt bör formatet på dina data vara det primära problemet när du väljer en lagringsbackend. Har du data som är relationell till sin natur? Om så är fallet, kan det och är det en bra idé att modellera data i dokument? Datamodellering är lika viktigt i en dokumentdatabas som i en relationsdatabas, det är bara gjort annorlunda. Hur många typer av föremål har du och hur är de relaterade? Kan DBrefs i Mongodb göra susen eller kommer du att sakna främmande nycklar så mycket att det blir smärtsamt? Vilka är dina åtkomstmönster för data? Hämtar du bara data av en typ filtrerad av ett fältvärde, eller har du invecklade hämtningslägen?
Behöver du ACID transaktionsintegritet? Genomför domänen många begränsningar för data? Behöver du skalbarhetsfaktorn för en dokumentdatabas eller är det bara en "cool" sak att ha?
Vilka är dina krav på konsekvens och dataintegritet? Vissa NoSQL-lösningar och MongoDB i synnerhet är ganska lösa på skrivkonsistensen för att få prestanda. NoSQL är inget enhetligt landskap och andra produkter, t.ex. CouchDB har andra egenskaper i denna avdelning. Vissa är också inställbara.
Dessa är alla frågor som bör gå in på valet av förvaring.
Några upplevelser
- Att göra omfattande rapportering om lagrad data kan vara svårare när du använder MongoDB eller någon dokumentdatabas och vissa användningsfall har kombinerat RDBMS och document-db för detta ändamål.
- (Mycket) Annan frågemodell. MongoDB skiljer sig också från andra dokument-dbs.
- Flexibel att ändra dataformat/schema under utveckling
- Okänt territorium
- varierande grad av mognad i drivkrafter och ramverk
- Snabb
- Enklare (på många sätt) produkt- och hanteringsverktyg (jämfört med många RDBMS-produkter)
- Ingen mer impedansavvikelse. Lagringen passar data, inte tvärtom.
- Mindre friktion och mer direkt tillgång till data.
- Domän mer knuten till persistens (beroende på ORM-"nivån" för NoRM, på hur mycket den abstraherar bort backend. Jag har inte använt NoRM så jag kan inte svara på det.)