Problema mysql e date

[keratox]

Ho una tabella che definisce un utente.
In questa tabella c'è un campo timestamp di 'data_registrazione'.
Come mai ogni volta che applico modifiche all'user (anche da phpmyadmin), mi aggiorna la data del timestamp ?
Come risolvo questo problema?

Ciao

[gm]

E' il normale comportamento del tipo TIMESTAMP

http://dev.mysql.com/doc/mysql/en/Co...s.html#IDX1109

[keratox]

mmh grazie ci ho dato un'occhiata
se non mi sbaglio dice che viene automaticamente aggiornato il primo campo timestamp, quindi l'unica soluzione e' quella di inserire un altro campo timestamp da non utilizzare ?

[daniele_dll]

non fai prima a inserire tipo un campo INT 10
e quando lo devi aggiornare con l'update/insert usi UNIX_TIMESTAMP (sempre da mysql) ?

[albertogianotti]

ma usare il campo DATETIME?!

Perchè complicarsi la vita con le timestamp se devi solo scrivere la data e l'ora??

E comunque ci sono milioni di modi per fare operazioni con le date in formato DATE TIME O DATETIME...

[daniele_dll]

Originariamente inviato da albertogianotti
ma usare il campo DATETIME?!

Perchè complicarsi la vita con le timestamp se devi solo scrivere la data e l'ora??

E comunque ci sono milioni di modi per fare operazioni con le date in formato DATE TIME O DATETIME...

xche il campo è piccolo...usa quindi poco spazio...ed essendo numeri è molto + facile da gestire e mysql, quando devi fare operazioni, è molto + veloce

xche invece di fare...ad es

data + 1 Day

fai

data + (60*60*24)

è il parser di mysql è molto + veloce a gestire una somma con 2 moltiplicazioni che a interpretare quello, scomporre la data, eseguire la somma del giorno, controllare se il mese è passato xche in caso deve aumentare di mese e impostare i giorni ed infine ricomporre la data

[albertogianotti]

si può anche darsi;

intanto non bisogna sempre e perforza ragionare in questo modo, bisogna studiare prima di tutto il sistema sul quale deve funzionare:

[se mi parli di una gestione di 10000 utenti con una manipolazione di date al minuto allora posso anche capirlo ] ...primo...

e poi anche il fatto che per fare un programma non posso diventare scemo a fare milioni di operazioni per risparmiare 0.0002 secondi a operazione o per alleggerire il carico macchina (se mi va bene) dello 0,001%...
Comunque per questo ti rimando al punto di cui sopra...


(però sul fatto che il campo è piccolo non sono del tutto d'accordo mi sa che è piu lungo un INT 11 che un DATE....)

ciao

[daniele_dll]

Originariamente inviato da albertogianotti
si può anche darsi;

intanto non bisogna sempre e perforza ragionare in questo modo, bisogna studiare prima di tutto il sistema sul quale deve funzionare:

[se mi parli di una gestione di 10000 utenti con una manipolazione di date al minuto allora posso anche capirlo ] ...primo...

il problema non è tanto della modifica a se stante...ma
1° Se ti serve come chiave primaria un'indice su un numero è MOLTO + performante
2° Occupa meno spazio
3° Le elaborazioni numeriche sono sempre MOLTO meno pesanti di una operazione su stringa

inoltre il ragionamento che fai è parzialmente errato...xche se uno ragiona cosi...allora non gli frega niente di scrivere codice ottimizzato e funzionante
xche risparmi memoria li...ma la fai risparmiare anche al programma...e tenendo conto che il codice gira in hosting insieme a mille siti...quanto + leggero lo riesci a fare meno carichi la macchina + veloce va

e poi anche il fatto che per fare un programma non posso diventare scemo a fare milioni di operazioni per risparmiare 0.0002 secondi a operazione o per alleggerire il carico macchina (se mi va bene) dello 0,001%...
Comunque per questo ti rimando al punto di cui sopra...

Non devi diventare scemo a fare milioni di operazioni...xche basta che adotti delle misure che esegui per abitudine e ti assicuro che ti verra spontaneo...

e poi non vedo cosa c'è di diventare scemo nel fare + (60*60*24) invece di + 1 DAY

(però sul fatto che il campo è piccolo non sono del tutto d'accordo mi sa che è piu lungo un INT 11 che un DATE....)

un date tiene solo la data...un INT può tenere tutto...ed inoltre un INT è SOLO 4 byte
il paragone tra INT e DATE non lo puoi fare
Se non erro un DATE è 3 byte...un bute in meno ma tiene fuori un sacco di informazioni (ore, minuti e secondi)

tra un INT e un DATETIME si

ognuno la pensa come vuole lui e si comporta di conseguenza...ma forse quando ti troverai a dover fare un programma che deve tenere carichi eccessivi capirai che è meglio avere un'abitudine di base nel fare queste cose e non pensarci dopo

ti può sembrare scemo...ma io uso gli apici singoli al posto di quelli doppi dove nn servono variabili o simili
uso il mysql_fetch_assoc o row x risparmiare memoria al posto di mysql_fetch_array

sono piccole cose...ma quando ti servono...non ti verrà "naturale" e li perderai il triplo del tempo

invece prendere l'abitudine a fare cosi ti costa molta meno fatica xche la puoi prendere con calma in compenso il tuo codice viene scritto OTTIMIZZATO già alla partenza senza bisogno di far giri e rigiri

[daviweb]

Originariamente inviato da daniele_dll
non fai prima a inserire tipo un campo INT 10
e quando lo devi aggiornare con l'update/insert usi UNIX_TIMESTAMP (sempre da mysql) ?

Ciao!

Utilizzando questa query
"SELECT FROM_UNIXTIME(start_date) as ciccio FROM ibf_topics"
mi viene restituita la data in questo formato "28/09/2004 15.17.02". Perfetto!

Se voglio inserire o aggiornare un record, con questa
"INSERT INTO ibf_topics (start_date) VALUES (UNIX_TIMESTAMP(now()))"
inserisce il valore corretto.

Ma se volesi inserire una certa data (quindi non utilizzando now()) qual'è il modo corretto? Ho fatto alcune prove ma mi dà errore di sintassi...

Grazie

[*Ray*]

Preoccuparsi dei tempi di calcolo in un database e' come preoccuparsi di quanto consuma in piu' una automobile accendendo i fari.

L'unica cosa che conta realmente in un DBMS sono gli accessi a disco, il resto sono esercizi mentali..