Un modello come questo potrebbe tradursi in un database di documenti o grafici?

Question

Un modello come questo potrebbe tradursi in un database di documenti o grafici?

#1 da (2 voti)

2

Sto cercando di capire quali tipi di modelli che ho tradizionalmente persistito in relazione si tradurrebbero bene in qualche tipo di database NoSQL. Supponiamo che abbia un modello con le seguenti relazioni:

Product  1-----0..N  Order
Customer 1-----0..N  Order

E supponiamo di dover interrogare frequentemente cose come Tutti gli ordini, Tutti i prodotti, Tutti i clienti, Tutti gli ordini per un determinato cliente, Tutti gli ordini per un determinato prodotto. La mia sensazione è che questo tipo di modello non denormalizza in modo pulito - Se avessi Product e Customer documenti con Orders incorporato, entrambi i documenti avrebbero ordini duplicati.

Quindi penso che avrei bisogno di documenti separati per tutte e tre le entità. Una caratteristica come questa in genere indica che un database di documenti non è adatto per un determinato modello? In generale, un database di documenti funzionerebbe come un database relazionale in questo tipo di situazione?

Conosco pochissimo sui database di grafi, ma capisco che un database grafico gestisca le relazioni in modo più performante di un database di documenti: un database grafico sarebbe adatto per questo tipo di modello?

database nosql document-databases graph-databases

posta Eric 18.10.2013 - 16:50

fonte

1 risposta

Leggi altre domande sui tag database nosql document-databases graph-databases

API Web riposante VS Regolatori regolari c ++ web con nginx - Devo preoccuparmi della sicurezza dei thread?

score 2 · Answer 1

A mio parere, un database di documenti non sarebbe corretto per questo. Ho un'esperienza limitata, però.

La mia esperienza: 15 anni di SQL Server, 2 anni di Postgres, solo 2 progetti con MongoDB.

Dopo i miei anni con database relazionali, potrei essere di parte. Ma ho davvero cercato di abbracciare il concetto di documento. È davvero fantastico avere documenti, cioè articoli che si desidera aggiornare atomicamente.

Stai descrivendo le relazioni. Le relazioni appartengono a un database relazionale. Potrebbero esserci alcuni database di documenti più evoluti che sono migliori per i dati relazionali. Ma sono davvero costruiti per altri usi.

Dopo aver costruito alcuni picchi con MongoDB, ho creato un progetto Node per ritrasmettere i dati tra diverse API esterne e la nostra API. Il server è in esecuzione da un paio d'anni e gestisce un paio di centinaia di migliaia di importazioni all'anno.

MongoDB sembrava essere particolarmente adatto a questo. Ma non appena ho aggiunto l'accesso agli utenti e al controllo degli accessi, ho iniziato a utilizzare di nuovo un db relazionale di nuovo.

I database dei documenti ti incoraggiano a lanciarci tutto. La sfida che ho incontrato è stata la gestione della versione tra diversi oggetti JSON sagomati nella stessa collezione (tabella). Ho finito per usare lo schema JSON per convalidare tutto ciò che entrava nelle raccolte. Questo mi ha tolto parte della libertà che ho acquisito usando MongoDB in primo luogo.

Se costruissi di nuovo quel progetto, lo farei con Postgres.

Due anni fa ho avviato un nuovo progetto (server Node, app React Native). Ho iniziato con MongoDB, ma la stessa identica cosa mi ha colpito di nuovo. Non appena inizi a gestire utenti, ACL e relazioni critiche crescerai da MongoDB. Sono passato a Postgres e ora il DB è composto da circa 100 tabelle normalizzate.

Postgres ha un tipo di campo JSON che compensa molto bene ciò che mi mancava da MongoDB.

Sommario: Interrogare per i dati in MongoDB non è un problema. Troverai tutto ciò che ti serve in un attimo. Funzionalità di indicizzazione sono anche grandi.

Mantenere protetti i tuoi dati relazionali sarà una sfida in MongoDB. L'ACID è la via per andare imho.

Se mi piacerebbe crescere dal tipo di campo JSON in Postgres potrei vedere me stesso usando MongoDB per qualche spazio, ma il db principale sarebbe sicuramente relazionale.