Visualizzazione dei risultati da 1 a 9 su 9
  1. #1

    Come creare un database relazionale mysql che gestisce le amicizie con utenti iscritt

    Salve, mi hanno chiesto di creare un sito simile a www.couchsurfing.org, un sito che ti permette di dare disponibilità di un letto dove far dormire a chiunque tu voglia tra coloro che ti fanno richiesta tramite il sito, così da poter dare la possibilità di risparmiare nel costo del posto letto se un turista visita la tua zona. Questo sito prevede quindi la possibilità di diventare amici di altri utenti e di comunicare con loro tramite dei messaggi di posta privata dal sito direttamente. Ora, il mio dubbio principale è come creare un database relazionale che gestisca i messaggi di posta inviati e ricevuti di ogni utente.
    Devo creare una tabella per ogni utente? Tipo:
    tabella messaggi_utente_francesco_35:

    id_messaggio,
    stato_messaggio (inviato-ricevuto),
    oggetto,
    contenuto

    oppure dovrei fare una tabella unica per tutti i messaggi di tutti gli utenti?
    tabella messaggi:
    id_messaggio,
    id_utente,
    stato_messaggio(inviato-ricevuto),
    oggetto,
    contenuto

    Per ciò che riguarda invece le info di ogni utente, dovrei creare una tabella per ogni utente o posso semplicemente creare una tabella utenti generale? Del tipo:
    id_utente,
    email,
    name,
    lastname,
    general_info,
    disponibilita_letto,
    interessi,
    ecc...

    sapete inoltre consigliarmi un sito dove possono inseganre a creare la struttura di complicati database relazionali? Grazie.

  2. #2
    una tabella per utente o una tabella per messaggio ovviamente sono soluzioni da scartare. di solito si fanno tabelle generali (utenti e messaggi nel tuo caso)


  3. #3
    Ti ringrazio innazitutto per la risposta celere, ma per capire meglio, quindi vuoi dare che nella tabella messaggi ci sarà una lunghissima lista di messaggi di ogni utente registrato al sito che verrà interrogato ogni qualvolta un utente vorrà leggere i suoi messaggi? Quindi devono essere tutti insieme? Poi vuoi dire anche che nella stessa tabella messaggio ci sarà anche un campo magari che stabilisce che il dato messaggio sarà "letto", "da leggere" o "eliminato"? Grazie.

  4. #4
    certo esatto, non è infrequente che in una tabella ci siano milioni di righe. non farti spaventare dal numero, non è che dovrai leggere tutta la tabella per trovare i messaggi dell'utente "x"...

    ad esempio, per leggere i nuovi messaggi inviati all'utente "x" basterà fare

    SELECT messaggio FROM tabella_messaggi WHERE utente_destinatario='x' AND Letto=False

    (è un esempio, ok?)

  5. #5
    Grazie infinite optime, ora devo studiare una struttura efficace per il mio database. Probabimente potrei disturbarti ancora in futuro . Che bello che ci sia questa solidarietà tra i programmatori, se non ci fossero questi forum sarei stato perso un milione di volta. Grazie ancora per l'aiuto.

  6. #6
    Scusa se riapro il post Optime, quindi riassumendo mi consigli di aprire una tabella utenti con le informazioni principali e poi una tabella messaggi che si referenzia alla prima con l'id dell'utente (ad esempio)? Quanto campi può contenere una tabella? Ti chiedo questo perché sembra che per il sito che dovrò creare ci saranno veramente tanti campi da inserire. Sembra che l'utente dovrà inserire una vasta varietà di informazioni per poter raffinare la ricerca di chi sta cercando ciò che esso offre. Mi potresti consigliare anche un web hosting che offre un servizio che possa sostenere un numero elevato di visite al giorno e che permetta l'inserimento di migliaia/milioni di righe in una tabella senza rallentare il servizio? A presto.

  7. #7
    1. quanti campi? http://dev.mysql.com/doc/refman/5.0/...unt-limit.html
    2. quale hosting? per regolamento non se ne può parlare (pubblicamente, in privato ovviamente sì )


  8. #8
    Originariamente inviato da optime
    1. quanti campi? http://dev.mysql.com/doc/refman/5.0/...unt-limit.html
    2. quale hosting? per regolamento non se ne può parlare (pubblicamente, in privato ovviamente sì )

    Immaginavo :-) Grazie per la dritta su quante colonne, sono sufficienti allora quelle che mi servono. :-)

  9. #9

    creazione database

    Salve, ho un altro quesito. Mi sto chiedendo come devo suddividere la struttura del mio database per un sito simile a couch surfing org, cioè un sito che permette di mettere in contatto persone alle quali piace viaggiare e che offrono un posto letto a persone che lo cercano in quella determinata zona dove è offerto. Ho creato l'account per ogni utente con le seguenti informazioni:

    utenti:
    id_utente
    username
    password
    nome
    cognome
    località
    etc...

    Ora mi trovo a dover inserire altre informazioni per aiutare gli utenti a far capire chi sono coloro che li ospitano. Queste informazioni sono le seguenti:

    Personal Description (TEXT)
    Interests (TEXT)
    favorite scripture (TEXT)
    hosting information (TEXT)
    disponibilità
    status
    età e sesso
    lingue
    Music, movies, books
    best quote (TEXT)
    I attend to church
    last login
    username
    education (TEXT)
    occupation (TEXT)
    hosting information (TEXT)
    hosting available
    member since
    ethnicity
    spoken languages

    Scusa se sono un po' in inglese e un po' in italiano :-) La mia domanda è se inserire tutte queste informazioni nella stessa tabella utenti, quindi aggiungere colonne alla tabella utenti già creata, o creare una nuova tabella nominata magari "hosting information" e collegarla alla prima tramite un campo "user_id". Tieni presente che la maggior parte dei campi sopra sono di tipo TEXT, per cui ho timore che ogni utente inserisca troppe informazioni e il database non riesca ad accettarli. Non è che ho quella grande dimestichezza nel creare database di grandi dimensioni :-)

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.