[php/mysql]Unieke ID's zonder gaten in volgorde

[Verwijderd]

Ik ben bezig met een DB waarbij ik het volgende probeer te bereiken:

Het aantal users is af te lezen aan de hoogste user_oudside_id. De user_id kolom is autoincrement en daar mogen de nummers gaten bevatten. Maar het user_outside_id niet. Ik wil dus dat als ik bijvoorbeeld het volgende heb:

code:

user_id | user_outside_id | user_name |
----------------------------------------
   1    |        1        |  Pietje   |
   2    |        2        |  Jantje   |
   3    |        3        |  Hendrik  |
   4    |        4        |  Klaas    |
   5    |        5        |  Terma    |

En ik hendrik verwijder, de rij met de hoogste user_outside_id de waarde van de zojuist verwijderde Hendrik user_outside_id overneemt en je dus bijv. het volgende te zien krijgt:

code:

user_id | user_outside_id | user_name |
----------------------------------------
   1    |        1        |  Pietje   |
   2    |        2        |  Jantje   |
  785   |        3        |  Leo      |
   4    |        4        |  Klaas    |
   5    |        5        |  Terma    |

De reden van dit alles is, dat ik een mooie opeenvolgende nummers wil hebben in de users. Als iemand dus bijvoorbeeld ?user=1 t/m ?user=784 intikt hij ook daadwerkelijk bij alle pagina's een user te zien krijgt.

offtopic:
Ik gebruik in dit voorbeeld users, maar het kan vanalles zijn, producten, quotes, posts etc.

Mijn 1e vraag is: Hoe kan ik via php/mysql er voor zorgen dat zodra ik een user verwijder, de hoogste user_outside_id, deze waarde overneemt?

Mijn 2e vraag: Hoe zorg ik ervoor, mocht er door een ongelukje toch gaten komen in de user_outside_id, hoe check ik dat en hoe zorg ik er voor dat de hoogste user_outside_id's die gaten opvullen?

[sjoerdb2]

Verwijderd schreef op 02 mei 2004 @ 16:27:
(...)
De reden van dit alles is, dat ik een mooie opeenvolgende nummers wil hebben in de users. Als iemand dus bijvoorbeeld ?user=1 t/m ?user=784 intikt hij ook daadwerkelijk bij alle pagina's een user te zien krijgt.
(...)

Dit kun je toch ook oplossen door een query te doen als:

code:

SELECT * FROM users WHERE userid=2 LIMIT 0,783;

of zeg ik nu iets doms?

[Limhes]

Verwijderd schreef op 02 mei 2004 @ 16:27:
...
De reden van dit alles is, dat ik een mooie opeenvolgende nummers wil hebben in de users. Als iemand dus bijvoorbeeld ?user=1 t/m ?user=784 intikt hij ook daadwerkelijk bij alle pagina's een user te zien krijgt.
...

Waarom wil je dit? Een ID dat je toekent aan een gebruiker/product/etc. is toch niet van belang voor de bezoeker van je site? Ik zie dus niet echt in waarom dit een probleem zou zijn... Een bezoeker tikt als het goed is namelijk geen URL in met de ID erin, maar bezoekt alleen een dergelijke link als hij ernaar doorverwezen wordt.

[gorgi_19]

sjoerdb schreef op 02 mei 2004 @ 16:36:
[...]


Dit kun je toch ook oplossen door een query te doen als:

code:

SELECT * FROM users WHERE userid=2 LIMIT 0,783;

of zeg ik nu iets doms?

* gorgi_19 gokt dat

code:

SELECT * FROM users ORDER BY UserID LIMIT 0,783;

beter gaat werken; de where clausule al niet zo veel nut hebben.

[faabman]

Mijn 1e vraag is: Hoe kan ik via php/mysql er voor zorgen dat zodra ik een user verwijder, de hoogste user_outside_id, deze waarde overneemt?

Mijn 2e vraag: Hoe zorg ik ervoor, mocht er door een ongelukje toch gaten komen in de user_outside_id, hoe check ik dat en hoe zorg ik er voor dat de hoogste user_outside_id's die gaten opvullen?

waarom wil je dit eigenlijk doen???

edit:

okey, mysql kent geen top, dus zie gorgi_19

[ Voor 36% gewijzigd door faabman op 02-05-2004 16:46 ]

[whoami]

whoami schreef op 10 januari 2004 @ 15:55:
De 'gaten' die kunnen ontstaan bij auto-incr. columns worden niet opgevuld nee. Als je 4 records hebt, met id's 1, 2, 3, 7, dan krijgt het eerstvolgende record het id 8 mee.

Maar waarom wil je dat die gaten opgevuld worden? Da's toch geen probleem? Een primary key is gewoon een 'administratief nummertje' voor je databank, en je hoeft je nu toch niet druk te maken of dat ID nu 1, 7, of 941211 is ?

whoami schreef op 10 januari 2004 @ 16:13:
[...]

Waarom? Je kan toch ook een veld opnemen met het nummer van die surat? Wat het ID dan is, maakt niet uit.
Daarnaast vind ik het eigenlijk niet zo goed, als je een 'betekenisvol veld' gebruikt als PK. Meestal maak ik een gewoon een extra auto-nummerveld bij in een tabel, wat ik dan gebruik als PK.

Als je bij iedere INSERT een dergelijke check moet doen, dan zal het op de lange duur nogal wat trager gaan om records te inserten.

[Verwijderd]

Limhes schreef op 02 mei 2004 @ 16:37:
[...]

Waarom wil je dit? Een ID dat je toekent aan een gebruiker/product/etc. is toch niet van belang voor de bezoeker van je site? Ik zie dus niet echt in waarom dit een probleem zou zijn... Een bezoeker tikt als het goed is namelijk geen URL in met de ID erin, maar bezoekt alleen een dergelijke link als hij ernaar doorverwezen wordt.

Ik vind het uitermate slordig om user ID's (lees offtopic note in TS) van 130.000 te hebben terwijl er maar 560 users werkelijk zijn.

Daarom heb ik dus TWEE unique id kolommen. De user_id die auto increment is die ook de link legt met alle andere DB onderdelen.

De outside_id is dus, zoals het al zegt, voor de buitenwereld.

Nu wil ik dus voornamelijk weten hoe ik op gaten in de numerieke volgorde kan controleren van de outside_user_id.

[whoami]

Wat heeft dat 'outside_user_id' dan eigenlijk van nut? Wat heeft een gebruiker dan aan wat het nummertje van z'n account oid is? Niks toch?

[djluc]

Wat is het nut van die outside id? Hij vertegenwoordigd niet een bepaalde waarde dus het is gewoon en loos getal. Die horen dus niet in de db. Dat je een mooi lijstje met nummers wilt hebben is ok->maar dan wel met PHP

edit:
x6^%&*&*

[ Voor 8% gewijzigd door djluc op 02-05-2004 17:01 ]

[Verwijderd]

Verwijderd schreef op 02 mei 2004 @ 16:27:
Mijn 1e vraag is: Hoe kan ik via php/mysql er voor zorgen dat zodra ik een user verwijder, de hoogste user_outside_id, deze waarde overneemt?

Voordat je de user verwijdert moet je met een variabele in de gaten houden welke id je hebt verwijdert (niet de auto_increment maar de andere). Na het verwijderen van de user, moet je de laatste user in je tabel op deze plek zetten met de opgeslagen id. De laatste user in je tabel kun je vinden door een MySQL-query op je tabel toe te passen bijvoorbeeld de id's aflopend sorteert. Dan lees je de eerste regel in en heb je de hoogste id te pakken die je kopieert naar de lege plek en vervolgens verwijder je hem natuurlijk (anders is hij dubbel).

Verwijderd schreef op 02 mei 2004 @ 16:27:
Mijn 2e vraag: Hoe zorg ik ervoor, mocht er door een ongelukje toch gaten komen in de user_outside_id, hoe check ik dat en hoe zorg ik er voor dat de hoogste user_outside_id's die gaten opvullen?

Op het moment van toevoegen van een nieuwe user kun je checken of er een lege plek is (probeer eerst op user_id 0 te zetten, anders op 1, anders op 2 etc totdat er een lege plek is > bij het uitlezen van een lege plek heb je geen data in user_name als het goed is, toch?). Maar je kunt natuurlijk ook een script maken op een aparte pagina dat checkt op lege plekken met dezelfde manier zoals hierboven beschreven. Als je dit even af en toe doet, dan kun je zelf die gaten wel opvullen, maar ik zou niet weten hoe die gaten zouden kunnen ontstaan. Let er gewoon op dat je bij het verwijderen van een user en bij het toevoegen de lege plekken in de gaten houdt.

edit:
Ik zie overigens ook het nut er niet zo van in, misschien moet je dit nog eens even duidelijk maken waarom je dit wilt. Misschien is er wel een andere oplossing die wat makkelijker werkt.

[ Voor 6% gewijzigd door Verwijderd op 02-05-2004 17:05 ]

[Arjan A]

Wat een klotediscussie is dit weer aan het worden.
Ik lees alleen maar "waarom wil je dat"-vragen en mogelijke conclusies
De topicstarter wil weten of er een mogelijkheid is om die gaten op te vullen.
In mijn eigen forum houd ik daarvoor een apart tabelletje bij, simpelkweg omdat met één query niet is te achterhalen wat het eerstvolgende vrije ID is.
Ik houd dit topic in de gaten om er misschien achter te komen dat het wel kan .

[whoami]

Arjan A schreef op 02 mei 2004 @ 17:05:
Wat een klotediscussie is dit weer aan het worden.
Ik lees alleen maar "waarom wil je dat"-vragen en mogelijke conclusies

Mag dat al niet meer?
Of moeten we mensen die fout bezig zijn, maar zo bezig laten?
Het opvullen van gaten heeft geen enkele zin, en zo'n outside_user_id heeft -met de info die we nu hebben- ook geen enkele zin.

De topicstarter wil weten of er een mogelijkheid is om die gaten op te vullen.
In mijn eigen forum houd ik daarvoor een apart tabelletje bij, simpelkweg omdat met één query niet is te achterhalen wat het eerstvolgende vrije ID is.
Ik houd dit topic in de gaten om er misschien achter te komen dat het wel kan .

Dat is dus gewoon onzin en onnodig. De gebruikers zien jouw id's niet, dus wat kan het hen wat schelen.

[Verwijderd]

Verwijderd schreef op 02 mei 2004 @ 16:27:
Als iemand dus bijvoorbeeld ?user=1 t/m ?user=784 intikt hij ook daadwerkelijk bij alle pagina's een user te zien krijgt.

Als het echt alleen hier om gaat dan kun je beter bij het 'afdrukken' van de tabel of wat dan ook checken of je idd informatie afdrukt of dat je geen info afdrukt. Ik bedoel dus dit:

- lees de info in (met een query of wat dan ook, je begrijpt het wel)
- kijk of de info ook info is (dus wel/geen user_name)
- als er een user_name in de ingelezen data voorkomt, dan druk je de data af (en anders lees je de volgende)

Ik ga er hierbij wel van uit dat als je bijvoorbeeld id 5 inleest en die bestaat niet, dat list() dan geen user_name bevat. Het inlezen kun je dan met een query (dus MySQL) doen die je aan een variabele toekent, bijvoorbeeld $result en vervolgens doe je list($1,$2,$etc)=mysql_fetch_row($result). Als dan de variabele van user_name een waarde bevat, dan druk je hem af en anders niet. Volgensmij moet dat werken.

[Olaf van der Spek]

Arjan A schreef op 02 mei 2004 @ 17:05:
Wat een klotediscussie is dit weer aan het worden.
Ik lees alleen maar "waarom wil je dat"-vragen en mogelijke conclusies

Het is IMO ook een niet zo slimme 'feature'. Externe bookmarks en links werken niet meer.

De topicstarter wil weten of er een mogelijkheid is om die gaten op te vullen.
In mijn eigen forum houd ik daarvoor een apart tabelletje bij, simpelkweg omdat met één query niet is te achterhalen wat het eerstvolgende vrije ID is.
Ik houd dit topic in de gaten om er misschien achter te komen dat het wel kan .

Het kan. Iets als:

SQL:

select a.id + 1 from t a left join t b on a.id + 1 = b.id where b.id is null.

[ Voor 3% gewijzigd door Olaf van der Spek op 02-05-2004 17:15 ]

[Verwijderd]

Volgensmij zijn we hier op een forum om elkaar te helpen. Dan mag er best worden gezegd dat het niet zo'n slim idee van de topicstarter is, maar dan hoeft dat niet tientallen keren herhaald te worden .

[Verwijderd]

OlafvdSpek schreef op 02 mei 2004 @ 17:13:
Het is IMO ook een niet zo slimme 'feature'. Externe bookmarks en links werken niet meer.

Maar deze kun je wel op je user_id (auto_increment) baseren

Edit:
Ik weet nu een leuke oplossing waarmee je snel kunt kijken of er sommige id's niet voorkomen. Doe het volgende:

- tel het aantal rows in je tabel (dit kun je krijgen met SHOW TABLE STATUS)
- haal de hoogste id die je zelf hebt 'verzonnen' uit je tabel
- vergelijk ze en je weet het (want als het aantal rows in je tabel geeft aan hoeveel id's er voorkomen)

[ Voor 44% gewijzigd door Verwijderd op 02-05-2004 18:09 ]

[Olaf van der Spek]

Verwijderd schreef op 02 mei 2004 @ 17:20:
Maar deze kun je wel op je user_id (auto_increment) baseren

Oh ja? Volgens mij is dat niet de bedoeling van de TS:

De reden van dit alles is, dat ik een mooie opeenvolgende nummers wil hebben in de users. Als iemand dus bijvoorbeeld ?user=1 t/m ?user=784 intikt hij ook daadwerkelijk bij alle pagina's een user te zien krijgt.

[raps]

Bij inserten pak je de MAX(user_outside_id) + 1. Je zorgt dat bij het deleten alles goed wordt gezet:

Voorbeeld (id=10)

Je verwijderd een record:

code:

$out_id = SELECT user_outside_id FROM users WHERE id=10
DELETE FROM users WHERE id=10

dan zet je vanaf je id alle waardes daarboven eentje lager:

code:

UPDATE users SET user_outside_id = user_outside_id - 1 WHERE user_outside_id > $out_id

(stukje PHP raar gebruikt)

[ Voor 11% gewijzigd door raps op 02-05-2004 18:39 ]

[Creepy]

raps schreef op 02 mei 2004 @ 18:38:
Bij inserten pak je de MAX(user_outside_id) + 1. Je zorgt dat bij het deleten alles goed wordt gezet:

Voorbeeld (id=10)

Je verwijderd een record:

code:

$out_id = SELECT user_outside_id FROM users WHERE id=10
DELETE FROM users WHERE id=10

dan zet je vanaf je id alle waardes daarboven eentje lager:

code:

UPDATE users SET user_outside_id = user_outside_id - 1 WHERE user_outside_id > $out_id

(stukje PHP raar gebruikt)

Nu verwijdert de eerste persoon een user met ID 10. De tweede tegelijk een user met ID 11.

10 wordt verwijdert en gaat hernummeren. 11 wordt nu verwijdert.. Oops, dat is ineens het verkeerde record aangezien na het verwijderen van 10 nummer 12 11 is geworden.

Als je zo een oplossing geeft meld dan in elk geval dat je gebruik maakt van locking, en dat je checkt dat wat je gaat verwijderen ook nog klopt.

Ik vraag me eigenlijk nog steeds af waarom je deze opvolgende nummering wilt hebben..

[Verwijderd]

OlafvdSpek schreef op 02 mei 2004 @ 18:23:
[...]

Oh ja? Volgens mij is dat niet de bedoeling van de TS:

Je zou best gelijk kunnen hebben, maar neem het volgende voorbeeld:

Ik heb het idee dat de TS deze manier van id's wilt gebruiken omdat hij anders problemen heeft met het afdrukken van de gegevens. Ik neem als voorbeeld even dat er een lijst wordt afgedrukt met een aantal berichten. Elk bericht is van een andere user en er moet een lijst worden afgedrukt van 10 berichten. Nou, op de manier van id's zoals de TS het wil, is dit heel makkelijk en kan alles zo worden afgedrukt (id 1..10). Moet er nu bijvoorbeeld een link naar een bepaalde user worden gelegd waar bijvoorbeeld info over deze user te zien is, dan kan er in de link gebruik worden gemaakt van het auto_increment_id waardoor de link altijd klopt. Dit id wordt namelijk niet gewijzigd bij het verschuiven van de data om de tabel op te vulllen. Misschien beetje verkeerd voorbeeld, maar ik weet het anders ook niet uit te leggen wat ik bedoel

edit:
dus als de topicstarter nou even uitlegt waarom hij dit nou precies wilt doen, dan is het wat makkelijker een juiste oplossing te vinden en te kijken of het inderdaad nodig is om op deze manier de id's te gebruiken

[ Voor 10% gewijzigd door Verwijderd op 02-05-2004 19:07 ]

[Verwijderd]

Bedankt voor alle antwoorden en hulp.

Het gaat er allemaal om, dat ik zaken goed geordend zie. Ik vind het bijvoorbeeld storend als er een product is met een id van 4700 terwijl er maar 2400 producten in de DB zitten.

Het lijkt me dus het beste om als er een nieuw product in de DB komt, er gekeken wordt naar de eerst vrije beschikbare outside_id. Nu is het natuurlijk vreemd om een user bestand te hebben met iemand die een aantal dagen is geregistreerd en die een ID heeft van 80 terwijl 't aantal aangemeldde users bij 5000 is. Ik had misschien in m'n startpost beter een ander voorbeeld kunnen nemen

[alt-92]

Verwijderd schreef op 02 mei 2004 @ 21:16:
Bedankt voor alle antwoorden en hulp.

Het gaat er allemaal om, dat ik zaken goed geordend zie. Ik vind het bijvoorbeeld storend als er een product is met een id van 4700 terwijl er maar 2400 producten in de DB zitten.

Wat nu als je nog ergens een query hebt die verwijst naar produkt x met id 123 maar inmiddels heb je daar produkt aa inzitten omdat je id 123 niet leeg wil laten?

Alleen maar "omdat dat netter is" ?

[whoami]

Verwijderd schreef op 02 mei 2004 @ 21:16:
Bedankt voor alle antwoorden en hulp.

Het gaat er allemaal om, dat ik zaken goed geordend zie. Ik vind het bijvoorbeeld storend als er een product is met een id van 4700 terwijl er maar 2400 producten in de DB zitten.

Het lijkt me dus het beste om als er een nieuw product in de DB komt, er gekeken wordt naar de eerst vrije beschikbare outside_id. Nu is het natuurlijk vreemd om een user bestand te hebben met iemand die een aantal dagen is geregistreerd en die een ID heeft van 80 terwijl 't aantal aangemeldde users bij 5000 is. Ik had misschien in m'n startpost beter een ander voorbeeld kunnen nemen

Je moet je dat allemaal niet teveel aantrekken; dergelijke 'controlesystemen' zorgen meestal enkel voor een performance-verlies.

Trouwens, van dat 'netter' zijn, wie ziet dat? De gebruiker ziet het niet, jij misschien wel. Een PK is gewoon een administratief nummertje dat nodig is om je record uniek te maken.

[ Voor 12% gewijzigd door whoami op 02-05-2004 21:34 ]

[Verwijderd]

BackSlash32 schreef op 02 mei 2004 @ 21:30:
[...]

Wat nu als je nog ergens een query hebt die verwijst naar produkt x met id 123 maar inmiddels heb je daar produkt aa inzitten omdat je id 123 niet leeg wil laten?

Alleen maar "omdat dat netter is" ?

In dat geval kan hij het auto_increment id in zijn query gebruiken

[Verwijderd]

dat is leuk, dan heb je een variabele userid ik zie persoonlijk het nut niet maar denk dat het updaten van de hoogte item naar een verwijderde id het meest functionele is... of anders als je het nog leuker wilt doen geef gewoon iedere user een soortement van random text als id {user=9X943S)

[ Voor 28% gewijzigd door Verwijderd op 02-05-2004 21:39 ]

[alt-92]

@HereIam:
Gaat er juist om dat produkt x er NIET meer is maar zn record nu naar produkt aa verwijst ipv een "not found" .

[Verwijderd]

Normaal gesproken moet er niet zomaar een product uit een database compleet worden verwijderd. Je zou je ook niet bezig moeten houden met het id. Het enige wat een id moet zijn, is uniek. Recyclen vind ik geen goed plan. Dat zorgt er alleen maar voor dat je ook alle relaties moet verwijderen als je een product uit de database verwijdert. (Wat ik dus al niet zo'n goed plan vind) Kun je een reden geven waarom je überhaupt weleens producten verwijdert?

[alt-92]

[very big assumption mode]
Die is er niet, dus zou die ID ook niet vrijkomen lijkt me dan.
in dat geval: waar hebben we het nog over?

[whoami]

Verwijderd schreef op 02 mei 2004 @ 21:42:
Dat zorgt er alleen maar voor dat je ook alle relaties moet verwijderen als je een product uit de database verwijdert. (Wat ik dus al niet zo'n goed plan vind)

Eh? Als je een produkt verwijderd uit een DB, en je wilt de gegevens consistent houden (geen orphan records enzo), dan heb je 2 mogelijkheden als het te verwijderen produkt gerelateerde records heeft in andere tabellen:
- weigeren van het produkt te verwijderen
- produkt en alle gerelateerde records van dat produkt verwijderen.

[mylar]

of het product gewoon disabled zetten

[Verwijderd]

Twee redenen om een product te verwijderen uit je DB:

- Door een (type)foutje staat een product er twee maal in en moet één van beide verwijderd worden.
- Achteraf blijkt het product helemaal niet in de DB horen te staan.

De data wordt door mensen ingevuld en een typefoutje is snel gemaakt. Natuurlijk kun je dat afvangen door de in te vullen data te vergelijken met de al bestaande data, maar tegen menselijke fouten kun je je niet 100% beschermen.

Daarnaast kan het best voorkomen dat er een item wordt toegevoegd die achteraf er helemaal niet in hoorde te staan.

Nu gebruik ik in de DB voor een tabel een autoincrement id. De id's die je ziet bij ?item=500 zijn dus voor de link op internet en nergens anders voor. Ze zullen in de DB ook voor geen enkel ander doel gebruikt worden. Nogmaals: een relatie die gelegd wordt tussen twee tabellen gebeurd dmv het unieke autoincrement id.

Ik geef toe, het maakt voor de werking van de DB geen bal uit . Maar zoals zoveel dingen in het leven gaat het om het uiterlijk. En voor mij gaat het ook om de ordelijkheid, dat het hoogste ID ook de totaal aantal aan producten weergeeft.

[Bosmonster]

Het gaat er allemaal om, dat ik zaken goed geordend zie. Ik vind het bijvoorbeeld storend als er een product is met een id van 4700 terwijl er maar 2400 producten in de DB zitten.

Je vindt het storend dat je een ID ziet die anders is dan het aantal producten Waarom stoor je je een een ID, die niks anders is als een IDENTIFIER voor de data in een DB. Jij plakt er visuele (het moet 'mooi' zijn) en andere betekenissen (zoals 'totale aantal') aan, waar de ID helemaal niet voor bedoeld is.

Als je wilt dat producten mooi te benaderen zijn, geef ze dan een soort tekstuele shortcut.

[bartware]

offtopic: ik denk dat er nu wel vaak genoeg is gezegd waar id's voor dienen. TS weet dat ook wel.

Persoonlijk heb ik ook zoiets: ik heb een tabel die als lijstje op het scherm wordt gerepresenteerd. Id is uiteraard increment.
Er kunnen items worden toegevoegd en verwijderd.
Maar ook in de lijst omhoog en omlaag gezet. De volgorde is belangrijk. Ik heb dus belang bij een tweede id, bij mij 'rank' genaamd.

Bij elke operatie moet deze rank worden bijgewerkt, want ik wil deze lijst in deze volgorde tonen. Als ik een item toevoeg moet hij MAX(rank) + 1 krijgen.
Bij verwijderen of verschuiven hernummer ik de hele lijst. (met locking) .

Voor de TS betekent het dat bij verwijderen het item met MAX (outside_id) wordt geupdate met de vrijgekomen outside_id. Zoals eerder genoemd.

[Verwijderd]

misschien kan je het oplossen door de user niet een echte kolom in de database te laten zien, maar een resultaat van een query, iets als:
select count(*) from users where id=<$pk_user;

op die manier hoef jij je database niet te "vervuilen" met nietszeggende id's en hebben de gebruikers een mooi nummertje om tegenaan te kijken.

vervolgens kan je desbetreffende user (/product/whatever/..) weer opvragen met iets als:
select * from users limit $pk_user,1

_{ff quick and dirty}

[MSalters]

Als ik het goed zie kost dit je wel een table lock, in plaats van een rowlock? Want je kunt hooguit een row delete tegelijkertijd hebben, omdat de tweede row delete dezelfde laatste row zou willen hernummeren.

[seweso]

Als je id's wil hergebruiken moet je in één ondeelbare actie het volgende doen:
- een her-te-gebruiken id opzoeken
- deze id in gebruik nemen

Want anders kun je (als er tegelijkertijd een nieuw record word aangemaakt) dubbele id's krijgen.

[Bosmonster]

MSalters schreef op 03 mei 2004 @ 15:16:
Als ik het goed zie kost dit je wel een table lock, in plaats van een rowlock? Want je kunt hooguit een row delete tegelijkertijd hebben, omdat de tweede row delete dezelfde laatste row zou willen hernummeren.

MySQL ondersteunt alleen table-locks, geen row-locks.