Progetto DataBase e JOIN

[wizardGIO]

Buongiorno ragazzi sto studiando per l'esame di Basi di Dati ed ho bisogno di alcuni Consigli sul progetto di un database. IL Database è per tenere una base dati della canzoni che mano mano sono passate attraverso una WEB RADIO. Ora io nel progetto ho utilizzato la metodologia(E/R). Ho costruito un database già abbastanza normalizzato ma questo mi costringerà a fare un bel Pò di JOIN per visualizzare alcune informazioni richieste.

Ad esempio se voglio vedere i dettagli delle canzoni dovrò fare JOIN tra le tabelle CAnzone,Genere,Copyright,Nazione etc....sono esattamente 6 più una concatenata(prima una join Artista Album e poi canzone).

Ho allegato la prima bozza di database. Dovrei dimistuire il numero di Join da eseguire secondo voi? Esiste una qualche Best Practice che mi dice quante JOIN è conveniente eseguire in un unico comando SQL?

HO fatto alcuni esercizi di SQL ed ho visto che al posto del JOIN è spesso usato il Prodotto Cartesiano condizionato(se non sbaglio tetha-join) c'è una regalo che mi dice quando meglio utilizzare l'uno e quando l'altro?

Grazie Gio

[Joe Taras]

Originariamente inviato da wizardGIO
Buongiorno ragazzi sto studiando per l'esame di Basi di Dati ed ho bisogno di alcuni Consigli sul progetto di un database. IL Database è per tenere una base dati della canzoni che mano mano sono passate attraverso una WEB RADIO. Ora io nel progetto ho utilizzato la metodologia(E/R). Ho costruito un database già abbastanza normalizzato ma questo mi costringerà a fare un bel Pò di JOIN per visualizzare alcune informazioni richieste.

Ad esempio se voglio vedere i dettagli delle canzoni dovrò fare JOIN tra le tabelle CAnzone,Genere,Copyright,Nazione etc....sono esattamente 6 più una concatenata(prima una join Artista Album e poi canzone).

Ho allegato la prima bozza di database. Dovrei dimistuire il numero di Join da eseguire secondo voi? Esiste una qualche Best Practice che mi dice quante JOIN è conveniente eseguire in un unico comando SQL?

HO fatto alcuni esercizi di SQL ed ho visto che al posto del JOIN è spesso usato il Prodotto Cartesiano condizionato(se non sbaglio tetha-join) c'è una regalo che mi dice quando meglio utilizzare l'uno e quando l'altro?

Grazie Gio

Quando progetti una base di dati devi rispettare le forme normali. Di contro aumentano la join ma devi tenere conto che le estrazioni "pesanti" per incroci di dati ed analisi non devono rientrare nella logica di un database OLTP (quelli che si usano in produzione) ma bensì in un OLAP (DB per datawarehouse) che non seguono la logica della normalizzazione ma bensì della ridondanza. Per me l'E/R che hai scritto sta bene.

[wizardGIO]

Il corso è stato molto teorico e poco pratico, ed il passare ad un progetto vero mi ha posto dei dubbi sui join. A lezione infatti il prof ci ha accennato che eagerare nella normalizzazione provoca dei problemi prestazionali a causa dei JOIN, percui a volte si decide di accettare una qualche ridondanza che a sua volta andrà gestita.

Ora il mio dubbio è tradurre il modello E/R bel modello relazionare farà si che per recuperare i dettagli di ogni singola canzone dovrò fare dei JOIN concatenati uno deitro l'altro



((CANZONE JOIN ALBUM ON ....)JOIN provenienza ON......)JOIN ......JOIN......ETC....

iL MIO DATABASE NON SARA' ENORME MA INSOMMA......

[Joe Taras]

Originariamente inviato da wizardGIO
Il corso è stato molto teorico e poco pratico, ed il passare ad un progetto vero mi ha posto dei dubbi sui join. A lezione infatti il prof ci ha accennato che eagerare nella normalizzazione provoca dei problemi prestazionali a causa dei JOIN, percui a volte si decide di accettare una qualche ridondanza che a sua volta andrà gestita.

Ora il mio dubbio è tradurre il modello E/R bel modello relazionare farà si che per recuperare i dettagli di ogni singola canzone dovrò fare dei JOIN concatenati uno deitro l'altro



((CANZONE JOIN ALBUM ON ....)JOIN provenienza ON......)JOIN ......JOIN......ETC....

iL MIO DATABASE NON SARA' ENORME MA INSOMMA......

Lo so, bisogna valutare caso per caso. Personalmente la ridondanza la accetto solo quando per ottenere un valore evito una procedura complessa

[optime]

sulla *singola* canzone le JOIN pesano poco. dovrai invece usare degli accorgimenti quando l'elaborazione coivolgerà tanti elementi