salve a tutti,
per lavoro ho sempre trattato database relazionali, però guardando in giro ho visto che sono nati molti progetti per database NON relazionali.
la mia domanda è questa: quali sono i vantaggi?
perchè dovrei passare ad un database non relazionale?
forse sono io che ho la mente già "inquadrata" nel sistema classico, ma non riesco a capire quali potrebbero essere i vantaggi..
qualcuno di voi li ha già provati? sa dirmi qualcosa di più?
i relazionali hanno tanti difetti e limitazioni.
join, per cominciare, e difficoltà nella modellazione di elementi variabili.
non si "mappa" per nulla bene (in generale) con la modellazione ad oggetti, ad esempio.
nonostante questo nel 99% dei casi si preferisce "combatterci", visto che ormai hanno potenze e prestazioni davvero smisurate
scusa la domanda stupida: perchè le join sono un problema?
per la modellizzazione ad oggetto esistono molte funzioni dedicate (vedi MySQL & PHP).
la domanda che mi frulla più in testa è: come tratto questi dati?
di solito uno effettua una normalizzazione, per evitare di ripetere i dati, e dopo mette insieme il tutto con una join.
in un database non relazionale come funziona? eseguo io questa operazione da programma?
ripeto: sarò io un po' con il "paraocchi" o forse non mi sono mai trovato a dover spingere un RDBMS al limite, ma non riesco a capire quali vantaggi potrei avere...
Bhè la risposta è altrettanto "stupida":Originariamente inviato da tampe125
scusa la domanda stupida: perchè le join sono un problema?
perchè son lente
Bhè direi di conoscere "benino" mysql, ed è lontano anni luce da un db ad oggettiper la modellizzazione ad oggetto esistono molte funzioni dedicate (vedi MySQL & PHP).
Per niente.la domanda che mi frulla più in testa è: come tratto questi dati?
di solito uno effettua una normalizzazione, per evitare di ripetere i dati, e dopo mette insieme il tutto con una join.
"di solito" = "come normalmente (** cit **) viene insegnato".
Non è che quello che viene "insegnato" sulla normalizzazione sia... normale sempre ed in ogni caso
Non c'entra un granchè la normalizzazione col tipo dbin un database non relazionale come funziona? eseguo io questa operazione da programma?
Semplicemente fare cose che con un rdbms non fai, neppure con le estensioni (** es. GIS **).ripeto: sarò io un po' con il "paraocchi" o forse non mi sono mai trovato a dover spingere un RDBMS al limite, ma non riesco a capire quali vantaggi potrei avere...
Ti prendo la più banale in assoluto: le varianti degli articoli.
Per non parlare poi di una distinta base con varianti e versioni.
O se preferisci anche un banale albero.
Per non parlare poi di una "vera" applicazione client ad oggetti lascamente collegata al suo db.
Con un rdbms bisogna fare i salti mortali carpiati multipli, con avvitamento, per fare qualcosa di "vagamente" funzionante e, tipicamente, dannatamente complicato.
Si rischia sovente di ricadere nel famigerato detto "se hai un martello tutti i problemi son chiodi"
spesso quando si parla di database non relazionali, non ci si riferisce a db ad oggetti, ma... a db a dati sparsi..
Dal mio punto di vista è meglio una join lenta, piuttosto che una query veloce ma dal risultato errato: è più facile ottimizzare una join lenta che correggere una query "srelazionata" ;-)
non è per nulla semplice, sopratutto se le "relazioni" non sono pre-codificate staticamente, ma "emergono dinamicamente" durante l'uso del db.Originariamente inviato da MacApp
spesso quando si parla di database non relazionali, non ci si riferisce a db ad oggetti, ma... a db a dati sparsi..
Dal mio punto di vista è meglio una join lenta, piuttosto che una query veloce ma dal risultato errato: è più facile ottimizzare una join lenta che correggere una query "srelazionata" ;-)
La "vera" differenza, come già detto, è l'affinamento e smisurata potenza dei db relazionali odierni, non esiste nulla di anche solo vagamente simile in altri campi, che permangono tra l'hobbistico o il superspecialistico
Il fatto e' che non tutte le basi di dati si adattano bene alla struttura di un DB relazionale, e in alcuni casi le relazioni che vanno costruite sono forzature per "usare una vite con un martello" per continuare l'analogia di franzauker.
Prendiamo per esempio un post di un blog. Un post ha alcune caratteristiche fisse (uno schema rigido) che si mappano bene su una tabella: titolo, data di creazione, contenuto, ecc. Gia' quando si passa a considerare i tag si incontra il primo problema: un articolo puo' avere zero o infiniti (teoricamente) tag, ed allo stesso modo i tag si applicano a infiniti articoli. Quindi queste informazioni non si mappano piu' su una tabella, ma - secondo la teoria della normalizzaione - sono necessarie altre due tabelle: una per i tag e una che mette in relazione tag e post. Si creano cosi delle relazioni (dopotutto e' un DB relazionale), ma queste relazioni sono evidentemente artificiose, in quanto necessarie per "spalmare" la struttura naturale di un post (un'entita' che ha una struttura non rigida) in un sistema che non ha un modo naturale per rappresentarla.
Un altro problema e' la gestione delle revisioni. Se vogliamo tenere traccia delle modifiche effettuate nel tempo ad un articolo, con un RDBMS non c'e' un sistema naturale per farlo. Si possono inserire altre entry nella tabella dei post usando un flag per identificare la versione piu' recente, ma anche questa sembra una forzatura dal punto di vista logico (dovrebbe valere "un record = un post", invece si complica la situazione per adattare la vite al martello).
Personalmente non ho ancora avuto esperienza diretta su DB non sql, ma mi sto studiando per interesse personale soluzioni "document oriented" come couchdb e mongodb. Quanto siano validi in produzione rispetto ai RDBMS non saprei dire, pero' sicuramente ci sono casi in cui l'utilizzo di un DB relazionale - prestazioni a parte - non e' la soluzione piu' naturale e porta alla necessita' di aumentare la complessita' in altre zone dell'applicazione (come ad esempio le mille interfacce ORM per mappare oggetti lato applicativo con il layer DB su cui salvarli).
Permessi di invio
Rispondi quotando