[MySQL] auto increment terugzetten

[Kaastosti]

Ik heb een forum gebouwd in php, waarbij in mysql aan berichten een message_id wordt gekoppeld en eventueel een message_parent als het een reply is. Nou komt het natuurlijk voor dat je bij het adminnnen posts weghaalt. Deze worden dan ook totaal uit de database weggehaald. Er blijven lege plekken over die niet opnieuw gebruik worden.

Ik heb een her-index scriptje geschreven wat alle lege plekken gebruikt. Alle posts worden als het ware weer in elkaar geschoven. Dit systeem werkt perfect.

Als ik echter een nieuwe post doe, krijgt deze automatisch van mysql het id 60 (bijvoorbeeld). Die kolom is auto-incremented en gaat nog steeds door waar hij het laatst gebleven was, in plaats van terug te springen net achter het id van de (na de her-index) laatste posting.

Is er een manier om dit alsnog handmatig te doen, dan kan ik ook dat in het script opnemen

[LordLarry]

Wat is er nou erg aan dat een ID waar de gebruiker niets mee te schaften heeft niet precies aansluit?!

[BasieP]

je kan het handmatig doen, maar het is erg database gevoelig (als je ook maar iets verkeerd doet is je database corrupt)

waarom zou je die lege velden weg willen halen?
ik zie het nut er niet zo van in.
bovendien is het zo dat als users dan linkjes naar een topic plaatsen dat ze ipv een 'topic niet gevonden' bericht een heel ander topic zien

[whoami]

* whoami is het eens met LordLarry.

Een PK zou imho geen enkele betekenis mogen hebben voor de gebruiker, enkel voor het DBMS is een PK belangrijk (administratief dan).
Stel dat je je PK's gaat gaan veranderen, dan mag je alle gerelateerde records gaan wijzigen.

[Kaastosti]

Het is voor een project van school. Ik verwacht daarbij dat ze bij de beoordeling wel extreme situaties gaan schetsen en hoe wij daaraan hebben gedacht. Als er zeer veel berichten in het forum zouden komen, werkt het sneller en efficienter als die ID's aansluiten.

De gebruikers hebben er idd ook niets mee van doen, die zien die ID's toch nooit, maar het gaat om het technisch aspect. Ze zijn nogal moeilijk bij eindbeoodelingen

Maar hoe is het handmatig te veranderen? Ik kan er namelijk niets over vinden

[ Voor 10% gewijzigd door Kaastosti op 25-11-2002 16:41 ]

[dirkpostma]

Hoewel ik het nut er ook niet van inzie, hier een oplossing:
1) maak een tweede posts tabel aan
2) kopieer alle posts uit de oude tabel naar de nieuw, met nieuwe indexen
3) verwijder oude tabel
4) rename nieuwe tabel

[Anders]

Kaastosti schreef op 25 November 2002 @ 16:33:Nou komt het natuurlijk voor dat je bij het adminnnen posts weghaalt. Deze worden dan ook totaal uit de database weggehaald. Er blijven lege plekken over die niet opnieuw gebruik worden.

Hoe kom je erbij dat er lege plekken overblijven? Da's totale onzin. Het enige wat er aan de hand is, is dat de keys niet meer aaneensluitend zijn, maar dat is van geen enkel belang voor het functioneren van de database en de toepassing waar deze op draait (tenzij deze verkeerd is ontworpen natuurlijk).

M.a.w. waarom wou je de nummertjes weer aaneensluitend willen maken?

[/quote]Ik verwacht daarbij dat ze bij de beoordeling wel extreme situaties gaan schetsen en hoe wij daaraan hebben gedacht. Als er zeer veel berichten in het forum zouden komen, werkt het sneller en efficienter als die ID's aansluiten.[/quote]

Oef. Als ik eindbeoordelaar was en zag dat je elke keer na het verwijderen van een paar posts de hele database opnieuw zou willen nummeren, zou ik je een dikke onvoldoende geven. Ten eerste omdat een nummer dat eerst bij topic A hoorde, later bij topic B hoort (zie post BasieP) met alle verwarring voor de gebruiker van dien. Ten tweede omdat er geen enkele technische of functionele reden voor en bij het minste of geringste foutje je database corrupt is en je helemaal opnieuw kunt beginnen.

[ Voor 37% gewijzigd door Anders op 25-11-2002 16:49 ]

[LordLarry]

Kaastosti schreef op 25 november 2002 @ 16:40:
Het is voor een project van school. Ik verwacht daarbij dat ze bij de beoordeling wel extreme situaties gaan schetsen en hoe wij daaraan hebben gedacht. Als er zeer veel berichten in het forum zouden komen, werkt het sneller en efficienter als die ID's aansluiten.

Nee, dat maakt niets uit voor een DB. Zeker niet als je er ook nog een index op hebt.

De gebruikers hebben er idd ook niets mee van doen, die zien die ID's toch nooit, maar het gaat om het technisch aspect. Ze zijn nogal moeilijk bij eindbeoodelingen

Onzin als ze hier over gaan zeuren, wat is er dan technisch niet goed aan?

Gebruik dan geen auto_inc, maar inc zelf

[whoami]

[nohtml]

Kaastosti schreef op 25 November 2002 @ 16:40:
Het is voor een project van school. Ik verwacht daarbij dat ze bij de beoordeling wel extreme situaties gaan schetsen en hoe wij daaraan hebben gedacht. Als er zeer veel berichten in het forum zouden komen, werkt het sneller en efficienter als die ID's aansluiten.

Wie zegt dat? Dat is gewoon onzin.
De gegevens in een databank worden meestal als een binary tree opgeslagen. Dwz dat er verschillende 'knooppunten' zijn die sleutels bevatten. Via die knooppunten kom je dan bij de uiteindelijke data. (Die knooppunten worden dus voor bepaalde velden gemaakt, namelijk de velden waar er een index op ligt).
De inhoud van de gegevens hebben wel invloed hoe de index gemaakt wordt, maar als er nu 'gaten' in dat id zitten, heeft dat niets te maken met het aantal knooppunten dat gemaakt wordt, dus zal dat ook de performance niet beinvloeden.
('t is een beetje *gaar* uitgelegd, maar 't is ook maandagavond).

[BasieP]

hehe whoami, je hebt idd gelijk, gaten hebben geen invloed op de leessnelheid
het telkens opschonen van records wel

het is technisch gezien ook slomer om alles op te schonen

[whoami]

Het verwijderen / inserten / updaten van records *kan* idd trager gaan. Als er veel indexen op die tabel liggen, zal dat idd iets trager gaan, het DBMS moet nl. iedere keer zijn indices gaan updaten.

[Verwijderd]

BasieP schreef op 25 november 2002 @ 16:55:
hehe whoami, je hebt idd gelijk, gaten hebben geen invloed op de leessnelheid
het telkens opschonen van records wel

het is technisch gezien ook slomer om alles op te schonen

Het zijn niet eens gaten, dat is alleen de associatie die de mens ermee maakt. Het DBMS heeft daar absoluut geen last van.

[Kaastosti]

Okee okee ik snap 't al
Slecht plan... het is ook nog niet geintegreerd in het geheel, dus ik laat 't er gewoon uit