Originariamente inviato da tampe125
scusa la domanda stupida: perchè le join sono un problema?
Bhè la risposta è altrettanto "stupida":
perchè son lente
per la modellizzazione ad oggetto esistono molte funzioni dedicate (vedi MySQL & PHP).
Bhè direi di conoscere "benino" mysql, ed è lontano anni luce da un db ad oggetti
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.
Per niente.
"di solito" = "come normalmente (** cit **) viene insegnato".
Non è che quello che viene "insegnato" sulla normalizzazione sia... normale sempre ed in ogni caso
in un database non relazionale come funziona? eseguo io questa operazione da programma?
Non c'entra un granchè la normalizzazione col tipo db
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...
Semplicemente fare cose che con un rdbms non fai, neppure con le estensioni (** es. GIS **).

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"