Newsgroup: it.comp.www.php
Titolo: [MySQL] Campo Auto-Increment a fondo scala...

Ciao a tutti,
sono alle prese con un campo auto incrementante che credo sia arrivato a
fondo scala.
Il campo e' int(11) e ogni record che aggiungo piglia il numero
2147483647
, sempre quello, che mi puzza sia il massimo raggiungibile da
quel campo.
Si puo' azzerare il contatore in qualche modo e forzarlo a ripartire da
0, anche cancellando tutti i records?
-- 
Mr. Fix @ work

 0, anche cancellando tutti i records?
Il contatore non lo puoi azzerare.
Perņ puoi creare una tabella uguale e copiarci tutti i dati.
Marco
+------------------------------+
| Marco <no private messages>  |
|                              |
| Software is like sex...      |
| It's better when it's free.  |
+------------------------------+

 Perņ puoi creare una tabella uguale e copiarci tutti i dati.
Ho risolto con le maniere forti...
Tramite MySQL Admin ho cancellato e ricreato il campo. Come per magilla
si e' impostato con i valori giusti ricreandosi automaticamente i numeri
progressivi (partendo da 1).
Boh...


 progressivi (partendo da 1).
Come non detto, e' impazzito nuovamente...
Mi puzza che sia perche', per effettuare un'operazione, scrivo
temporaneamente dei numeri negativi in quel campo...


 wrote:



Tu non devi _mai_ manipolare un campo autoincrement, se hai bisogno di 
manipolare un campo dovresti assegnare la sua vera funzione. Un po'
come salvare una data in un campo BLOB. The Art of Database design...
-- 
I'm not a signature.

 come salvare una data in un campo BLOB. The Art of Database design...
He he he... Hai ragione, purtroppo approccio da poco a MySQL e molti
concetti sono ancora oscuri, specialmente quello che si puo' e non si
puo' fare...


 relativi valori inseriti nel campo auto incrementante
[...]
Potresti aggiungere un campo timestamp cosi' avresti i record ordinati per
inserimento
con un semplice order by.
E quindi un campo ID che usi per dargli l'ordine che vuoi tu....
Nota il primo campo timestamp che crei si modifica ad ogni insrt o update
del campo
il secondo no. Quindi potresti fare un campo DATAultimamodifica e un secondo
campo Datadi creazione.
spero ti sia stato utile.
--
--
Xantos
m.mo...@NlOiSbPeArMo.it
 per rispondermi basta non urlare!

  per rispondermi basta non urlare!  <- He he he, simpatico... : )


 inserimento
Uhm... Ho provato e mi e' sembrata una soluzione ottima ma purtroppo,
essendo questo dato una chiave primaria, accade che se due persone
inseriscono un record nello stesso secondo salta fuori l'errore
(duplicate key).
Pensavo ad un sistema simile: recuperare il timestamp via php (time())
aggiungendo pero' il decimo (e magari anche il centesimo) di secondo.
Pero' l'unica funzione che ho trovato e' microtime() che recupera i
microsecondi.
Non ho capito una cosa: il numero di microsecondi (ad es 0.58317300) che
ottengo cosa significa? 0 microsecondi virgola qualcosa o 0 secondi
virgola 5 decimi 8 centesimi ecc?
Una volta ricavati i decimi ed i centesimi, per ottimizzare al massimo,
in che tipo di campo mi conviene metterli? INT (moltiplicando x 10 o 100
per togliere la virgola) oppure FLOAT?


temporaneamente dei numeri negativi in quel campo...
Se lo fai, automaticamente il campo va in rollover ed assume il valore
massimo. Usa un altro campo. I campi contatore servono a contare, e se
li usi per altri scopi rischi di fartici male :-)
Leonardo
-- 
Time's angles, mages tell, conceal a place
incredible, beyond the mundane mind;
night-shrouded and between the seas of space
dread creatures drift in the ageless winds.

 li usi per altri scopi rischi di fartici male :-)
Me ne sono accorto...  : )


0, anche cancellando tutti i records?
cambialo in unsigned.... 

 guardacaso... il tuo nomero.. 
Temo che cambiero' completamente soluzione ed evitero' i campi auto
incrementanti... Mi pare che abbiano troppe limitazioni e credo non si
possano ottimizzare (compattare) i dati al loro interno, ovvero,
cancellando records rimarrebbero un mucchio di buchi...


 cancellando records rimarrebbero un mucchio di buchi...
Ti consiglio vivamente di leggere un buon libro (o in rete) sui 
database relazionali. Temi come la normalizzazione di un database
devono essere chiari _prima_ di pasticciare.
La compattazione non esiste (meglio: non dovrebbe). Un database
e sempre un insieme di dati non ordinati. L'ordine devi assegnare tu
in qualche modo e viene generata nel momento in qui fai la query (il 
motore del database ha naturalmente mecchanismi molto potenti per 
ordinare, ad esempio l'indici).
Un campo auto_increment serve a dare un numero unico ad un record,
cosi, quando si fa un reference da una altra tabella sei sicuro che 
punta sempre sullo stesso record. Per quello non si puo' enumerare di 
nuovo. 
Ti metto qualche link:
  (anche se parla di access, va bene lo stesso)
 
http://www.itportal.it/tutorial/software/office/schemi_access/default.asp
 
 English:
 
http://newton.uor.edu/FacultyFolder/CKettemborough/Codd12R.html
 
http://www.intelligententerprise.com/db_area/archives/1999/993003/online2.shtml
 
http://www.cs.sfu.ca/CC/354/zaiane/material/notes/contents.html
 (forse troppo 
  academico)
;-)


 Ti metto qualche link:
[...]
Ti ringrazio per i link, mi saranno sicuramente utili.
Come libri ho cominciato leggendo "PHP per esempi" della Jackson e sono
passato da pochi giorni a "Sviluppare applicazioni per database con
MySQL/PHP" della Apogeo, quest'ultimo, in particolare, mi pare molto
interessante.
Thanks again!  : )


 interessante.
E' quello di Greenspan/Bulger? Ho la versione in Inglese. 
Li trovi subito nel primo capitolo il database design (da questo si capisce
quanto sia importante). Il libro e' buono, anche se ora sono cambiate alcune
cose per quello che riguarda PHP.


 quanto sia importante).
Hai ragione... Effettivamente dopo aver letto l'altro libro sono passato
a questo consultando le funzioni php e tralasciando momentaneamente sql.
Mea culpa...  : )


 Aaargh... Masochista...  ; )
Dipende dalla qualita' della traduzione!


 Dipende dalla qualita' della traduzione!
Obiezione accolta...
