het veiligste/beste lijkt me om je id's zelf te genereren door bv een timestamp oid te nemen,
dan weet je altijd zeker onder welke id een row wordt toegevoegd en dat het een unique is.
echter,
je kan er ook voor kiezen om gewoon je id's te laten auto-incrementen door mysql.
nou vraag ik me af in hoeverre dat fout gaat in de volgende situatie:
stel je stopt een nieuwe entry in je db maar wil tegelijker tijd ook weten wat de id daarvan is geworden.
dan kan je natuurlijk meteen na je insert statement een max(id) opvragen en dan weet je wat het hoogste/laatst toegevoegde id is en dat zal dan ook die id zijn van die row die je net hebt toegevoegd (je kan dit ook doen voordat je een nieuwe insert doet en er dan 1 bij optellen).
anyway, dit gaat goed, maar als je een systeem hebt waar vele duizende users tegelijk in die db aan het harken zijn dan kan het wel eens gebeuren dat er zoveel inserts zijn dat tegen de tijd dat je de max(id) opvraagt er alweer inserts tussen door zijn geweest en dus de id die je terug krijgt niet de id is van de row die je verwacht...snappie?
nou zou je de db kunnen locken en zo forceren dat niemand iets kan toevoegen zolang jij nog bezig bent die id te achter halen.
nadeel lijkt me dan weer dat als je dan juist op zo'n druk systeem zit de heleboel ontzettend traag word door al die locks, niet?
punt is,
de auto increment functie zit er niet voor niets in,
maar is het dan mischien een soort van vaak gemaakte fout om hem voor id's te gebruiken?
wat is de beste oplossing,
ik neem aan zelf je id's genereren, niet?
dan weet je altijd zeker onder welke id een row wordt toegevoegd en dat het een unique is.
echter,
je kan er ook voor kiezen om gewoon je id's te laten auto-incrementen door mysql.
nou vraag ik me af in hoeverre dat fout gaat in de volgende situatie:
stel je stopt een nieuwe entry in je db maar wil tegelijker tijd ook weten wat de id daarvan is geworden.
dan kan je natuurlijk meteen na je insert statement een max(id) opvragen en dan weet je wat het hoogste/laatst toegevoegde id is en dat zal dan ook die id zijn van die row die je net hebt toegevoegd (je kan dit ook doen voordat je een nieuwe insert doet en er dan 1 bij optellen).
anyway, dit gaat goed, maar als je een systeem hebt waar vele duizende users tegelijk in die db aan het harken zijn dan kan het wel eens gebeuren dat er zoveel inserts zijn dat tegen de tijd dat je de max(id) opvraagt er alweer inserts tussen door zijn geweest en dus de id die je terug krijgt niet de id is van de row die je verwacht...snappie?
nou zou je de db kunnen locken en zo forceren dat niemand iets kan toevoegen zolang jij nog bezig bent die id te achter halen.
nadeel lijkt me dan weer dat als je dan juist op zo'n druk systeem zit de heleboel ontzettend traag word door al die locks, niet?
punt is,
de auto increment functie zit er niet voor niets in,
maar is het dan mischien een soort van vaak gemaakte fout om hem voor id's te gebruiken?
wat is de beste oplossing,
ik neem aan zelf je id's genereren, niet?
"I disagree with what you are saying, but I will defend to the death your right to say it." -- not clear who
:strip_icc():strip_exif()/u/43029/insp8200_60x60.jpg?f=community)
:strip_exif()/u/17059/joost.gif?f=community)
:strip_exif()/u/3398/rh.gif?f=community)