[MySQL] auto_increment veranderen

[Verwijderd]

Voor het spel Omerta waarvan sommigen van jullie misschien iets meegekregen heb ik een table 'user' met een auto_increment voor de column ID.
Deze staat op INT(5), 99999 users leek me wel genoeg immers.

Hier het probleem:
De auto_increment staat (ineens?!) op 131233, en nu gaat het mis. Nieuwe users krijgen verkeerde informatie etc. etc...

Mijn vraag:
Hoe komt het dat hij ineens over de 130.000 gegaan is, en hoe herstel ik dit weer? Moet ik daarvoor de hele table opslaan en de autoincrement handmatig veranderen en table weer invoegen?

[dArtagnan]

Oplossing:

SQL:

ALTER TABLE table_naam AUTO_INCREMENT = nieuw nummer;

Voorbeeld:

SQL:

ALTER TABLE producten AUTO_INCREMENT = 245;

[ Voor 20% gewijzigd door dArtagnan op 07-10-2003 20:05 ]

[Creepy]

Mag ik vragen waarom je afhankelijk bent van de volgorde van een auto_increment veld?

[ACM]

int(5) is trouwens alleen maar grafische kerst, het blijft gewoon een normale integer kwa opslag...

[Verwijderd]

Als je afhankelijk bent van je auto_increment waarde, dan klopt er iets niet, en werk je volgens mij met (pseudo-) hardcoded waarden/optellingen/...?

ACM schreef op 07 October 2003 @ 20:52:
int(5) is trouwens alleen maar grafische kerst, het blijft gewoon een normale integer kwa opslag...

Wat bedoel jij daar mee?

[Jordi]

Dat het geen drol uitmaakt of je INT(5) of INT(10) opgeeft en het veld dus net zoveel ruimte in zal nemen.

[Verwijderd]

Ah, het getalletje dus, ja tuurlijk, je legt er gewoon een constraint op, heeft niets met de opslag te maken

[curry684]

ACM schreef op 07 October 2003 @ 20:52:
int(5) is trouwens alleen maar grafische kerst, het blijft gewoon een normale integer kwa opslag...

Sterker nog, een constraint zal extra controles tot gevolg hebben waardoor het geheel een minieme fractie langzamer wordt.

[eborn]

curry684 schreef op 08 October 2003 @ 07:49:
[...]

Sterker nog, een constraint zal extra controles tot gevolg hebben waardoor het geheel een minieme fractie langzamer wordt.

Het getal is geen constraint, het is een opmaak-indicatie. Volgens mij kun je in MySQL geen eens INT velden aanmaken zonder een width mee te geven.

[eborn]

Verwijderd schreef op 08 October 2003 @ 00:07:
Ah, het getalletje dus, ja tuurlijk, je legt er gewoon een constraint op, heeft niets met de opslag te maken

Het is dus geen constraint.

As an extension to the SQL-92 standard, MySQL also supports the integer types TINYINT, MEDIUMINT, and BIGINT as listed in the tables above. Another extension is supported by MySQL for optionally specifying the display width of an integer value in parentheses following the base keyword for the type (for example, INT(4)). This optional width specification is used to left-pad the display of values whose width is less than the width specified for the column, but does not constrain the range of values that can be stored in the column, nor the number of digits that will be displayed for values whose width exceeds that specified for the column.

[ACM]

eborn schreef op 08 oktober 2003 @ 10:13:
Het getal is geen constraint, het is een opmaak-indicatie. Volgens mij kun je in MySQL geen eens INT velden aanmaken zonder een width mee te geven.

Jahoor, je kan gewoon int of integer intikken, zonder grootte.

Maar dan maakt ie er int(11) oid van.

Maar het is eigenlijk nog erger, mysql kent niet eens constraints op ints, als jij een waarde groter dan max-int invoert, dan zal ie dat gewoon invoeren (als max-int), ipv netjes weigeren...
Datzelfde geldt voor varchar's, die worden getruncate ipv geweigerd.

En dat is nou typisch iets wat een ACID compliant RDBMS niet zou mogen doen (ingevoerde waarde = uitgevoerde waarde, is een van de consistency eisen), iets dat mysql wel pretendeert te zijn.

[bigtree]

ACM schreef op 08 oktober 2003 @ 10:24:
[...]

Jahoor, je kan gewoon int of integer intikken, zonder grootte.

Maar dan maakt ie er int(11) oid van.

Maar het is eigenlijk nog erger, mysql kent niet eens constraints op ints, als jij een waarde groter dan max-int invoert, dan zal ie dat gewoon invoeren (als max-int), ipv netjes weigeren...
Datzelfde geldt voor varchar's, die worden getruncate ipv geweigerd.

En dat is nou typisch iets wat een ACID compliant RDBMS niet zou mogen doen (ingevoerde waarde = uitgevoerde waarde, is een van de consistency eisen), iets dat mysql wel pretendeert te zijn.

Dan moet je toch eens je lijstje aanpassen.

Int(10) is the same as int(1) eventhough the manual says differently.

Dit duidt er op dat je de manual niet goed gelezen hebt.

What does zerofill do to a integer field? A database is meant to store data, not to format it while storing.

Zerofill wordt pas toegepast bij ophalen, niet bij opslaan.

If you update a record and set it to the same value, mysql'll define that as unaffected. Even if it does change a timestamp field.

Dit zelfde gedrag houdt MSSQL er dacht ik ook op na. Niet daadwerkelijk gewijzigd? Dan ook de timestamp niet updaten. Dit is imo trouwens superhandig, vooral als je de timestamp gebruikt om twee databases te synchroniseren. Stel dat een record op beide databases niet veranderd zijn maar wel een timestamp update hebben gehad, welke laat je dan prevaleren?