Come faccio a sapere se i miei dati sono relazionali o orientati agli oggetti in natura?

Leggi queste righe-

• Se i tuoi dati sono di natura oggetto, utilizza gli archivi oggetti ("NoSQL"). Saranno molto più veloci di un database relazionale.

• Se i dati sono di natura relazionale, ne vale la pena l'overhead di un database relazionale.

a partire dal-

http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern

Quindi, come faccio a sapere se i miei dati sono di natura relazionale o orientati 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 il recupero. Inoltre, se i dati possono essere modellati in modo tale che tutti gli elementi abbiano uno di un insieme limitato di tipi, è quindi possibile definire una struttura di dati relazionali che corrisponda a questo insieme di tipi.

La "natura dell'oggetto" si traduce in: Gli elementi di tipo simile possono avere una grande varietà di attributi e questi attributi possono essere di una grande varietà di natura e tipo. Molto spesso questo potrebbe (con sufficiente sforzo) essere tradotto in un modello relazionale, ma molte tabelle sarebbero scarsamente popolate e si finiranno con join LEFT OUTER molto inefficienti, il che rende lenta la performance di un database relazionale rispetto a un database NOSQL.

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

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

I dati sono entrambi.

(a rigor di termini non può essere un oggetto in natura perché manca di comportamento, ma non lo faremo nitpick).

Le decisioni in merito all'archiviazione dei dati in un database RDBMS o NoSQL dipendono più da come si intende utilizzare i dati , piuttosto che dalla vera "natura" dei dati stessi.

Se si intende supportare tutti i tipi di percorsi di navigazione verso i dati, è possibile che si desideri archiviare i dati in un RDBMS perché si avranno diversi modi per accedere e presentare i dati. È necessario che il database esegua molto lavoro pesante per te. Ad esempio, è possibile accedere ai dati "Ordine" tramite cliente, addetto alle vendite, sku (articolo), data, regione ecc.

D'altra parte, se si dispone di percorsi di navigazione minimi, è possibile memorizzare l'intero oggetto. Ad esempio, "Basket" a cui si accede solo dal front-end Web e non è archiviato a lungo o analizzato molto, potrebbe essere più adatto a un archivio NoSQL. Il sacrificio che fai con gli archivi di dati NoSQL (documento o valore chiave) è quello di fare a meno delle relazioni tra raccolte - se non hai bisogno di quelle relazioni (per percorsi di navigazione, query o report ad hoc) e occupartene nel tuo app, allora starai bene.

Naturalmente, è possibile archiviare i dati in entrambi per diversi motivi, ma questo ha i suoi svantaggi.

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

L'affermazione che Object Stores / NoSql sarà più veloce di quella relazionale per alcuni tipi di dati è semplicemente sbagliata. Ciò che conta è di nuovo come l'applicazione utilizza i dati, non la forma dei dati stessi. Un archivio oggetti sarà più veloce nel caricare un grafico a oggetti memorizzato come unità, ma sarà molto più lento nel interrogare ad hoc su molti oggetti o nell'aggiornamento delle 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 sottolineando che se, ad esempio, il tuo codice ottiene il numero di clienti in Spagna per un po 'di logica, non dovresti compilare un elenco di clienti con tutti i clienti in Spagna e quindi contare il cliente obietta. (verso cui un ORM potrebbe spingerti verso)

Ovviamente non si può dire dalla stessa struttura dei dati del cliente se verrà utilizzato in questo modo. quindi penso che dovremmo interpretare "dati" per indicare "Tutte le informazioni utilizzate dalla tua applicazione". Se questo include cose come aggregati o "Tutte le X relative a Y", i tuoi "dati" non sono adatti all'approccio atomico NoSql