[mysql] autoincrement bij 0 beginnen

[whitehouse]

ik heb een tabel met daarin een ID. Deze is auto_increment.
Nu heb ik een tijdje deze tabel test gedraaid, en ben bij 130 items gekomen.
nu heb ik alle items weggehaald, maar als ik er nu 1 toevoeg, dan begint deze bij 131 .. hoe kan ik ervoor zorgen dat de ID bij 1 begint als er GEEN items in de tabel staan ?

[whoami]

Niet.....

Hier zijn al zoveel topics over geweest....

Waarom wil je eigenlijk dat er opnieuw bij 1 begonnen wordt? Je hebt gewoon een uniek nr nodig, en de waarde doet er toch niet toe?

[CyberSnooP]

Tabel verwijderen en opnieuw aanmaken helpt.. Maar in principe mag (zoals whoami terecht zegt) de waarde van een auto_increment veld er nooooit toe doen.

[Verwijderd]

Mja, dit fenomeen ken ik...en het boeit mij helemaal geen r**t...
Het gaat gewoon om een unieke integer, en of die nou bij 1 of bij 100000 begint maakt toch niks uit

[Firefox]

whoami schreef op 12 oktober 2002 @ 17:30:
Niet.....

Hier zijn al zoveel topics over geweest....

Waarom wil je eigenlijk dat er opnieuw bij 1 begonnen wordt? Je hebt gewoon een uniek nr nodig, en de waarde doet er toch niet toe?

Wel.....

Als er al zoveel topics over zijn geweest, waarom is de oplossing die heel simpel is dan niet alsnog gegeven?

Sommige mensen zijn gewoon een beetje perfectionistisch. Als je een test op een table hebt gedaan met je scriptje, en je wil je autoindex ff terug zetten voor de netheid als je prodcutie gaat draaien....

ALTER TABLE <tablename> AUTO_INCREMENT = 1;

Dit werkt ook als je niet alle records weggegooid hebt. Dan wordt met dit commando de next index op de laatste index+1 gezet.

(en dan ben ik nog een SQL n00b ook )

[Verwijderd]

Maar.... maar... maar...
nu wil ik wel graag weten waarom je nu de autoindex value wilt resetten ?
gewoon uit pure interesse zeg maar.

[ACM]

Firefox schreef op 12 oktober 2002 @ 18:32:
(en dan ben ik nog een SQL n00b ook )

Dat wil nog niet zeggen dat iemand met veel SQL kennis ook gelijk maar alle ins-en-outs van mysql kent...

[Verwijderd]

Ná de testset is het gewoon mooi om met een schone lei te beginnen.

[Verwijderd]

met phpmyadmin kan je gewoon LEGEN doen .. dan verwijderd ie de tabel en maakt ie hem weer aan dacht ik .. dan is ie weer bij 1 .. .

[MisterData]

Zolang je DB-design niet afhangt van het feit dat auto_increment bij 1 begint maakt het niet uit IMHO

[rickmans]

Je kan ook (lekker omslachtig ) de MAX waarde van id ophalen en vervolgens deze waarde +1 invoegen in je db

[Grum]

na een delete from <TABLE> zonder where restart de autoincrement ook automagisch

[drm]

MisterData:
Zolang je DB-design niet afhangt van het feit dat auto_increment bij 1 begint maakt het niet uit IMHO

Da's imo ook de meeste grove "fout" die ik hier vaker voorbij zie komen. Een primary key is de identificatie van 't record, verder niks. Het feit dat hij uniek is, is genoeg. Verder zou een primary key geen enkele betekenis moeten hebben, en heeft de werkelijke inhoud (het nummertje) van de primary key dus ook geen enkele waarde.

't Staat misschien netter, omdat wanneer je in de raw database kijkt (zonder schil eromheen) je dan mooi het eerste record bij 1 begint, maar theoretisch zou het net zo mooi zijn als wanneer elk opeenvolgende record een random nummer toegewezen krijgt, zolang hij maar uniek is.

Overigens gaat dit verhaal enkel op wanneer je het hebt over een primary key die door het dbms gegenereerd wordt. Er zijn situaties te bedenken waarbij dit niet het geval is, maar dan moet je ook niet van de database verwachten dat hij een sleutel voor je verzint

[Verwijderd]

empty tabel, dat gaat teminste met phpmyadmin goed

[Verwijderd]

drm schreef op 13 oktober 2002 @ 13:07 een heel mooi stukje over de betekenis (of eigenlijk gebrek daaraan) van gegenereerde ID's:
[...]

Lees en huiver mensen! Want dit is 100% true ...

[ Voor 0% gewijzigd door Verwijderd op 13-10-2002 13:21 . Reden: *bleep*ing smiley ]

[MisterData]

drm schreef op 13 oktober 2002 @ 13:07:

[...]

Da's imo ook de meeste grove "fout" die ik hier vaker voorbij zie komen. Een primary key is de identificatie van 't record, verder niks. Het feit dat hij uniek is, is genoeg. Verder zou een primary key geen enkele betekenis moeten hebben, en heeft de werkelijke inhoud (het nummertje) van de primary key dus ook geen enkele waarde.

't Staat misschien netter, omdat wanneer je in de raw database kijkt (zonder schil eromheen) je dan mooi het eerste record bij 1 begint, maar theoretisch zou het net zo mooi zijn als wanneer elk opeenvolgende record een random nummer toegewezen krijgt, zolang hij maar uniek is.

Overigens gaat dit verhaal enkel op wanneer je het hebt over een primary key die door het dbms gegenereerd wordt. Er zijn situaties te bedenken waarbij dit niet het geval is, maar dan moet je ook niet van de database verwachten dat hij een sleutel voor je verzint

Inderdaad

[ACM]

drm schreef op 13 oktober 2002 @ 13:07:
Overigens gaat dit verhaal enkel op wanneer je het hebt over een primary key die door het dbms gegenereerd wordt. Er zijn situaties te bedenken waarbij dit niet het geval is, maar dan moet je ook niet van de database verwachten dat hij een sleutel voor je verzint

Sterker nog, op het moment dat je primairy key een betekenis gaat krijgen (naast die van het identificeren) ben je fout bezig.
Namen en dergelijke moet je ook niet als primary key gebruiken, ondanks dat ze wel uniek (kunnen) zijn en bijna (en daar zit het hem in) nooit veranderen.
Door de primary key restrictie mag je het niet meer veranderen... (uiteraard staan de meeste RDBMS-en dat wel toe, maar officieel hoort het niet)

[drm]

ACM:
Sterker nog, op het moment dat je primairy key een betekenis gaat krijgen (naast die van het identificeren) ben je fout bezig.

offtopic:
Hoe vaak hebben we dit nou al gezegd in verscheidene topics?

[Verwijderd]

Volgens mij kunnen sommige mensen zich hiet echt helemaal over opvreten . Hebben ze een record gewijzigd zie je 233 ... 234 ... 236 NOOOOOOO Waar is 235 .

[Janoz]

rickmans schreef op 13 oktober 2002 @ 11:51:
Je kan ook (lekker omslachtig ) de MAX waarde van id ophalen en vervolgens deze waarde +1 invoegen in je db

Gaat goed totdat er 2 mensen tegelijk wat invoegen.....

[Basszje]

Janoz schreef op 14 oktober 2002 @ 10:37:

[...]


Gaat goed totdat er 2 mensen tegelijk wat invoegen.....

Idd , je wilt *niet* weten wat voor gezeur je daarmee kan krijgen .

Had ooit eens een script gebouwd wat in 2 tables insert deed en met een max de auto_inc van de eerste opvroeg voor de 2de.

Dan loop je het risico op 'scheve' records en dat is niet leuk als je een hoop mensen op die db hebt werken

[whoami]

Basszje schreef op 14 oktober 2002 @ 11:13:
[...]


Idd , je wilt *niet* weten wat voor gezeur je daarmee kan krijgen .

Had ooit eens een script gebouwd wat in 2 tables insert deed en met een max de auto_inc van de eerste opvroeg voor de 2de.

Dan loop je het risico op 'scheve' records en dat is niet leuk als je een hoop mensen op die db hebt werken

Dat risico kan je beperken door een controle in te bouwen....
Als je select max() gedaan hebt, ga je gaan kijken of er nog geen record bestaat met id = max(). Indien wel, ga je select maxxen tot wanneer je een id hebt die uniek is.
Maar goed, waarom moeilijk doen als het makkelijk kan?

[Janoz]

whoami schreef op 14 oktober 2002 @ 11:20:
[nohtml]
[...]
[/nohtml]

Dat risico kan je beperken door een controle in te bouwen....
Als je select max() gedaan hebt, ga je gaan kijken of er nog geen record bestaat met id = max(). Indien wel, ga je select maxxen tot wanneer je een id hebt die uniek is.
Maar goed, waarom moeilijk doen als het makkelijk kan?

Dan nog. Je zchuift het probleem alleen maar op... Je zult die methode sowieso op 1 of andere manier synchronized moeten maken waardoor dit slechts 1 x tegelijk uitgevoerd kan worden. En dat kan meestal alleen maar in de frontend die je om je db heen klust.

[drm]

Maak een insert queue aan. Input bufferen. Dan kan het niet meer mis gaan. Zorgen dat bij update de hele zooi pas een primary key krijgt. Interval van de flush kun je dan op 1 dag maar net zo goed op 1 minuut zetten.

( load )

[cameodski]

Tja, als je nou transacties had.
Kon je in een aparte tabel een tellertje bijhouden. Tijdens het toevoegen gewoon eventjes een update lock op de tabel met de teller.
Zorgen dat het hele gebeuren binnen een transactie staat en klaar is Kees.

[CyberSnooP]

ACM schreef op 13 oktober 2002 @ 15:16:
Namen en dergelijke moet je ook niet als primary key gebruiken, ondanks dat ze wel uniek (kunnen) zijn en bijna (en daar zit het hem in) nooit veranderen.
Door de primary key restrictie mag je het niet meer veranderen... (uiteraard staan de meeste RDBMS-en dat wel toe, maar officieel hoort het niet)

Tsja, dat GoT nou nickname-changes toestaat zegt niks over het algemene geval

[Anders]

"Het zou nooit uit mogen maken" - maar dat is natuurlijk puur technisch gesproken. Heb regelmatig meegemaakt dat een klant per se wilde dat "dat nummertje" van het eerste nieuwsbericht op zijn nieuwe site per sé bij 1 moest beginnen. Sommige klanten kun je overtuigen dat dat geen enkele waarde heeft, maar bij anderen kan je hoog en laag lullen als brugman, maar er moet en zal daar een 1'tje komen in de URL.

[CyberSnooP]

Anders schreef op 14 oktober 2002 @ 13:17:
Heb regelmatig meegemaakt dat een klant per se wilde dat "dat nummertje" van het eerste nieuwsbericht op zijn nieuwe site per sé bij 1 moest beginnen.

Tsja, dan maak je een apart nummerings systeem daarvoor aan, of je trekt het minimum-ID er vanaf hè. Zo heb je meteen extra werk moeten verrichten en dus geld geïnd!

[drm]

CyberSnooP:
Tsja, dan maak je een apart nummerings systeem daarvoor aan, of je trekt het minimum-ID er vanaf hè. Zo heb je meteen extra werk moeten verrichten en dus geld geïnd!

Dit meen je niet

[whoami]

cameodski schreef op 14 oktober 2002 @ 11:36:
Tja, als je nou transacties had.
Kon je in een aparte tabel een tellertje bijhouden. Tijdens het toevoegen gewoon eventjes een update lock op de tabel met de teller.
Zorgen dat het hele gebeuren binnen een transactie staat en klaar is Kees.

En dan gaat er eens iemand het tellertje in die tabel manual gaan aanpassen.

[ACM]

CyberSnooP schreef op 14 oktober 2002 @ 13:17:
Tsja, dat GoT nou nickname-changes toestaat zegt niks over het algemene geval

Ondanks dat rust er wel een unique constraint op nicknames.
We willen _wel_ dat ze uniek zijn natuurlijk.

Maar om nou gelijk maar de message-user etc koppelingen maar te baseren op de username (en dus ook verbieden dat ie ooit wijzigt) gaat wel vrij ver.

Naast over het algemeen de minder efficiente opslag (een nickname is minstens 3 tekens en meestal meer, dus bijna altijd 4 of meer bytes een (32bits) integer is altijd maar 4 bytes) en bewerkingen erop.

Het is gewoon zo dat als jij een betekenis aan je primary key toekent je potentieel in de problemen kunt komen.
Nicknames van users zijn er idd een voorbeeld van.

[ACM]

cameodski schreef op 14 oktober 2002 @ 11:36:
Tja, als je nou transacties had.
Kon je in een aparte tabel een tellertje bijhouden. Tijdens het toevoegen gewoon eventjes een update lock op de tabel met de teller.
Zorgen dat het hele gebeuren binnen een transactie staat en klaar is Kees.

Elke database die ik heb gebruikt met transactie support had gelukkig ook sequences of iets dergelijks (generator igg interbase)
Dus dan zou ik niet zo'n enge oplossing nemen, maar simpelweg de sequence toepassen.

Net als in postgresql stiekem gedaan wordt als je een SERIAL kolomtype neemt.

[cameodski]

whoami schreef op 14 oktober 2002 @ 13:22:
En dan gaat er eens iemand het tellertje in die tabel manual gaan aanpassen.

Je kunt in een trigger natuurlijk controleren of het wel mag, maar als je iets wilt verzieken kan dat altijd.

[cameodski]

ACM schreef op 14 oktober 2002 @ 13:28:
Elke database die ik heb gebruikt met transactie support had gelukkig ook sequences of iets dergelijks (generator igg interbase)
Dus dan zou ik niet zo'n enge oplossing nemen, maar simpelweg de sequence toepassen.

Zo eng is dat nu ook weer niet.
Als je bijvoorbeeld een opeenvolgende reeks factuur- of ordernummers wilt zonder gaten, zul je toch iets dergelijks moeten doen, vrees ik.