Problema gestione dati MySQL per ogni singolo utente

[Vallo]

Ciao a tutti,
sono un neofita di MySQL, e avrei bisogno di un vostro consiglio per risolvere un mio problema di gestione.
sto sviluppando un gioco di carte, e per motivi di sicurezza ho deciso di salvare alcuni dati fondamentali, online, all’interno di un database MySQL.
Per ogni singolo utente avrei bisogno di salvare quantità, livello e uso per ogni carta posseduta (le carte disponibili sono circa 60/70). Il problema è che creando ad esempio una tabella “collezione” mi è impossibile (almeno per le mie conoscenze) inserire in una riga assegnata ad un id utente, 4 dati per ogni singola carta.
L’unica soluzione che mi è venuta in mente è quella di creare una singola tabella per ogni utente, ma a quanto ho capito navigando in rete, sembra non essere una buona idea, e probabilmente andrò incontro a problemi di gestione, memoria e prestazioni.


Avete qualche idea a riguardo?

Grazie!

[optime]

puoi spiegare meglio cosa vuol dire "mi è impossibile inserire in una riga assegnata ad un id utente, 4 dati per ogni singola carta"

[Vallo]

Scusami, cercher� di essere pi� preciso nella spiegazione.

Come ho gi� scritto ho bisogno di salvare nel database la collezione di carte di ogni utente. La collezione di carte comprende tutte le carte presenti nell�app (riconoscibili tramite il loro id. Esempio 1,2,3,4 etc), e dei dati specifici per ogni si gola carta (livello della carta, quantit� della carta posseduta, e se la carta � in uso nel mazzo o no.
Se la collezione era formata ad esempio solo da la quantit� di ogni singola carta, riuscivo tranquillamente a gestire tutto con una singola tabella: come primo dato di ogni riga inserivo l�id utente per la selezione della riga corretta, successivamente creavo tanti campi quante sono le carte presenti nel gioco, e li compilavo con la quantit� di ogni singola carta.
Nel mio caso per� oltre alla quantit�, devo salvare altri 2 campi per ogni carta. Probabilmente potrei creare una tabella enorme contenente per ogni riga, oltre all�id utente, 3 campi per ogni carta (esempio: cartaquantit�1, cartalivello1, cartauso1, cartaquantit�2 etc.), ma visto che le carte sono molte non so se � una buona cosa creare una tabella con potenzialmente 200 o pi� campi.

Visto che non sono ancora pratico di MySQL, volevo chiedere a voi pi� esperti se ci sono metodi consigliati per gestire al meglio situazioni come queste.

P.S.
Non so se pu� servire, ma vi posso gia dire che recupero i dati generando un file json e stampandolo tramite echo in una pagina php.

[optime]

puoi usare una tabella del tipo

IdUtente | IdCarta | IdInformazioneCarta | Valore

così puoi gestire quanti utenti vuoi, quante carte vuoi e quante informazioni per carta vuoi

[Vallo]

puoi usare una tabella del tipo

IdUtente | IdCarta | IdInformazioneCarta | Valore

così puoi gestire quanti utenti vuoi, quante carte vuoi e quante informazioni per carta vuoi

Grazie per la risposta!
Così facendo però non andrei a creare una tabella lunghissima potenzialmente sempre più "pesante" da ciclare? Mi riferisco al fatto che ogni utente (prendendo ad esempio la presenza di 60 carte all'interno dell'app) andrà a generare 60*3=180 (moltiplico per 3 visto che l'informazioni da salvare sono 3: uso, livello e quantità) righe all'interno della tabella. Prendendo sempre per esempio. la presenza di 100 utenti (che comunque può tranquillamente crescere), si andranno a generare 100*180=18000 righe, ed ogni volta che dovrò creare un echo del json della collezione di ogni utente, dovrò andare a ciclare ogni volta una tabella sempre più lunga (il file json deve contenere solo le carte del giocatore, quindi dovrò stampare solo le carte appartenenti all'id giocatore in questione).
Così facendo non vado incontro a nessun problema? O, a questo punto, è meglio creare una tabella con più campi, ma strutturare la ricerca ad una sola riga (quindi un utente a riga come ho detto nel mio precedente post)? O addirittura tornare all'idea iniziale di creare una tabella per ogni utente (anche se così facendo si andrà a creare un numero di tabelle elevato all'interno del db?

Grazie!

[nman]

....... andrà a generare 60*3=180 (moltiplico per 3 visto che l'informazioni da salvare sono 3: uso, livello e quantità) righe all'interno della tabella. Prendendo sempre per esempio. la presenza di 100 utenti (che comunque può tranquillamente crescere), si andranno a generare 100*180=18000 righe,
...........
Così facendo non vado incontro a nessun problema? .........

Assolutamente nessun problema, 18.000 record è solo una tabellina giocattolo
metti un indice sul campo "IdUtente" se devi filtrare su quello

.......... O, a questo punto, è meglio creare una tabella con più campi, ma strutturare la ricerca ad una sola riga (quindi un utente a riga come ho detto nel mio precedente post)? ........

No

......... O addirittura tornare all'idea iniziale di creare una tabella per ogni utente (anche se così facendo si andrà a creare un numero di tabelle elevato all'interno del db? ..........

Assolutamente No

.

[optime]

Un database NON è un foglio excel. I motori dei db fanno più fatica a gestire tabelle "larghe" (tanti campi) piuttosto che "lunghe" (tanti record). Le tabelle non si "ciclano", si interrogano

[Vallo]

Grazie per la precisazione. Vi chiedo ancora scusa, ma come vi ho detto non sono assolutamente un esperto.
Optero per la soluzione che mi avete suggerito senza farmi problemi del numero di righe che si andranno a creare col tempo.

grazie mille

[marino51]

puoi esaminare anche la possibilita di scrivere nella colonna del db la stringa json
1 scrittura, 1 lettura, magari anche 2 o 3 situazioni precedenti come storia, se servono

[Vallo]

Ah, non avevo pensato alla possibilità di salvare direttamente tutta la stringa json. Inserire in una cella una stringa json molto luna può compromettere qualcosa? Oppure è sempre meglio optare per l'opzione suggerita da optime?

Cosa intendi per "1 scrittura, 1 lettura, magari anche 2 o 3 situazioni precedenti come storia"?