Newsgroup: it.comp.www.php
Titolo: Database Sqless possono sostituire i rdbms?

Ultimamente comincio a sentire spesso parlare di questi database non-
sql (anche su questo ng), ho provato mongodb e devo dire che come
prestazioni è eccezzionale rispetto a mysql o postgresql (parlo di
semplici test insert/select, utilizzando i sistemi così come vengono
installati, senza nessuna ottimizzazione)
 
Anche dopo una veloce ottimizzazione base su mysql e postgresql
(indici) le performance di mongo rimangono almeno 3 volte migliori,
senza contare che mongo risulta (stando a quello che ho letto, è la
mia prima esperienza con mongo) molto più scalabile.
 
Ora mi chiedo: in un'applicazione 'standard', come può essere un e-
commerce (utenti, ordini, oggetti, etc..) a quali problemi si può
andare in contro con mongodb?
 
Esiste un modo per avere (o emulare efficacemente): l'integrità dei
dati (foreign key) e le transazioni?
 
I consigli da chi ha esperienza diretta mi farebbero molto comodo (per
ora, ho deciso di passare solo il sistema di archiviaizone i18n su
mongo)


maaa... sto provando la shell interattiva sul sito di mongo, vedo "oid" 
da una parte... ma si tratta di database a oggetti? Perchè, studiandoli 
da lontano, mi è parso che gli OODBMS non siano molto ben voluti in 
generale.
 
No perchè di database che non seguono il paradigma RDBMS io conoscevo 
anche NoSQL, non saprei

 andare in contro con mongodb?
 
Per come č adesso, con il livello under-low di cultura che (mi) ci
circonda, se a un potenziale cliente dico - per sbaglio - che uso un db
che si chiama "mongo" :
a) gli viene in mente Shrek 2, si mette a ridere e mi manda a ca°are
b) mi manda a ca°are
 
Se sei piů fortunato di me e non hai pelo sullo stomaco, č da provare...
(solo per quello che ho letto, non ho avuto modo di provarlo).
 
saludos,
M.

 M.
Beh, ma non si dice questo al cliente
Gli si dice che usi un sistema NoSql per l'Object Based Entity Mapping 
che massimizza le performaces e supercazzola prematurata ...
 
Siamo proprio alle basi, eh :D
 
Personalmente sono tentatissimo pure io. Ho per le mani un paio di 
progetti dove potrei anche provare un sistema noSql.
Quello che mi terrorizza è metterlo in produzione e scoprire bug random 
del menga.
M
 
-- 
I fatti mi cosano

 mongo)
 
Mongo e` ottimo per gestire documenti, e infatti si chiama "Document 
Database". In un ecommerce, per esempio, puoi avere il prodotto, i 
commenti degli acquirenti e un array dinamico di tutti i riferimenti 
esterni (prodotti consigliati, correlati, siti di recensioni, ecc.) tutto 
nella stessa "riga" di database, ed estrapolare (ma anche fare ricerche 
su) solo i dati che ti servono.
 
Nulla ti vieta di mischiare i database. Puoi usare mongo per il catalogo 
prodotti, e PostgreSQL per la gestione del carrello e del magazzino.
 
Tieni presente pero` le destinazioni d'uso. Mongo e Couch sono document 
database (ognuno coi suoi punti di forza e debolezza), ma ci sono graph 
database che rendono istantanee query sui grafi (come la rete di amicizie 
di facebook o linkedin, per esempio) che su MySQL richiedono ore o 
giorni. E ci sono key-value-store (come il vecchio gdbc, ma evoluti in 
salsa scalabile) per usi particolari come il caching o simili.
 
Bye.

 pensati
 
E viceversa :)


a un certo punto infatti diaspora č passato da mongo a mysql! :-D
 
http://bit.ly/oORLi1
 
 
-- 
http://www.evilripper.net
 
http://www.flickr.com/photos/evilripper/
 

 a un certo punto infatti diaspora è passato da mongo a mysql! :-D
 
Io credo che il boom dei DB NoSQL abbia lasciato un po' tutti spiazzati, 
e che una sana analisi su pregi e difetti di ogni soluzione sia ancora 
allo studio.
 
Non per niente si trovano un sacco di articoli "mongoDB vs CouchDB vs 
Cassandra vs the world" che cercano di capire pregi e difetti di ogni 
soluzione.
 
Da ignorante, io per Diaspora avrei usato un GraphDB per le relazioni tra 
gli utenti, e un SQL o un DocDB per le loro attivita`.
Mantenere l'integrita` delle relazioni tra utenti dentro un DocDB deve 
essere abbastanza complicato gia` dal secondo livello (gli amici degli 
amici).
 
Bye.
 

Grazie Alessandro, sempre molto esaustivo.
 
Ora, fatemi capire una cosa, in un rdbms solitamente ho:
1. Tabella clienti, con tutti i dati del cliente*
2. Tabella ordini, con id del cliente, data di consegna, note,
totali*, etc..
3. Tabella listino (catalogo), con tutti i dati degli oggetti
4. Tabella oggetti acquistati (dentro l'ordine), con quantita, note,
prezzo etc..**
 
*   A volte le tabelle si frammentano, ad esempio nel caso in cui il
cliente abbia più indirizzi di spedizione, o gli oggetti più aliquote
iva, etc..
** Qui dovranno essere salvati anche tutti i dati del listino che non
devono variare nel tempo, come appunto il prezzo
 
Se ho capito bene, in mongodb avrei:
 
1. Una collezione per i clienti *
2. Una collezione per gli ordini, con dentro anche gli oggetti
presenti nell'ordine *
3. Una collezione per il listino
 
* Nel caso di più indirizzi di spedizione, non si crea un'altra
tabella, ma si mettono dentro al set come array
 
Oppure:
1. Una collezione per i clienti, con dentro gli ordini, con dentro gli
oggetti, a mò di matrioska
2. Una collezione per il listino
 
 
Nel secondo caso eliminando il cliente vengono eliminati
automaticamente i suoi ordini, le relazioni sono praticamente
'implicite'.
Ciò non accade eliminando un oggetto nel listino, perchè bisognerebbe
eliminare*** anche le controparti negli ordini.
 
*** ammettiamo che vogliamo eliminare gli oggetti 'orfani', anche se
nella vita reale non si eliminano a cane oggetti dagli ordini clienti
 
Complichiamo le cose: abbiamo più listini con scontistiche diverse,
questi possono avere gli stessi oggetti o possono essere diversi,
immaginiamo un listino standard, uno per i rivenditori e uno per i
clienti abbonati.
 
In RDBMS io aggiungerei semplicemente un'altra tabella con 2 campi,
id_listino e id_utente (cliente/fornitore) per i collegamenti.
Se collego un utente a un listino, e poi elimino l'utente o il
listino, dovrei eliminare anche la riga nella tabella con 2 campi.
 
In NoSql dovrei semplicemente aggiungere l'attributo
"listini_collegati" nella collezione dei clienti, e se voglio sapere
quali clienti sono collegati al determinato listino devo aggiungere
anche un attributo alla collezione dei clienti; Forse per queste
casistiche è meglio l'approccio rdbms.
 
 
Fin qui stò ragionando in maniera corretta?

Ho proprio scritto su ilpw un post simile sull'argomento.
Quello che mi interessa capire (sto provando mongoDb e mi sembra un bell'approccio) e' se nello sviluppo di un applicazione si puo' pensare di aggiungere un layer software tra il modello e il db cioe' sviluppare l'app basandosi su propri modelli e poi astrarre il supporto per MySql e per Mongo, in modo da poter far funzionare l'app con entrambi come si fa supportando i vari RDBMS, o e' un idea malsana, dovuta alla diversa filosofia di approccio al dato?
 
J.

 approccio al dato?
 
L'idea non e` malsana, ed e` quello che tentano di fare gli ORM da anni.
 
Non e` semplice, perche` dovresti veramente separare logicamente i due 
mondi.
Lato PHP devi costruirti la tua gerarchia di oggetti come se dovessi 
tenere tutto in RAM, mentre lato DB devi gestire tutto come se avessi 
solo i dati e non dovessi farci nulla.
 
Lo strato in mezzo ha l'improbo lavoro di metterli d'accordo.
 
Su SQL dovra` inventarsi le relazioni, crearsi le tabelle dati e le 
tabelle di relazione pura.
Lato NoSQL dovra` mappare i dati quasi 1:1 con gli oggetti PHP, ma non 
sempre e` la strada migliore.
 
Se ci riesci, fammi sapere che mi interessa ;)
 
Bye.
 


In teoria è possibile, sfruttando ad hoc l'(h)mvc non dovrebbe neanche
essere una cosa impossibile: hai un model per i clienti, con tutti i
metodi necessari, questo a seconda del database in usa invoca il model
corretto (o adattatore) che pesca i dati nel modo corretto.
 
Forse, la cosa difficile è strutturare l'applicazione, probabilmente
le procedure classiche usate nei rdbms diventano poco ottimizzate o
superflue su nosql e viceversa.. credo.
 
Mi linki il post su ilpw (che roba è a proposito?) così lo tengo
sott'occhio?
 
Onestamente, a me la cosa che più spaventa è che il nosql sia una moda
che finisca presto, non vorrei che quando tante applicazioni
cominciano a usarli in modo intensivo spuntino fuori problemi, mentre
sui rdbms essendo più 'rodati' bene o male se ne conoscono i pregi e
difetti con basso margine di errore

 Fin qui stò ragionando in maniera corretta?
 
Direi di si`.
 
Bye.
 

 Fermo restando che comunque dovresti avere un solo listino collegato. :)
Bhè questo immagino si possa risolvere, iio devo poter associare
infiniti listini a un cliente e decidere la priorità.. che poi, verrà
utilizzata solo nel front-end quando l'utente seleziona gli oggetti..
ma vabbhè questo è un esempio e immagino che cambiando metodo si
riesca ad avere infinite associazioni (dopotutto NoSql ragiona ad
oggetti/array)
Alla fine della fiera, per ora uso mongodb per gestire l'i18n, poi
quando avrò più dimestichezza e se il gioco vale la candela sposterò
pian piano i dati che traggono vantaggio dal nosql ;)

 L'idea non e` malsana, ed e` quello che tentano di fare gli ORM da anni.
E' quello che tentano già da tempo di fare i vari framework (mi viene in
mente hibernate per primo) di astrarre il layer db e farti lavorare con
strutture a oggetti.
Con i noSQL l'astrazione dovrebbe essere "nativa", in teoria. Ma si sa,
fra la teoria e la pratica ... :)

 difetti con basso margine di errore
Questa paura e' sensata, ma per ogni tecnologia piuttosto nuova, ricordo qualche hanno fa quando le prime forme di ajax si imlementavano con l'XMLHttpReques che non era cross browser... poi arrivo' google e chiamo' tutto ajax e tutto si evolvette in poco :)
J

 avere infinite associazioni (dopotutto NoSql ragiona ad oggetti/array)
{
 nome: 'Nome cliente',
 listini: [
  { nome: 'VIP', pri: 10},
  { nome: 'standard', pri: 0}
 },
 indirizzi: [
  ...
 ]
}
Bye.

load() senza preoccuparsi di cosa c'e` sotto.
Bye.

 Questa paura e' sensata, ma per ogni tecnologia piuttosto nuova, ricordo qualche hanno fa quando le prime forme di ajax si imlementavano con l'XMLHttpReques che non era cross browser... poi arrivo' google e chiamo' tutto ajax e tutto si evolvette in poco :)
 
 
Eh per il mio blog personale mi butterei subito su mongo, dal test di
prima ho avuto un incremento di velocità del 570,09% su 50000 insert
su mysql (ovviamente, mysql era sotto prepared statement) e del
2252,88% su 50000 select... cioè.. ammesso e non concesso che
l'applicazione debba fare 2 calcoli in più (anche se strutturando bene
i dati non credo sia necessario) dovrebbe velerne veramente la pena..
 
Pian piano, senza fretta, comincio a guardarmeli.. anche perchè se
prendono veramente piede, probabilmente si troverà il modo di
aggiungere le funzioni che mancano.

Bhè a vedere da  qui: 
http://www.mongodb.org/display/DOCS/Production+Deployments
direi che mongo è già ampiamente sfruttato sia da piccoli che da
grossi ;)