229 messaggi dal 08 marzo 2012
ciao a tutti,

Vi faccio una domanda per cercare di capire come funziona.
Ormai si parla spesso di database colonnari o document db o comunque di archiviazione in formato json.
Io non capisco però come potrei poi realmente gestire le classiche relazioni.
Prendiamo un semplicissimo gestionale ordini.

Memorizzo anagrafica clienti e man mano gli ordini, righe ordini etc...
Su un db relazionale prendo id cliente e lo porto su ordine come foreign key.
Di conseguenza se aggiornerò cliente quando recupero ordine la referenza è aggiornata.
Come funziona tutto ciò su db non relazionali?

Certo è comodissimo salvare tutto il json su una sola colonna ed anche enormemente più veloce in termini di sviluppo.
Anche le join svaniscono...quindi più veloce.

Ma non capisco come potrei gestire allo stesso modo un classico piccolo gestionale come questo o anche molti altri sistemi come per esempio sistemi di prevenzione etc...

Sapreste spiegarmelo?

Grazie!
708 messaggi dal 13 novembre 2008
Contributi
sono storage non relazionali, quindi il concetto è proprio che le classiche relazioni non esistono, anche se poi ognuno ha le sue caratteristiche specifiche
DocumentDb non l'ho mai usato, ma il concetto è che salvi dati json che possono avere struttura differente, questo in alcuni casi è un enorme vantaggio a livello di sviluppo, per esempio non devi pensare a strutturare rigidamente i dati a inizio progetto, puoi cambiare la struttura del json in qualsiasi momento a seconda delle esigenze, ecc.
Su Azure Storage Table, che uso abitualmente, posso inserire dati non strutturati, le relazioni le faccio a codice incrociando i dati prelevati attraverso due chiavi PartitionKey RowKey che hanno caratteristiche specifiche; la comodità è che la mia Table può avere Rows con proprietà differenti e ciò mi permette una grande flessibilità di sviluppo.
Il concetto quindi è molto diverso da un db relazionale e dovrai gestire lo sviluppo diversamente, comunque occorre leggere la documentazione di ogni storage per capire bene cosa può essere, e se può essere, più proficuo per il tuo progetto, quali sono le chiavi se ci sono, come possono essere utilizzate, ecc.
229 messaggi dal 08 marzo 2012
teo prome ha scritto:
sono storage non relazionali, quindi il concetto è proprio che le classiche relazioni non esistono, anche se poi ognuno ha le sue caratteristiche specifiche
DocumentDb non l'ho mai usato, ma il concetto è che salvi dati json che possono avere struttura differente, questo in alcuni casi è un enorme vantaggio a livello di sviluppo, per esempio non devi pensare a strutturare rigidamente i dati a inizio progetto, puoi cambiare la struttura del json in qualsiasi momento a seconda delle esigenze, ecc.
Su Azure Storage Table, che uso abitualmente, posso inserire dati non strutturati, le relazioni le faccio a codice incrociando i dati prelevati attraverso due chiavi PartitionKey RowKey che hanno caratteristiche specifiche; la comodità è che la mia Table può avere Rows con proprietà differenti e ciò mi permette una grande flessibilità di sviluppo.
Il concetto quindi è molto diverso da un db relazionale e dovrai gestire lo sviluppo diversamente, comunque occorre leggere la documentazione di ogni storage per capire bene cosa può essere, e se può essere, più proficuo per il tuo progetto, quali sono le chiavi se ci sono, come possono essere utilizzate, ecc.


Chiaro, ma ci svilupperemo mai dei "gestionali"?

Quale tipo di applicazione ci hai realizzato?
708 messaggi dal 13 novembre 2008
Contributi
Un sistema che gestisce autorizzazioni ad un'app, prenotazioni di attività online, pagamenti, profili utente, ecc.;un altro in sviluppo che gestisce un minisocial. Tutto con Azure Storage che tra l'altro è veloce e conveniente.
229 messaggi dal 08 marzo 2012
Sono tutti casi nei quali non hai necessità di mantenere aggiornate le relazioni ma ogni "salvataggio" per così dire è "a se stante".

Sbaglio?

Se dovessi invece fare il classico gestionale di azienda sarebbe una buona scelta oppure non conviene?
Come si comporta inoltre tutto questo con la necessità di analizzare dati per esempio con PowerBI?

Archiviando tutto in json non lo vedo così semplice da analizzare poi. Sbaglio?
708 messaggi dal 13 novembre 2008
Contributi
prenotazioni-pagamenti-utente certo che sono relazionati, nel caso di Azure Table avranno appositi PartitionKey e RowKey, occorre uscire però dal modo classico di intendere le relazioni facendole direttamente a storage; personalmente quel metodo non mi è mai piaciuto, voglio avere una struttura con la massima flessibilità, se cambio storage non voglio passare il mio tempo a ricostruire relazioni o altro, ho sempre preferito avere un layer di codice apposito dove eventualmente relazionare le chiamate. Se un utente fa un'azione che comporta due-tre chiamate, magari asincrone, che poi relaziono col codice per me è perfetto; se voglio cambiare la risposta, perché magari il cliente vuole che escano dati diversi, perfetto, cambio due righe di codice.
Cosa mi da in più? A me conviene in termini di flessibilità, portabilità, modificabilità, pulizia, velocità, e mille altre cose, ma ognuno valuterà in base al suo progetto; non esiste una buona scelta in generale per tutti i progetti, ma solo una scelta valida ad ottenere un buon risultato finale per quel progetto.
PowerBI l'ho solo visto di sfuggita, non ho idea quindi di come possa trattare i dati su diversi tipi di storage.
Modificato da teo prome il 04 maggio 2020 09:11 -
229 messaggi dal 08 marzo 2012
teo prome ha scritto:
prenotazioni-pagamenti-utente certo che sono relazionati, nel caso di Azure Table avranno appositi PartitionKey e RowKey, occorre uscire però dal modo classico di intendere le relazioni facendole direttamente a storage; personalmente quel metodo non mi è mai piaciuto, voglio avere una struttura con la massima flessibilità, se cambio storage non voglio passare il mio tempo a ricostruire relazioni o altro, ho sempre preferito avere un layer di codice apposito dove eventualmente relazionare le chiamate. Se un utente fa un'azione che comporta due-tre chiamate, magari asincrone, che poi relaziono col codice per me è perfetto; se voglio cambiare la risposta, perché magari il cliente vuole che escano dati diversi, perfetto, cambio due righe di codice.
Cosa mi da in più? A me conviene in termini di flessibilità, portabilità, modificabilità, pulizia, velocità, e mille altre cose, ma ognuno valuterà in base al suo progetto; non esiste una buona scelta in generale per tutti i progetti, ma solo una scelta valida ad ottenere un buon risultato finale per quel progetto.
PowerBI l'ho solo visto di sfuggita, non ho idea quindi di come possa trattare i dati su diversi tipi di storage.
Modificato da teo prome il 04 maggio 2020 09:11 -


Ok condivido il punto di vista e proprio per questo sono interessato a capire.
Quello che però ancora non comprendo è se hai il classico gestionale dove

- registrati un cliente
- registri ordini per quel cliente
- in seguito modifichi anagrafica cliente

In un modello relazionale ordine ha la foreign key a cliente quindi la prossima volta che recupero i dati di ordine troverò quelli del cliente aggiornati.

Non capisco come funzioni tutto ciò invece su uno storage come azure table o ancora come mongodb, etc...

Se volessi ancora per esempio ottenere tutti gli ordini di un cliente e paginarli a video come faccio?

Grazie per le risposte, sono davvero interessato a capire come possa essere fatto diversamente.
Il vantaggio di archiviare dati con forma diversa senza definirla è indubbiamente potente ma quale poi il prezzo di gestire tutta la logica nel codice?

Un DataAccess su questi sistemi che gestisce dati di questo tipo che "forma ha"? Come recupera o salva i dati in transazione?

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.