legen van de database
Ben het niet met je eens ;).
Hoe bepaal jij of dat wel of geen betekenis heeft voor de gebruikers? Hoe klein de groep gebruikers ook, er zijn altijd mensen die graag hun eerste record id=1 willen geven, al is het maar voor de look alleen.. Voor sommige mensen heeft een km stand ook geen betekenis. Die rijden hun auto gewoon op totdat hij niet meer van zijn plaats komt. Dat is met een database het zelfde. Wanneer al je unieke id's op zijn dan stopt je database met zich te vullen.
Laat ik een ander praktisch voorbeeld geven wanneer het wel degelijk noodzakelijk is je autoincrement naar 0 te zetten. Stel je hebt een werkend systeem geinstalleerd op een webserver met database etc. Je wilt op een gegeven moment een precies het zelfde systeem gaan plaatsen voor een andere gebruiker met dezelfde database. Je exporteerd dus de ene database en importeerd deze bij de andere gebruiker zijn webserver. Omdat je de autoincrement niet naar 0 had gezet krijgt de 2e gebruiker een systeem waarbij de tabellen veel eerder uit hun unieke id's zullen zijn omdat de teller niet bij 0 begon. Nou is dit bij een systeem met weinig inserts nog niet zo erg, maar wanneer het een "groot systeem" met veel inserts betreft wel, wat ook weer nare consequenties kan hebben. Ik vind het daarom kort door de bocht om te zeggen dat een autoincrement naar 0 zetten voor iedereen fout, gevaarlijk, zinloos etc. is.
Mijn voorbeeld diende trouwens ook niet t.o.v. hergebruik van id's waarop jij wel reageerde. Zoals ik al eerder aangaf is hergebruik niet aan te raden, ik wou alleen aangeven dat het wel gewoon kan.
Quote:
Dat zegt in dit geval wel iets over hun intelligentie, of eigenlijk het gebrek daaraan... al is het maar voor de look alleen.
Een auto slijt naarmate hij meer km's maakt, een database slijt niet.
Hou toch op met deze onzin. Ga eens bij een bank of verzekeringsmaatschappij werken en kom met het voorstel om met je vingers aan de auto_increment te zitten. Ik vrees dat je laatste uurtje is geslagen.
Ik heb het hier helemaal niet over bestaande systemen, dus ook niet van banken of verzekeringmaatschappijen! Voor mij part de NASA!
Ik heb het hier over NIEUWE BLANCO SYSTEMEN!!!!
Dit was ook waar vraag van de poster van dit topic oorspronkelijk het over ging (LEZEN!).
Vind jij het dan normaal dat als je een nieuw systeem installeert bij een gebruiker je de helft van de id's al laatwegkomen voordat het systeem daadwerkelijk draait? Zodat jij als beheerder deste eerder hun database kan komen verschonen?! Ik denk dat jouw laatste uurtje dan ook wel geslagen heeft ;)
Jaws schreef op 03.09.2007 12:22:
@Jan:
... tabellen veel eerder uit hun unieke id's zullen zijn omdat de teller niet bij 0 begon....
... tabellen veel eerder uit hun unieke id's zullen zijn omdat de teller niet bij 0 begon....
9223372036854775807
Dat zal inderdaad sneller gebeuren
bron
Gewijzigd op 01/01/1970 01:00:00 door Klaasjan Boven
Quote:
Klaasjan heeft je al een indruk gegeven van het aantal id's dat beschikbaar is, de kans dat jij tijdens het live-testen zoveel id's verbruikt is niet zo groot.Vind jij het dan normaal dat als je een nieuw systeem installeert bij een gebruiker je de helft van de id's al laatwegkomen voordat het systeem daadwerkelijk draait?
En wat ik normaal vind? Een systeem gaat live en daarna gaan de beheerders eerst nog even een rondje testscripts uitvoeren. Bv. wat betalingsopdrachten of verzekeringspolissen aanmaken en laten verwerken. Dit is de normaalste zaak van de wereld, ook voor splinternieuwe systemen. Je denkt toch niet dat we dan na afloop de auto_increment op 0 hebben gezet? Moet er niet aan denken!
Zorg er voor dat je voor het id een BIGINT of BIGSERIAL gebruikt, dan heb je de garantie dat je tijdens dit leven nooit in de problemen komt. Resetten van de auto_increment komt dus niet voor. Het kost je hooguit een paar extra bits opslag, maar dat is alles. Daarvoor ga je echt niet het risico lopen dat je moet gaan resetten.
(Heb 10 jaar met dit soort toepassingen gewerkt, ik weet dus echt wel waar ik over praat)
Edit: Nu wordt het leuk, met cijfers gooien!
Een BIGINT heeft als hoogste waarde 18446744073709551615. Wanneer je per dag 1 miljoen records aanmaakt, dan kun je dus zo'n 50.539.024.859 jaar doorwerken zonder in de problemen te komen. Daar maak ik me niet druk over, ik heb de pensioengerechtigde leeftijd dan al lang bereikt!
;)
(Heb ik nergens een rekenfoutje gemaakt?)
Gewijzigd op 01/01/1970 01:00:00 door Frank -
nou dat was moeilijk zeg
(Heb 3 jaar frank moeten aanhoren, ik weet dus waar ik het over heb)
Gewijzigd op 01/01/1970 01:00:00 door - wes -
Jij deed dit: (18446744073709551615/1000000)/365 Dat is goed het kan echter exacter:
(18446744073709551615/1000000)/365.25
ER zijn tenslotte schrikkeljaren en dat maakt redelijk wat uit over zoveel jaar:
((18446744073709551615/1000000)/365)-((18446744073709551615/1000000)/365.25) = 505044327 jaar verschil
Gewijzigd op 01/01/1970 01:00:00 door Citroen Anoniem Graag
Jaws schreef op 28.08.2007 23:23:
... net zoals je een auto ook koopt met een km-teller die bij 0 begint ...
Als je een auto koopt met de teller op 000000 dan garandeer ik je dat daar mee is geknoeid. Auto's ondergaan testen waardoor de stand niet meer op 000000 zal staan als de auto bij de dealer aankomt.