[SQL] herindexeren van een veld

[Diaboluzzz]

Ik gebruik phpmyadmin 2.4.0 en één van de meest recente MySql versies, de exacte weet ik even niet uit mn hoofd.

Probleem is als volgt: Ik heb een tabel met ruim 4000 entry's hierin is het veld 'num' de index, primaire sleutel dit veld is van het type int(11)
Nu zijn er in het verleden dingen gewist waardoor er 'gaten' zijn gevallen in het veld 'num' (1,2,3,4,10,20,21 enz).
De volgende autoindex is 4231, maar de kardinaliteit staat al op 4300+.

Hoe zorg ik er voor dat die gaten verdwijnen en de cardinaliteit weer gelijk wordt aan de volgende autoindex zonder gegevens te verliezen?


De search ( http://gathering.tweakers...5Bsearch%5D=Zoek#hitstart &
http://gathering.tweakers...data%5Bpage%5D=2#hitstart ) geeft geen uitsluitsel vandaar dit topic.

Alvast bedankt

[ripexx]

Doe eens een optimize van je tabel:

SQL:

OPTIMIZE TABLE tablenaam;

Verder heeft PHPMyAdmin ook deze functie er in gebouwd.

[ Voor 3% gewijzigd door ripexx op 10-05-2004 17:28 ]

[Xander]

ripexx schreef op 10 mei 2004 @ 17:27:
Doe eens een optimize van je tabel:

SQL:

OPTIMIZE TABLE tablenaam;

Verder heeft PHPMyAdmin ook deze functie er in gebouwd.

Volgens mij zorgt een optimize er niet voor dat die indexcijfers weer kloppen.

Diaboluzzz schreef op 10 mei 2004 @ 16:59:
Ik heb een tabel met ruim 4000 entry's hierin is het veld 'num' de index, primaire sleutel dit veld is van het type int(11)
Nu zijn er in het verleden dingen gewist waardoor er 'gaten' zijn gevallen in het veld 'num' (1,2,3,4,10,20,21 enz).
De volgende autoindex is 4231, maar de kardinaliteit staat al op 4300+.

Ik heb eerlijk gezegd geen idee wat "kardinaliteit" is... maar als ik met PremiumSoft MySQL studio in mijn databases het index field verwijder en weer opnieuw aanmaak nummert hij weer aaneengesloten... Als je dit gaat proberen zorg dan wel echter eventjes voor een backup...

[ Voor 4% gewijzigd door Xander op 10-05-2004 17:35 ]

[Creepy]

Here we go again: Wat is het probleem met die gaten in die lijst? Want die ID's gebruik je als het goed is niet om te tonen aan gebruikers e.d.

[ Voor 43% gewijzigd door Creepy op 10-05-2004 17:41 ]

[TeasingU]

de kardinaliteit heeft te maken met het aantal rijen die voldoen aan bepaalde randvoorwaarden.

Je kunt zelf handmatig via een (php) script een nieuwe index aanmaken, maar dat zul je dan telkens moeten doen wanneer je iets verwijdert.

Weet je zeker dat het een vereiste is dat de index geen gaten heeft?

[djluc]

Wat jij wilt mag gewoonweg *NIET* op een primary key. Dan is de gehele betekenis daarvan weg.

Geef eens een duidelijk voorbeeld waar je die nummertjes wilt tonen, en waarom deze in de database zouden moeten staan. Als je gewoon wat rijtjes wilt nummeren kun je dat veel beter gewoon in PHP doen omdat die nummers toch geen enkele relevantie met de getoonde gegevens hebben.

[ Voor 61% gewijzigd door djluc op 10-05-2004 17:55 ]

[Xander]

djluc schreef op 10 mei 2004 @ 17:54:
Wat jij wilt mag gewoonweg *NIET* op een primary key. Dan is de gehele betekenis daarvan weg.

Tja, het kan wel, ik vind het er zelf ook overzichtelijker uitzien.
ff voorbeeldje:






Netjes opnieuw nummertjes aangemaakt

[gorgi_19]

@XanderH

En de rest van de referenties worden dan opeens ook netjes aangepast?

[Xander]

gorgi_19 schreef op 10 mei 2004 @ 18:06:
@XanderH

En de rest van de referenties worden dan opeens ook netjes aangepast?

Zoals ik al gezegd hebt, ik vat niet echt veel van dit SQL gebeuren, ik weet alleen dat de nummertjes er zo beter uitzien en alles nog werkt

[gorgi_19]

XanderH schreef op 10 mei 2004 @ 18:08:
[...]


Zoals ik al gezegd hebt, ik vat niet echt veel van dit SQL gebeuren, ik weet alleen dat de nummertjes er zo beter uitzien en alles nog werkt

Voor 1 tabel verwacht ik ook niet zo veel problemen. Maar ik ben juist benieuwd of je geen relaties gaat verknallen. Stel we hebben een userID (PK). Vervolgens heb ik een rechtenlijst (RoleID (PK), UserID (FK), RoleNameID)

Gaan die UserID's dan in de rechtenlijst ook netjes mee?

* gorgi_19 blijft het onzin vinden om je PK's te gaan hernummeren alleen voor de 'netheid'.

[Xander]

gorgi_19 schreef op 10 mei 2004 @ 18:11:
[...]

Voor 1 tabel verwacht ik ook niet zo veel problemen. Maar ik ben juist benieuwd of je geen relaties gaat verknallen.

Die heb ik niet

Ik wist toevallig dat het zo ging, ik zou ook nooit dit zomaar doen op een MySQL server die in gebruik is, en eigenlijk is het wel onzin ja. Ik gaf dit alleen maar als tip voor de Topic Starter, hij mag zelf weten of en wat hij er mee doet, maar je zou zoiets natuurlijk altijd op een test database kunnen uitproberen...

[ Voor 40% gewijzigd door Xander op 10-05-2004 18:14 ]

[P_de_B]

* P_de_B vraagt zich af hoe "er beter uit zien" een criterium kan zijn voor een PK

[marty]

gorgi_19 schreef op 10 mei 2004 @ 18:11:
[...]

* gorgi_19 blijft het onzin vinden om je PK's te gaan hernummeren alleen voor de 'netheid'.

Het is niet eens onzin, zoals djluc al zegt mag je dit gewoon nooit en te nimmer doen. Die PK werkt niet voor niets zoals ie werkt. Die gaten hebben een bepaalde functie en die moet je er niet handmatig uit gaan zitten slopen, want dan sloop je ook gelijk de R uit RDBM.

[Diaboluzzz]

Het is niet alleen voor de netheid gorgi, we gebruiken die nummers.
Op de site in kwestie tonen we het totaal aantal geposte berichten.
Als er nu een keer iets wordt gepost wat verwijdert moet worden dan gebruiken we die teller als referentie.
Maar in een ongeordent zootje is het lastig zoeken en met 20 berichten per dag is dat gewoon binnen 2 jaar onhanteerbaar (we adminnen direct in sql via phpmyadmin)

[marty]

Diaboluzzz schreef op 10 mei 2004 @ 19:12:
Het is niet alleen voor de netheid gorgi, we gebruiken die nummers.
Op de site in kwestie tonen we het totaal aantal geposte berichten.
Als er nu een keer iets wordt gepost wat verwijdert moet worden dan gebruiken we die teller als referentie.

En daarom mag je dus (nogmaals) nooit en te nimmer met die PKs gaan klooien. Juist omdat ze als referentie dienen. Als jij van de 22 berichten nummer 19 verwijderd en je drukt per ongeluk op refresh dan verwijder je nummer 20 dus ook per ongeluk.

Maar in een ongeordent zootje is het lastig zoeken en met 20 berichten per dag is dat gewoon binnen 2 jaar onhanteerbaar (we adminnen direct in sql via phpmyadmin)

Dat moet je me toch eens uitleggen .... (dat onhanteerbare aspect)
Verder raad ik je dat 'direct adminnen' ten zeerste af. Steek er even 2 uurtjes tijd in om er iets voor in PHP/ASP/whatever te schrijven, dan weet je zeker dat je in de toekomst geen domme fouten maakt met een vinkje op de verkeerde regel ofzo. bovendien gaat dat een stuk sneller dan telkens een hele tabel aan data met PHPMyAdmin binnenhalen

[ Voor 19% gewijzigd door marty op 10-05-2004 19:17 ]

[djluc]

@ts: waarom gebruik je niet gewoon een fatsoenlijke methode om records te tellen? In SQL is dat iets als SELECT count(*) AS aantal FROM tabel.

offtopic:
Ik wil niet heel flauw doen marty maar:
Als je verder geen tot weinig PHP kennis hebt zal het maken van een bruibare admin niet zo 123 lukken. Verder vind ik het argument van fouten maken ook een beetje dubieus aangezien je ook op het verkeerde delete knopje in je eigen admin kunt drukken. Dat maakt dus verder geen verschil.

[marty]

djluc schreef op 10 mei 2004 @ 19:34:

offtopic:
Ik wil niet heel flauw doen marty maar:
Als je verder geen tot weinig PHP kennis hebt zal het maken van een bruibare admin niet zo 123 lukken.

Hoezo? Dat is toch vrij basic? Als je ook een systeem kunt maken waarmee je berichten op een site kunt posten of wat ie dan ook doet, dan moet dat volgens mij ook wel lukken.

offtopic:
Verder vind ik het argument van fouten maken ook een beetje dubieus aangezien je ook op het verkeerde delete knopje in je eigen admin kunt drukken. Dat maakt dus verder geen verschil.

Dat voorkom je met een admin systeem dus door een 'weet je het zeker' melding te geven met een overzicht van het te deleten record
Maar het ging me meer om het idee. Ik heb het in het verleden ook wel eens gehad dat ik even snel wat via de prompt ging aanpassen met een UPDATE en een stukje WHERE vergat waardoor ineens de helft van m'n tabel dezelfde data had. En da's niet echt fijn. En dat zal je met een eigen gemaakt admin systeempje nooit gebeuren (als je dat eerst test met een backup achter de hand)

[ontopic]
Overigens: Deleten is vaak geen goed idee. Waarom doe je dit eigenlijk? Een veel beter methode is vaak om een extra veld op te nemen dat je op 'deleted' ofzo zet, zodat je weet dat die niet meer meetellen. Data delete je eigenlijk alleen maar uit een database als die er écht niet (meer) in thuis hoort.

[ Voor 17% gewijzigd door marty op 10-05-2004 19:50 ]