Design di un DB per posta interna

[Bukowski]

Ciao a tutti,
devo accingermi a creare una messaggistica interna per un mio portale abbastanza grande.

La classica possibilità di scriversi tra utenti, con posta in entrata e posta in uscita.

Sto nella fase più importante, ovvero quella di disegnare il DB.

In realtà non ho ancora capito quale è la strada migliore da seguire, soprattutto per via della posta IN USCITA.

Come ci si comporta in questo caso? Visto che uno dei 2 potrebbe cancellare il messaggio, è ovvio che debbono girare sempre due copie, o no???

Ho pensato anche ad una sola copia del messaggio con un FLAG per uno e l'altro utente.

Inoltre mi sarebbe piaciuto raggruppare i messaggi in un'unica discussione (alla facebook per intenderci) quindi una sorta di sistema a thread .. ma poichè mi aspetto una mole di messaggi molto importante ho paura anche di "joinare" troppo, sia per recuperare tutta la discussione, sia quando nel messaggio in entrata devo recuperare i dati del mittente e del destinatario.

Qualche mente brillante sa darmi qualche dritta per risparmiare risorse il più possibile alle macchine?

Grazie!!

[Virus_101]

Quello che domandi si chiama "Software engineering" ed e' una delle cose piu' costose dell'informatica.

Sinceramente e' meglio se cerchi qualcosa di gia' fatto, anche eprche' un sw del genere e' molto grande e se non sai da dove partire o usi qlkosa che esiste gia' o paghi qlkuno per farla.

Cio che domandi e' una progettazione fatta e finita di dab e sw per il tuo portale ?
Mi spiace ma a mio avviso una cosa del genere costa anche parecchio.

[Bukowski]

Ciao,
forse non mi sono spiegato bene

Non cerco una cosa fatta, la faccio da me

Cercavo solo di inquadrare come sarebbe, in termini logistici, il miglior modo per farla.

[Virus_101]

Uhm ok pero' la mi risp rimane cmq valida.

Alla fine ti devi progettare lo schema del database, pensare ai possibili problemi etc ....
Sinceramente ribadisco quanto detto sopra.

Prova a proporre cosa pensavi di fare e vediamo.

Ovviamente devi considerare che le tabelle "esplodano" anche perche' con messaggistica istantea cio' puo' succedere.

[Bukowski]

Beh, in realtà un'idea ben precisa ancora non ce l'ho.

Immaginavo qualcosa del tipo

# TABELLA_POSTA

IDMSG | ID_THREAD | ID_MITT | ID_DEST | NICK_MITT | NICK_DEST | SOGGETTO | MSG | DATA | LETTURA | ELIMINAZIONE

Con id_thread controllo tutto il thread.
Id nick mi serve per evitare join troppo pesanti in fase di lettura.
Lettura per sapere se è stato letto oppure no.
Eliminazione, qui controllo chi dei 2 l'ha eliminato e conseguentemente cancello il thread.

Il fatto è che una tabella così mi sembra troppo "semplicistica" per funzionare correttamente. No?

[Virus_101]

mmmmmm non e' un discroso di diea semplicistica, e' prorpio un discorso di normalizzazione della base di dati.

Io sinceramente vorrei un po' sfatare il mito che le join siano pesanti.
Ho visto rallentamenti sono quando fai join rta colonne di tipo diverso oppure con charset diversi.

Per il resto le join sono performanti e ti risolvono un sacco di problemi e sono una necessita' in base di dati relazionale ben progettata e ben normalizzata.

io farei una cosa del tipo :

tabella utenti

tabella threads

tabella utenti_threads


la tabella utenti_treads e' una bella tabellozza di relazione che relaziona i vari utenti ai vari threads.
Ovviamente a doppia via cioe' chi invia un dato sara' il mittente chi lo ricave il destinatario.
Potrai tracciare cosi' tutto quello che ti pare da chi sta partecipando a che discussione etc..
Inoltre con degli accorgimenti ptrai anche gestire discussioni con piu' utenti.
Ogni messagio ha un suo intero che ne indica la sequenza, e ogni utente potra' quindi ricavare i vari messaggi spediti.

Pensaci.

[Bukowski]

Mmm .. però cosi avrei delle JOIN su 3 tabelle anzichè su 2, al momento in cui si aprirà il messaggio.

Query sul Thread joinata sull'utente mittente che a sua volta viene joinata con la relazione tra queste attraverso utenti_thread.

Non sarebbe meglio a questo punto una sola tabella come ho indicato nel primo esempio?

[tokki]

Io non credo che un join su 3 tabelle anzichè 2 sia un gran problema di performance, è meglio a mio avviso avere il db strutturato bene.

Sono d'accordo con Virus_101 sull'utilizzo delle 3 tabelle e terrei i flag per decidere se un thread è stato consegnato (letto) e/o cancellato.

Comunque concordo anche sul fatto che sia un lavoro complicato... e che si chiama "Ingegneria del Software"

Ciao


__________________________________________________ ______
Parma