ID's database tabellen

Wat doe je als je een tabel hebt die vaak gebruikt wordt, en waarvan je database ID's op kunnen raken? Wordt er dan een foutmelding gegeven door het databasesysteem?

Ik gebruik MySQL.

Hmm, met een UNSIGNED BIGINT moet het toch wel raar zijn als de ID's opraken


(((18 446 744 073 709 551 615 / 60) / 60) / 24) / 365 = 5.84942417 × 10^11

Als je zorgen maakt kun je ook gaan werken met letters.

[Klaas B.]

Sowieso is die angst ongegrond lijkt me, als je AUTO_INCREMENT hebt aangezet.

@**********:
Je bedoelt dat je een string (text) type gebruikt als ID? Ja, dat zou inderdaad kunnen (of meerdere BIGINT velden), maar een BIGINT veld lijkt me nu toch wel voldoende.

@Klaas B.:
AUTOINCREMENT heb ik inderdaad aan staan. Maar ID's hergebruiken is voor mij niet een goed plan denk ik, en heb ik ook niet aanstaan.

Maar zelfs als ik ID's niet hergebruik moet het wel heel raar lopen als ik gedurende de levensduur van mijn website (of vele malen de levensduur van mijn website) niet genoeg zou hebben aan een BIGINT.

Immers, als er elke seconde een nieuw ID zou worden geproduceerd, dan zou het nog 5.84942417 × 10^11 jaar duren voordat de ID's op zijn.

[Klaas B.]

Ja, serieus, wat is je probleem?

Klaas B. schreef op 17-06-2007 @ 17:25 :
Ja, serieus, wat is je probleem?

Ik hou bij, bij welk ID ik ben, en moet er daarbij van uit kunnen gaan dat ik ID's onder dat nummer (en het ID zelf) al gehad heb. Zou ik ID nummer 6 hebben opgeslagen en er vervolgens een aantal ID's gewist zijn en weer een aantal bijgekomen zijn, dan kijk ik alleen naar ID's > 6, terwijl er nieuwe ID's onder de 6 zijn bijgekomen, in geval van hergebruik.

Dit omdat er meerdere gebruikers achter een website kijken naar binnengekomen berichten, en niet telkens alle berichten opgehaald moeten worden, maar alleen nieuwgekomen berichten.

[Dr HenDre]

Mis het nut van dit topic als je zelf je vragen beantwoord.
Anyway, als je een unsigned 32 bits integer pakt heb je 4294967296 mogelijke waarden.
Pak je een 64 bits integer heb je 18446744073709551616 verschillende ID's.
Lijkt me meeeeer dan voldoende

Dr HenDre schreef op 17-06-2007 @ 21:00 :

Mis het nut van dit topic als je zelf je vragen beantwoord.
Anyway, als je een unsigned 32 bits integer pakt heb je 4294967296 mogelijke waarden.
Pak je een 64 bits integer heb je 18446744073709551616 verschillende ID's.
Lijkt me meeeeer dan voldoende

Toen ik deze vraag postte dacht ik dat een BIGINT best wel groot zo zijn (vandaar ook de naam natuurlijk), maar wist niet dat ie zo groot was, dacht dat het toch wel eens problemen op kon leveren.

Toen ik 'm gepost had, ging ik toch maar even kijken hoe groot ie precies was, en toen bleek dus dat ie wel erg groot was. En toen had ik dit ook gepost (zie het bericht onder mijn eerste bericht in dit topic).

Daarna kwamen er toch nog antwoorden, dus reageerde ik daar op. Ik was ook wel benieuwd of anderen er misschien andere gedachten over hadden, of gedachten over zaken die er mee te maken hebben. Wat is daar mis mee?!?!

[deefeketje]

Als je een MySQL database gebruikt op een gehoste server (met webhosting ofzo) moet je er wel op letten dat je zoveel entries kan hebben in een databank.
bij vele staat deze gelimiteerd op zo'n 76.000 ofzoiets
wat je ook altijd kan doen is een datum toevoegen ofzo, dan kan je je berichten rangschikken op datum, en niet op ID

deefeketje schreef op 18-06-2007 @ 09:42 :
Als je een MySQL database gebruikt op een gehoste server (met webhosting ofzo) moet je er wel op letten dat je zoveel entries kan hebben in een databank.
bij vele staat deze gelimiteerd op zo'n 76.000 ofzoiets
wat je ook altijd kan doen is een datum toevoegen ofzo, dan kan je je berichten rangschikken op datum, en niet op ID

Dat is niet zo prettig als iets in dezelfde datum (tot op de seconde ofzo) word gedaan

********** schreef op 18-06-2007 @ 13:21 :
Dat is niet zo prettig als iets in dezelfde datum (tot op de seconde ofzo) word gedaan

Inderdaad, om die reden gebruik ik ook ID's.

deefeketje schreef op 18-06-2007 @ 09:42 :
Als je een MySQL database gebruikt op een gehoste server (met webhosting ofzo) moet je er wel op letten dat je zoveel entries kan hebben in een databank.
bij vele staat deze gelimiteerd op zo'n 76.000 ofzoiets
wat je ook altijd kan doen is een datum toevoegen ofzo, dan kan je je berichten rangschikken op datum, en niet op ID

Ik wist niet dat er een limiet op zat. Ik heb bij mijn vorige gratis hosting provider (Funpic.org) wel steeds gehad dat na een tijd een vrij grote tabel van mij werd gewist.

Lijkt me wel gek dat de hele tabel dan gewist zou worden nadat zo'n limiet bereikt is. Maar je weet maar nooit. Ik had een mailtje daarover naar m'n hosting provider gestuurd, of zij er meer van wisten, maar die hadden daar niet op gereageerd.

Ik heb m'n database beveiligd tegen SQL injectie, dus hoop nog steeds maar dat het daar niet door gekomen is. Lijkt me sterk eigenlijk, want dan zou men wel een belangrijkere tabel wissen.

Hoewel... Je hoeft voor de gewiste tabel geen account te hebben. Toch denk ik niet dat het om SQL injectie gaat.

Gelukkig was die niet echt van belang voor het functioneren van mijn weblog. Bovendien maak ik ook wel backups.

[Klaas B.]

Het nut van deze topic ontgaat me echt aan alle kanten.

Klaas B. schreef op 18-06-2007 @ 20:39 :
Het nut van deze topic ontgaat me echt aan alle kanten.

Het nut van jouw bericht begaat mij ook aan alle kanten. Post dan ook niet in dit topic. Je hebt een keuze!

Mijn vraag is ook beantwoord, door mezelf ook al eigenlijk. Dus het topic mag van mij ook best dicht. Alleen post gewoon niet als je van een topic het nut niet inzit, ongeacht of het werkelijk nut heeft of niet.

********** schreef op 18-06-2007 @ 13:21 :
Dat is niet zo prettig als iets in dezelfde datum (tot op de seconde ofzo) word gedaan

Daar heb je dan een timestamp voor.

Verder hebben sommige RDMBS'en ook ondersteuning voor GUIDs als (alternatief voor) integer PKs.

eddie schreef op 18-06-2007 @ 21:05 :
Daar heb je dan een timestamp voor.

Verder hebben sommige RDMBS'en ook ondersteuning voor GUIDs als (alternatief voor) integer PKs.

Een timestamp bevat toch een tijd? En als er door verschillende gebruikers op dezelfde tijd wordt gepost, dan kun je aan de hand van zo'n timestamp niet meer nagaan wie het eerst iets heeft gepost.

Een oplopend ID nummer verschilt altijd per rij.

[Rob]

12Trix schreef op 18-06-2007 @ 21:09 :
Een timestamp bevat toch een tijd? En als er door verschillende gebruikers op dezelfde tijd wordt gepost, dan kun je aan de hand van zo'n timestamp niet meer nagaan wie het eerst iets heeft gepost.

Een oplopend ID nummer verschilt altijd per rij.

Timestamps van PHP en Java zijn bijvoorbeeld tot op de seconde nauwkeurig. Ik zou de kans dat iemand op dezelfde tijd iets post, niet erg groot schatten.
Then again, Murphy komt op de meest rare plaatsen om de hoek kijken.

Rob schreef op 18-06-2007 @ 22:37 :
Timestamps van PHP en Java zijn bijvoorbeeld tot op de seconde nauwkeurig. Ik zou de kans dat iemand op dezelfde tijd iets post, niet erg groot schatten.
Then again, Murphy komt op de meest rare plaatsen om de hoek kijken.

Naarmate het aantal gebruikers toeneemt wordt die kans groter. Niet dat ik zoveel gebruikers zal krijgen, maar ik wil sowieso geen risico lopen.