Newsgroup: it.comp.www.php
Titolo: Tabella con 365 colonne

In MySQL, parlando di prestazioni e gestibilità, è "ammissibile" una tabella
con 365 colonne ed un migliaio di righe? Servirebbe per mostrare (a mò di
statistiche) il numero di un certo tipo di operazioni compiute dagli utenti
giorno per giorno. Ci sono altre soluzioni per immagazzinare questo tipo di
dati?
Ancora, per ogni utente ho la necessità di memorizzare altri dati (ogni IP
di accesso, alcuni tipi di campi compilati... diciamo un centinaio di
informazioni); per questo avevo pensato, probabilmente sbagliando, di creare
una tabella per ogni utente... ma dopo mi verrei a trovare con 1.000
tabelle, se gli utenti aumentassero. Non diventa poi incasinato e poco
performante?
Grazie!



Crea una tabella per gli utenti, un record per utente, in cui metti le
solite cose, nome cognome login, se ti servono e soprattutto metti una
chiave (che spesso viene chiamata id) intera non nulla, con autoincrement
etc . 
Crea una tabella per la registrazione delle attivita' in cui metti una
nuova chiave (che non fa mai male) e un campo che puoi chiamare id_utente
che andrai a riempire con l'id dell'utente che stai monitorando. In questo
record metti quindi data, ip, tipo attivita', etc etc etc.
Un cosiglio. Leggiti un buon libro di base sui db relazionali.
Ciao.
	-Ema-

 dati?
Non è ammissibile e sarebbe pure una soluzione stupida.
Comprati e studiati un bel manuale di database relazionali.
Ciao
Marco

 ha scritto nel messaggio
news:c0d1ce$58k$1...@newsreader.mailgate.org...

Ciao Marco, cerco un buon libro e lo compro!
Però mi diresti perchè ti sembra non ammissibile e stupida, come soluzione?
Cioè come memorizzeresti i valori per ogni giorno, utente per utente?
Trascorso un anno non serviranno comunque 365 colonne (una per giorno)?

 performante?
   Direi di sì, anche questa volta. Ti suggerisco, en passant, di dare 
un'occhiata a qualche libro che parli di basi di dati relazionali, in 
modo da apprendere teoria e pratica di quello che stai, a quanto pare 
autodidatticamente, cercando di fare. Un buon esempio, è, di Atzeni & 
Al., "Basi di dati", ed. McGraw Hill. Inoltre, quesiti di questo tipo, 
probabilmente, trovano risposte più pronte ed esaurienti sul gruppo 
deidicato ai database.
   Nel tuo caso specifico, ti suggerisco di separare, ancora una volta, 
quello che gli utenti "sono" da quello che, invece, "fanno": ti può 
essere di nuovo utile l'esempio di cui sopra.
-- 
Alla prossima,
Marco

 Trascorso un anno non serviranno comunque 365 colonne (una per giorno)?
Perchè i database non vanno progettati alla membro di segugio.
Bisogna seguire regole precise per avere delle strutture solide, funzionali
ed espandibili.
Dettaglia maggiormente il tuo problema se vuoi un'idea di soluzione.
- Cos'è un utente e quali informazioni vuoi memorizzare
- Che cosa fa l'utente nel sistema
- Con quale cadenza l'utente svolge le azioni
Ciao
Marco

Trascorso un anno non serviranno comunque 365 colonne (una per giorno)?
In poche parole:
Tabella utenti:
id_utente utente
Tabella Operazioni:
id_operazione operazione data
Tabella utenti_operazioni:
id_utente id_operazione
Ciao
Francesco
_____________________________________
http://www.altropc.it
 - Un altro PC è possibile!
Software libero, PHP, MySQL, Webdesign, Sicurezza, CMS, Tutorials
Per rispondere in e-mail togli NOSPAM 

 ha scritto nel messaggio
news:RsnWb.219176$VW.89...@news3.tin.it...

scindi il problema in piu tabelle, cosi hai un db che è un mattone
innanzitutto gli utenti se ne stanno in una tabella a parte
i giorni in un altra (anche perche far un'anno cosa fai, cancelli tutto?)
e quelle 1000 righe cerca di compattarle sicuramente avranno dati
ridondanti, studiaci un po su e leggi qualche libro.
puoi vedere fondamenti di sql della mcgrawhill (se non erro, collana
frrecodeonline ha il lato giallo) che è semplice e completo.
relaziona il tutto con collegamenti chiave-valore , probabilmente avrai
necessita di relazionare molti a molti (ma non ho visto i dati, quindi
potrei sbagliarmi, magari basta una normalizzazione fatta bene)

 ed espandibili.
Per esempio: cosa succede se per caso un anno diventa di 366 giorni? :)
Benvenuti nel 2004! :D
Bye.

> Per esempio: cosa succede se per caso un anno diventa di 366 giorni? :)
Appunto.
Ciao
Marco


Per esempio: e se un Personal Computer dovesse mai avere un fabbisogno 
di memoria superiore a 640 kb?
Tac

Trascorso un anno non serviranno comunque 365 colonne (una per giorno)?
Quest'anno allora ti servono 366 colonne.
Matteo
------------------------------------
Peggio pe' voi che me ciavete messo!
Silenzio! e rispettate er Presidente!
------------------------------------

Trascorso un anno non serviranno comunque 365 colonne (una per giorno)?
Ad esempio puoi avere una tabella di 3 colonne:
- data
- utente (username ad esempio)
- tot operazioni
Ciao


 id_utente id_operazione
da uno schema fatto se non sbaglio con queste tre tabelle praticamente 
dovrebbe essere possibile ad ogni utente aggiungere o togliere una 
operazione  e per ogni operazione archiviare molte date.
Pero' quali relazioni si usano e tra quali colonne?
Inoltre mysql supporta le relazioni?
e se io cancello ad esempio una operazione a catena si cancellano i 
rispettivi record della tabella relativa?

rispettivi record della tabella relativa?
No, vanno cancellati a mano.
Ciao
Francesco
_____________________________________
http://www.altropc.it
 - Un altro PC č possibile!
