consiglio struttura tabella

[sitodue]

ok... la terza tabella mi viene in questo modo:

iduser|idfrutto|quantita
001|mele|300
001|pere|0 ->il record indica che in passato c'erano, altrimenti nn ci sarebbe, giusto?
001|arance|100
002|pere|0
002|arance|200
003 -> nessun record

E' corretto così?
in effetti i records saranno sempre meno di num utenti * num frutti...
Uhm...uhm... mi resta il dubbio dell'altra tabella, quella che contiene solo l'elenco del nome frutto... in quali casi la utilizzo? questa tabella così com'è mi da già tutte le informazioni di cui necessito... Cosa mi sfugge ancora?

[optime]

Originariamente inviato da sitodue
001|pere|0 ->il record indica che in passato c'erano, altrimenti nn ci sarebbe, giusto?

ma ti interessa anche avere lo storico?

[sitodue]

Originariamente inviato da optime
ma ti interessa anche avere lo storico?

Non proprio lo storico ma devo poter cogliere la differenza tra "non aver mai avuto" e "aver avuto in passato" per questo all'inizio avevo pensato ad un flag per ogni frutto;

Pippo con 0 mele adesso;
Pippo con 0 mele adesso ma che ne ha avute in passato;

sono due cose diverse per quello che devo fare...

In effetti così com'è la tabella è uguale al secondo esempio che avevo postato all'inizio, ma con due campi in meno che effettivamente erano ridondanti... Per questo credo di non aver capito bene i suggerimenti... O forse a questo punto nn ho spiegato bene la problematica...

[optime]

direi la seconda

[franzauker2.0]

Originariamente inviato da optime
direi la seconda

Direi che era scritto fin dal primo post

Il flag si/no abbinato ad ogni frutto non mi indica solo la presenza attuale, ma anche l'eventuale presenza passata, quindi non posso rinunciarvi (o almeno non saprei in che modo sostituirlo).

[sitodue]

Originariamente inviato da franzauker2.0
Direi che era scritto fin dal primo post

Grazie :-D
mi stavo convincendo di essere pazzo!
Alla luce di questa riscoperta, resto col dubbio di quale delle 2 tabelle che ho proposto all'inizio sia più corretto implementare...
Ovviamente eliminando i campi ridondanti come iduser e nomeuser...
Anche se forse meno corretta e più difficile da "manutenere" credo che la prima sia la migliore...
Se ad esempio devo inserire un utente nuovo con 20 tipologie di frutti differenti, mi basta un'unica insert, mentre con la seconda tabella dovrei farne 20...

[optime]

un po' dipende anche dalle query che devi fare

se devi solo visualizzare la situazione dell'utente, una SELECT * sulla prima struttura è sicuramente più immediata. se invece ti interessa anche sapere chi ha mele (e quante) la seconda struttura si presta meglio.

dacci qualche info in più

[sitodue]

Per similitudine faccio l'esempio di un mercato, dove ogni user è una banco con varie tipologie di frutti, soggetti a compravendita continua, quindi principalmente SELECT per visualizzarne a video le quantità e UPDATE per modificarle. Più limitatamente INSERT, perchè un record una volta aperto resta aperto, anche se la quantità scende a 0 (Come dire che un banco che ha iniziato a vendere mele, anche se al momento non ne ha, è comunque un banco che vende anche mele - da qui il famoso flag che testimonia l'eventuale presenza in passato di quella tipologia di frutto... che mi indica che quell'oggetto in quel determinato banco è stato "startato"... "inizializzato"... a prescindere dalla sua presenza attuale o meno)

[sitodue]

Aggiungo delle considerazioni;
Le query saranno create dinamicamente tramite php;
Ho fatto dei tentativi ieri con entrame le tipologie di tabelle, con il risultato che, nel primo caso (con la tabella orizzontale per intenderci) il codice è più pulito, ma creare la query è estremamente più difficoltoso a causa dell'alternanza tra frutti e flag... e anche posizionare prima tutti i frutti e poi tutti i flag, non migliora la cosa;
Nel secondo caso invece (con tabella verticale) le query sono molto più facili da creare, ma ogni volta che mi trovo a dover inizializzare un utente con molti frutti, o anche a modificare molti frutti sullo stesso utente, mi trovo a dover gestire 20-30-40 query per una singola operazione... :-s

Forse un compromesso potrebbe essere creare 2 tabelle simili:

utente|frutto1|frutto2|frutto3|ecc

utente|flag1|flag2|flag3|ecc

In questo modo avrei praticamente 1 query per ogni operazione per utente, ma ripetuta 2 volte, in quanto la struttura sarebbe praticamente identica e abbastanza semplice da realizzare...

[optime]

l'inizializzazione potresti ottenerla facilmente con tre tabelle (INSERT...SELECT JOIN) - vedo che riesci facilmente da solo a fare le tue prove, quindi prova e vedi cosa è più conveniente per te