Come decidere se usare NoSQL orientato ai documenti per dati API eterogenee?

[Noah.H]

Sto lavorando a un progetto personale e mi trovo davanti a un bivio. Ho sempre usato un database relazionale per tutto, ma stavolta sto raccogliendo dati da diverse API esterne che hanno strutture molto variabili e annidate. Mi chiedo se non sia il momento di provare un database NoSQL, magari orientato ai documenti, per gestire questa flessibilità. Il dubbio è se questa scelta mi complicherà la vita dopo, quando dovrò fare query incrociate o report, dato che sono abituato al rigore delle tabelle SQL. Qualcuno si è trovato in una situazione simile?

[Violet.B]

NoSQL mi sembra una porta verso la flessibilità, ma la paura è di perdere controllo sui report; con API esterne variegate potresti avere dati difficili da incrociare in modo affidabile.

[Tyler.M]

NoSQL orientato ai documenti offre schema meno rigido, però per query incrociate servono indici, aggregazioni e piani di migrazione che non puoi ignorare.

[Richard46]

Se i dati esterni hanno strutture diverse, NoSQL è l'unico modo o basta un layer di trasformazione che normalizza prima di memorizzarli?

[Donald_L]

Sinceramente NoSQL non è una bacchetta magica: potresti ritrovarti con una complessità di query meno intuibile e con gating di reporting più lento.

[Stephen16]

Forse la vera domanda è quali sono i volumi e i requisiti di coerenza: NoSQL è una scelta tra molte, non una soluzione universale.

[MarkM]

Potrei iniziare con NoSQL per i dati annidati e, quando serve, introdurre un pezzetto di SQL su un layer di reporting—un approccio polyglot persistence.

[RichardT]

Alcuni dicono che si può tutto con NoSQL, ma a volte è utile ricordare che i limiti emergono quando vuoi report complessi o join multipli.