[mysql]autoincrement maximum

[Gomez12]

nav [rml]Gomez12 in "[ MYsql] Database door de war"[/rml] heb ik even een vraagje over autoincrement van mysql. Als de autoincrement nummering vol zit begint hij dan overnieuw bij 0 of heb je een probleem in je applicatie???

Want ik heb bijv een todo lijstje met actieve todo's met een autoincrement op een id kolom van int (6) Omdat ik er gewoon vanuit ga dat er op een gegeven moment niet meer dan 1.000.000 actieve todo's kunnen zijn, als een todo afgehandeld is gaat hij naar een aparte tabel die wel meer aankan en die geen autoincrement heeft.

Maar als ik de post van chem lees, dan gaat het niet om hoeveel todo's ik op een moment heb, maar moet ik hem gaan verhogen omdat in de loop van enkele jaren de todo tabel best meer dan 1.000.000 records bevat kan hebben??? Klopt dit.

Dus als ik 1.000 records per dag invoer en verplaats naar mijn afgehandeld tabel dan heb ik dus na 1.000 dagen een probleem omdat de autoincrement dan op 1.000.000 staat en dan dus niet meer naar nul gaat???

[djluc]

Kijk eens hoe hoog de waarde mag zijn die in een integer mag komen. Waarom geen int(11)? Al denk ik dat mysql dit niet zelf zal gaan verhogen.

[ Voor 36% gewijzigd door djluc op 28-08-2004 15:33 ]

[Gomez12]

Dat is te doen, maar gaat mij meer om het principe, ik kan mijn database wel vergroten om onder het probleem van auto-increment uit te komen, maar dat doe ik liever niet. Zoals ik hierboven al aangeef staat er op een gegeven moment niet meer dan 10.000 records in een tabel, dan vind ik het onzin om problemen met een auto-increment te voorkomen door de kolom maar even op int(10) of hoger te gaan gooien, dat heb ik nooit nodig omdat er op een moment nooit zoveel records in die tabel staan.

Dus ik wil graag weten of auto-increment echt moeilijk zit te doen als ik hem volgooi ( want dan bouw ik zelf wel een auto-increment in mijn scripts )

[ACM]

int(6) is niks anders dan een gewone integer waar maar 6 getallen van getoond zouden moeten worden, 't is niet een kleinere of grotere int naargelang je het getalletje varieert. 't Ding in een int (11) veranderen zou dus geen gevolg voor je tabel of applicatie moeten hebben, terwijl je wel het complete bereik van de integer kan zien. En ik zie ook niet in waarom je maar max 6 cijfers zou willen zien, dat is weer zo'n - imho - compleet zinloze toevoeging op de standaard van MySQL.

Als ze dan nog zouden controleren of je getal inderdaad binnen het bereik van die int(6) zou vallen, dan was het tenminste nog een beetje zinvol...

Sterker nog, het wordt niet eens afgedwongen of bij het tonen gebruikt:

code:

mysql> desc int_test;
+-------+--------+------+-----+---------+-------+
| Field | Type   | Null | Key | Default | Extra |
+-------+--------+------+-----+---------+-------+
| test  | int(6) | YES  |     | NULL    |       |
+-------+--------+------+-----+---------+-------+
1 row in set (0.00 sec)

mysql> insert into int_test values (10000), (100000), (1000000), (10000000), (100000000);
Query OK, 5 rows affected (0.00 sec)
Records: 5  Duplicates: 0  Warnings: 0

mysql> select * from int_test;
+-----------+
| test      |
+-----------+
|     10000 |
|    100000 |
|   1000000 |
|  10000000 |
| 100000000 |
+-----------+
5 rows in set (0.00 sec)

Verder heb je in principe een probleem als je auto_increment vol zit, dan krijg je MAX_INT en daarna wil ie niet meer hoger:

code:

mysql> select * from inc_test;
+------+
| test |
+------+
|    1 |
|    2 |
|    3 |
|    4 |
|  126 |
+------+
5 rows in set (0.00 sec)

mysql> insert into inc_test () values ();
Query OK, 1 row affected (0.00 sec)

mysql> insert into inc_test () values ();
ERROR 1062: Duplicate entry '127' for key 1

[ACM]

Gomez12 schreef op 28 augustus 2004 @ 15:47:
Dat is te doen, maar gaat mij meer om het principe, ik kan mijn database wel vergroten om onder het probleem van auto-increment uit te komen, maar dat doe ik liever niet. Zoals ik hierboven al aangeef staat er op een gegeven moment niet meer dan 10.000 records in een tabel, dan vind ik het onzin om problemen met een auto-increment te voorkomen door de kolom maar even op int(10) of hoger te gaan gooien, dat heb ik nooit nodig omdat er op een moment nooit zoveel records in die tabel staan.

Ik vind dit wel een beetje een wazige redenering... Je hebt nooit meer dan 10k records dus hoeft je auto_increment niet verder dan 10k te tellen. Dat zou impliceren dat je records die je nu hebt en de records die je over een maand hebt dezelfde primary key zouden mogen hebben... Als je die records van nu en dan toch niet uit elkaar wilt kunnen houden, waarom definieer je dan een primary key?

Btw, waarom heb je niet een statusveld "afgehandeld", ipv de records verplaatsen?

[ Voor 5% gewijzigd door ACM op 28-08-2004 15:56 ]

[Gomez12]

ACM schreef op 28 augustus 2004 @ 15:55:
[...]

Ik vind dit wel een beetje een wazige redenering... Je hebt nooit meer dan 10k records dus hoeft je auto_increment niet verder dan 10k te tellen. Dat zou impliceren dat je records die je nu hebt en de records die je over een maand hebt dezelfde primary key zouden mogen hebben... Als je die records van nu en dan toch niet uit elkaar wilt kunnen houden, waarom definieer je dan een primary key?

Btw, waarom heb je niet een statusveld "afgehandeld", ipv de records verplaatsen?

Omdat het afgehandeld gedeelte een historie heeft met 29.582 records en een actieve todo heeft een aantal velden en is genormaliseerd op een manier die ik bij een afgehandelde nooit meer nodig heb. ( voorbeeld, een actieve todo heeft een klantid en een koppeling met de klanten tabel zodat als ik de adres gegevens wijzig dat die ook in de todo wijzigt, een afgehandelde todo heeft gewoon keihard een klantnaam, klantadres etc erin staan. Zodat ik bij een todo van 2 jaar geleden kan zeggen dat die is uitgevoerd op het adres van toen, en de klantnaam van toen)

En omdat ik een primary key alleen zie als iets wat voor de dbase van belang is, vind ik het niet erg als 1 maand terug id 1 iets anders is als id 1 vandaag ( mits id1 van 1 maand terug afgehandeld is ). De gebruiker zegt toch nooit dat hij id 1 wil hebben, hij zoekt op andere dingen.

Maar is het niet zo dat de dbase sneller is als ik gewoon zeg dat een int (6) is, want dan weet de dbase van te voren al op welke plek het volgende record begint, want een record is 6 tekens??? Meen ik opgepikt te hebben vanuit varchars....

Maar na het bekijken van acm's Anti-mysql lijst zie ik dat het niets uitmaakt of ik int(6) of int(10) doe, dus dan maar int(10)

[ Voor 7% gewijzigd door Gomez12 op 28-08-2004 16:39 ]