Newsgroup: it.comp.appl.access
Titolo: Access + MongoDB ???

C'e' qualcuno che ha esperienza con MongoDB ed in generale coi NoSql?
Ultimamente si trova un po' ovunque
Volevo provare a pasticciarci per capire mellio a cosa serve, perche' in 
realta' non ho ancora ben capito quali vantaggi possano avere rispetto 
ai classici db relazionali
Consilli?
 


io ho seguito questi tutorial
http://university.mongodbitalia.it/
 
 
https://consulity.net/content/consulity-InstallMongoDB.aspx
 
 
Efisio


Vedo che l'hai usato
Quand'e' che consiglieresti un db NoSql rispetto ai classici 
SqlServer/Db2/Oracle?
 

Quand'e' che consiglieresti un db NoSql rispetto ai classici SqlServer/Db2/Oracle? 
 
consigliare...
bisogna capire che tipo di dato devi gestire.
I "classici" motori relazionali li usi per gestire dati strutturati, a schema fisso. il dato viene inserito in tabelle. 
I NoSQL sono più indicati per gestire dati di vario genere (documenti ad esempio) e consentono 
una versatilità e modellazione del dato molto più ampia rispetto dai database relazionali a schema fisso. 
dipende....
 
Oggi motori come SQL Server, dalla versione 2016, sono proiettati verso l'intergrazione ai db NoSQL 
vedi Polybase > Hadoop
 
Efisio


Ancora non riesco a comprendere quando dici "..versatilità e 
modellazione del dato molto più ampia.."
Potresti fare qualche esempio ?
 

 relazionali a schema fisso.  dipende....
 
Mongo è il pianeta sul quale s'abbattè Flash Gordon... ;-) ;-) ;-)
 
A parte ciò, MongoDB continua ad essere un database relazionale o no?
 
Bruno


un esempio semplice:
suppuni che ti è stato chiesto di creare una tabella anagrafica clienti,
in un qualsiasi database relazionare crei la tabella: 
ID_CLIENTE	INT
COGNOME		VARCHAR(100)
NOME		VARCHAR(100)
...
 
a questa tabella successivamente devi abbinare una tabella di indirizzi,
perchè chi ti ha commissionato il programma vuole uan relazione uno a molti per gli indirizzi.
quindi crei una tabella indirizzi:
ID_INDIRIZZO	INT
ID_CLIENTE	INT
INDIRIZZO	VARCHAR(100)
...
 
ovviamente su queste due tabelle fai una JOIN per relazionarle.
 
su un database NoSQL, invece, crei la collection clienti e poi al suo interno un array indirizzi[]:
{
_id:Objectid()
Cognome:"qui inserisci il cognome",
Nome:"qui inserisci il nome",
Indirizzi:[
	{Indirizzo:"qui inserisci il primo indirizzo"},
	{Indirizzo:"qui inserisci il secondo indirizzo"},
	{Indirizzo:"qui inserisci il terzo indirizzo"}
 	]
}
 
finito!
 
ovvio che questo è un esempio semplice semplice.
c'è molto da studiare e di conseguenza mettere in pratica
 
Efisio


no

fif...@gmail.com
 wrote :

Beh è il secondo di cui sento parlare, il primo si chiamava,
se non ricordo male, Approach... ebbe vita brevissima.
 
Ma a che serve un db non relazionale? ci sono già le
tabelle di Excel!
 
Bruno

Ma a che serve un db non relazionale?
i motori di dataqbase NoSQL sono orientati ai documenti. 
Qualunque tipo di documento
Questi vengono usati per i famosi Big Data.
Amazon, Google, Facebook ecc... lavorano con database NoSQL
 
Efisio


L'esempio e' chiaro
Non altrettanto chiaro e' il motivo per cui, in questo caso, sarebbe da 
preferire un noSql rispetto ad un relazionale
Dire una tabella 'nomi' collegata ad una tabella 'indirizzi', mi sembra 
la stessa identica cosa che dire una collection 'nomi' ed un array 
'indirizzi'
Ma forse l'esempio proposto non descrive un caso adatto ad un noSql 
rispetto ad un classico relazionale
 

 rispetto ad un classico relazionale
 
Stai tralasciando il FOCUS del NoSQL, ovvero trattare moli di dati molto grandi con caratteristiche non predefinite ed eterogenee...!
 
L'esempio in questione infatti prevede la rigidità sul campo INDIRIZZI...!
Supponi di non sapere a priori l'esigenza di flessibilità..., quindi potrebbe nascere l'esigenza del campo "email" (lato Molti), poi del campo NICK(lato Molti)... ecc..!
 
Nel DB relazionale per offrire la flessibilità hai 2 Opzioni:
1) DENORMALIZZI per consentire CUSTOM PROPERTIES, ma ci sono in tutti i casi limiti di flessibilità sulle aggregazioni eterogenee
 
2) MODIFICHI la struttura ogni volta dati perchè non puoi prevedere TUTTO.
 
Nel DB nonRelazionale di fatto non viene alterata la Struttura, ma semplicemente sfruttata la possibilità di Personalizzazione ed implementare CUSTOM COLLECTION le quali possono implementare CUSTOM PROPERTIES, o a sua volta CUSTOM COLLECTION... 
 
https://docs.mongodb.com/manual/core/databases-and-collections/
 
 
In sostanza banalizzando è un DB con una logica di implementazione ad OGGETTI, cosa non fattibile con un DB-Relazionale.
 
In Sostanza in un Relazionele la Classe Oggetto è la Struttura del RECORD, e la Collection è la Tabella, struttura rigida... per modificarla devi modificare Tabella e campi.
 
In un NON-Relazionale questi vincoli non esistono.
 
Di fatto non credo sia facile la comprensione della differenza se non ci si lavora, ma la differenza va contestualizzata allo scopo reale per cui sono sitati pensati ed ottimizzati.
Offrono prestazioni di estrazione dati con Velocità estremamente più performanti di un Relazionale.
 
@Alex