Come faccio a sapere che i miei dati sono di natura relazionale o orientata agli oggetti?

A rischio di sparare a pezzi, proverò una semplice definizione inglese.

"Natura relazionale" per me si traduce in: tutti gli elementi di un particolare tipo hanno praticamente gli stessi attributi, il che rende abbastanza facile progettare una tabella semplice, ma tutti gli elementi in quella tabella e quindi SQL per eseguire CRUD e recupero. Inoltre, se i tuoi dati possono essere modellati in modo tale che tutti gli articoli abbiano uno di un set limitato di tipi, puoi quindi definire una struttura di dati relazionali che corrisponde a questo insieme di tipi.

"Natura dell'oggetto" si traduce in: Articoli di tipo simile possono avere un'ampia varietà di attributi e questi attributi possono essere di una grande varietà in natura e tipo. Molto spesso questo potrebbe (con uno sforzo sufficiente) essere tradotto in un modello relazionale, ma molti tavoli sarebbero molto scarsamente popolati e si finirebbero con join LEFT OUTER molto inefficienti, il che rende le prestazioni di un database relazionale lento rispetto a in un database NOSQL.

Devo dire che dal mio punto di vista non esiste una linea rigorosa che separi questi due. Probabilmente potresti trovare un numero qualsiasi di esempi che cadono ovunque tra i due estremi.

OK, così ora mi sono aperto ai cecchini da tutte le direzioni. Qualsiasi commento benvenuto. Vediamo se possiamo migliorare insieme questa definizione.

I dati sono entrambi.

(in senso stretto non può essere oggetto di natura perché manca di comportamento, ma non lo faremo con il nitpick).

Le decisioni sull'archiviazione dei dati in un database RDBMS o NoSQL dipendono più da come intendi utilizzare i dati , piuttosto che dalla "natura" reale dei dati stessi.

Se si intende supportare tutti i tipi di percorsi di navigazione ai dati, è possibile che si desideri archiviare i dati in un RDBMS poiché si avranno diversi modi per accedere e presentare i dati. Hai bisogno del database per fare un sacco di lavori pesanti per te. Ad esempio, è possibile accedere ai dati "Ordine" tramite cliente, addetto alle vendite, sku (articolo), data, regione ecc.

D'altra parte, se hai percorsi di navigazione minimi, puoi semplicemente memorizzare l'intero oggetto. Ad esempio, 'Carrello' a cui si accede solo dal front-end Web e che non è memorizzato per molto tempo o analizzato molto, può essere più adatto a un negozio NoSQL. Il sacrificio che fai con (documento o valore chiave) gli archivi dati NoSQL è che fai senza relazioni tra le collezioni - se non hai bisogno di quelle relazioni (per i percorsi di navigazione, query o report ad-hoc) e prenditi cura di loro nel tuo app, allora starai bene.

Ovviamente, puoi memorizzare i dati in entrambi i casi per diversi motivi, ma questo ha i suoi svantaggi.

I dati non sono "oggetto nella natura" o "natura relazionale". Qualsiasi tipo di dati può essere rappresentato sia nella struttura relazionale che in un modello di oggetto / struttura del grafico. Ciò che è appropriato dipende da come i dati verranno utilizzati dalle applicazioni. Spesso potresti persino averli entrambi. Ad esempio, i dati utilizzati su un sito Web possono essere archiviati in un database relazionale, ma caricati su richiesta in una struttura di grafici che viene quindi memorizzata nella cache in un archivio di valori-chiave in memoria.

L'affermazione che l'oggetto memorizza / NoSql sarà più veloce della relazione per alcuni tipi di dati è semplicemente sbagliata. Ciò che conta è ancora come la tua applicazione usa i dati, non la forma dei dati stessi. Un archivio oggetti sarà più veloce nel caricare un grafico oggetto memorizzato come un'unità, ma sarà molto più lento nel caso di query ad-hoc su molti oggetti o nell'aggiornamento di proprietà su molti oggetti.

Penso che la linea chiave dell'articolo sia:

"Likewise, sometimes the output will be a single object X, which is easy to represent. But sometimes the output will be a grid of aggregate data, or a single integer count"

Mi sembra che l'autore stia facendo un buon punto sul fatto che se il tuo codice per esempio ottiene il numero dei clienti in Spagna per un po 'di logica, non dovresti compilare un elenco di clienti con tutti i clienti in spagna e quindi conta gli oggetti cliente. (che un ORM potrebbe spingerti verso)

Ovviamente non puoi dire dalla struttura dei dati del cliente stesso se verrà usato in quel modo. quindi penso che dovremmo interpretare "dati" come "tutte le informazioni utilizzate dalla vostra applicazione". Se questo include cose come "aggregati" o "Tutti X correlati a Y", i tuoi "dati" non sono adatti all'approccio NoSql atomico