Su come progettare database (dubbio sulle relazioni...)

[_Mara_]

Ciao a tutti,
spero di non essere OT perchè la mia domanda riguarda più la fase progettazione... e non sono espertissima perciò abbiate pietà se la sparo grossa:D
In un'anagrafica di aziende ho tabella con nome/cognome fornitore (TabAnagAziende). Ha senso creare un'altra tabella solo per le email, con riferimento all'anagrafica tramite chiave esterna, oppure va bene prevedere 2 o 3 campi inTabAnagAziende nel caso di email multiple?
Domanda più generale: non mi chiederanno di conteggiare le email per singolo fornitore, al massimo di stamparle tutte in un riepilogo quindi potrebbe essere giusta la seconda ipotesi?
Ancora più in generale... quando è meglio spostare tutto su una tabella correlata?

Grazie dei consigli :)

Mara

[Nuke987]

Ciao,

Per esperienza tendo sempre a creare una tabella per ogni categoria. Nel tuo caso specifico mi si sono subito accese delle lampadine appena ho letto i termini "azienda" e "fornitori". Già immagino come potrebbe andare a finire...

«Senti siamo noi siamo Pincopallo Srl ma abbiamo un contatto per l'amministrazione, uno per l'assistenza, uno per le pubbliche relazioni ed infine uno per bustarelle»

Oppure...

«Si può fare in modo di inviare le fatture solo al nostro contabile, le bolle di spedizione solo al magazziniere e le richieste libidinose all'amministratore delegato? Lui è un maiale e a queste cose ci tiene»

Per dormire tranquillo farei da subito così:

Tabella agagrafica aziende (nome, cognome, ragione sociale, Tax ID, VAT ID, indirizzo, VIES, intra/extra EU, status, email principale...)
Tabella contatti di ogni azienda in modo tale che ogni azienda è libera di creare tutti i sub-account che desidera. Il che si presterebbe ad eventuali sviluppi futuri nel caso ci fosse la necessità (esempio) di inviare le fatture a determinati contatti designati dall'azienda stessa invece di rompere le scatole a tutti. Può funzionare anche per un sistema di permessi dove account Tizio deve poter fare A ma non B e Sempronio B ma non A.

[-MiStO-]

Ciao,

Per esperienza tendo sempre a creare una tabella per ogni categoria. Nel tuo caso specifico mi si sono subito accese delle lampadine appena ho letto i termini "azienda" e "fornitori". Già immagino come potrebbe andare a finire...

«Senti siamo noi siamo Pincopallo Srl ma abbiamo un contatto per l'amministrazione, uno per l'assistenza, uno per le pubbliche relazioni ed infine uno per bustarelle»

Oppure...

«Si può fare in modo di inviare le fatture solo al nostro contabile, le bolle di spedizione solo al magazziniere e le richieste libidinose all'amministratore delegato? Lui è un maiale e a queste cose ci tiene»

Per dormire tranquillo farei da subito così:

Tabella agagrafica aziende (nome, cognome, ragione sociale, Tax ID, VAT ID, indirizzo, VIES, intra/extra EU, status, email principale...)
Tabella contatti di ogni azienda in modo tale che ogni azienda è libera di creare tutti i sub-account che desidera. Il che si presterebbe ad eventuali sviluppi futuri nel caso ci fosse la necessità (esempio) di inviare le fatture a determinati contatti designati dall'azienda stessa invece di rompere le scatole a tutti. Può funzionare anche per un sistema di permessi dove account Tizio deve poter fare A ma non B e Sempronio B ma non A.

appoggio la risposta di Nuke, direi che è l'approccio migliore anche in vista di sviluppi futuri


Ancora più in generale... quando è meglio spostare tutto su una tabella correlata?

darei un occhio alla normalizzazione dei database, in linea di principio tieni conto che
- se uno o più campi non dipendono totalmente dalla chiave che hai scelto, oppure dipendono da altri campi non chiave
- se la relazione che lega due "informazioni" non è strettamente uno a uno, ma hai attributi multivalore

allora è il caso di creare una nuova tabella

[!fazz]

così in poche parole le relazioni si semplificano con queste 3 regole

1) se due entità hanno una relazione 1-1 si fondono in una sola tabella
2) se due entità hanno una relazione 1-n si mette la chiave di 1 come esterna nella tabella di n
3) se due entità hanno una relazione n-n essa si divide in 2 relazioni 1-n con una tabella intermedia che ha come chiave la somma delle chiavi delle 2 tabelle ed eventuali altri campi per le proprietà della relazione.

nel tuo caso se le mail sono multiple sei nel caso 2 quindi 2 tabelle