wow, grazie a tutti sta diventando una discussione interessante...non sono un guru di sql ma dalla discussione ho preso un paio di spunti molto interessanti, cmq sto studiando bene come organizzare le tabelle, minimo 2 poi vediamo se suddividere il tutto in 3 come detto da html5today

domanda !!

ponendo il caso di 3 tabelle !

utenti
utnPFisica
utnPGiuridica

Volendo fare un join tra la tabella utenti e la tabella associata all'utente inche modo mi comporto ?

devo fare un join a 3 tabelle ? es...

select * from utenti inner join utnPFisica on utenti.id = utnPFisica.utente_id inner join utnPGiuridica on utenti.id=utnPGiuridica.utente_id where utenti.id = 10

giusto ?

Direi proprio di no

Il vantaggio di questo approccio è dividere "logicamente" i dati relativi ad una categoria rispetto i dati relativi all'altra quindi la JOIN la devi fare solo con la tabella corrispondente al "tipo utente" specifico.

Inoltre la tua query non funzionerebbe perchè delle tue due JOIN una sarebbe sempre "falsa" dal momento che ad ogni utente può essere associato solo un record di una delle due tabelle (cioè un utente può essere solo persona fisica o persona giuridica e non entrambi, giusto?)

Ovviamente nel tuo PHP devi avere la "logica" per decidere quale tabella interrogare - oppure usare due query, interrogando prima la tabella "utenti" (dove avrai un campo "tipo") e poi la tabella "giusta" in base al "tipo" utente.

Una considerazione: tutta la discussione avuta sino ad ora è un po' "di scuola" quindi può darsi che in alcune applicazioni pratiche sia più conveniente violare le regole di normalizzazione a vantaggio di una maggior efficienza o manutenibilità del codice. Se ad esempio tu mostri spesso gli utenti in liste indifferentemente dalla loro tipologia oppure non sai a priori (per es. avendolo nella sessione o passandolo come parametro) la tipologia di utente da mostrare potrebbe essere più conveniente avere tutto in un'unica tabella. La scelta dipende dall'implementazione, da considerazioni di efficienza e, in ultima e più importante istanza, dalle tue preferenze.

ok, grazie !

eccomi ritorno ehehe

allora altro dubbio.... il software deve gestire dei pagamenti.. ovvero gli utenti devono eseguire un tesseramento per poi poter richiedere delle autoriazioni....

io avevo in mente di fare un'unica tabella pagamenti da agganciare poi con due tabelle, alle tabella Tesseramenti e Autorizzazioni

Tabelle : Tesseramenti, Autorizzazioni, Pagamenti
Tabella di collegamento :

• Associazione_Tesseramenti : che collega l'id della tessera al pagamento sulla tabella pagamenti

• Associazione_Autorizzazioni : che collega l'id dell'autorizzazione al pagamento sulla tabella pagamenti

Un approccio del genere è giusto ? Suggerimenti ?

@rambco said:

eccomi ritorno ehehe

allora altro dubbio.... il software deve gestire dei pagamenti.. ovvero gli utenti devono eseguire un tesseramento per poi poter richiedere delle autoriazioni....

io avevo in mente di fare un'unica tabella pagamenti da agganciare poi con due tabelle, alle tabella Tesseramenti e Autorizzazioni

Tabelle : Tesseramenti, Autorizzazioni, Pagamenti
Tabella di collegamento :

• Associazione_Tesseramenti : che collega l'id della tessera al pagamento sulla tabella pagamenti

• Associazione_Autorizzazioni : che collega l'id dell'autorizzazione al pagamento sulla tabella pagamenti

Un approccio del genere è giusto ? Suggerimenti ?

Ciao, l'approccio è ideologicamente corretto, tuttavia è ridondante fare 2 tabelle per gestire gli abbinamenti, ne basta una strutturata ipoteticamente così come segue.

**id | tipo | id_assoc | pagamento**
```Dove:

- **id **è l'identificativo univoco della riga;
- **tipo **identifica la tipologia di abbinazione (tesseramento/autorizzazione);
- **id_assoc **è l'id da abbinare del tesseramento/autorizzazione in questione;
- **pagamento **è l'id associato al pagamento in questione.


Spero sia abbastanza chiaro ;-)

mmm anche potrebbe essere un'ottima soluzione per risparmiare tabelle

Chiaro che tutto dipende dall'applicazione che si intende sviluppare.
A seconda del contesto alcune logiche ridondanti possono essere più performanti su numeri sconfinati mentre in medio-piccole applicazioni non conviene in quanto il numero "esiguo" di record non comporta problemi prestazionali risultando spesso invece il metodo più rapido per gestire la cosa.

Sta all'abilità di chi struttura il database prevedere in base alla vastità dell'applicazione, e al numero di record che si aspetta di immagazzinare, di creare una determinata logica di archiviazione relazionale, al posto di un altra, al fine di poterne ottimizzare al meglio le operazioni sui dati ivi archiviati.

Hai ragione, comunque rapportarsi con gli altri serve anche a capire le varie metodologie con cui affrontare il problema no

@rambco said:

hai ragione, cmq rapportarsi con gli altri serve anche a capire le varie metodologie con cui affrontare il problema no

Motivo per cui è stata mia premura esprimere il precedente concetto, magari arriva qualcuno che mi smentisce/corregge e mi apre un mondo nuovo.

Se mi sono posto lasciando intender male, ti chiedo scusa

No figurati anzi.