eerste vrije id gebruiken
Ik ben bezig met een database waar een garantie op is dat er minstens 4 miljard records in kunnen (wat mogelijk uitloopt tot vele miljarden), nu ben ik bezig met een functionaliteit waarmee ik alle acties log van een gebruiker in me db omdat dat op te vragen moet zijn.
De discussie of dit wel of niet in een db moet staan is niet relevant, die is al geweest en besloten toch een db te gebruiken op betere zoek mogelijkheden.
Nu is mijn vraag, hoe kan ik alle vrije id's gebruiken?
Nu is de id colom auto_increment, en dat moet het niet zijn, want de gelogde acties kunnen ook per gebruiker verwijderd worden, en dan valt er een mogelijk gat van 200 records. nu wil ik dat alle query's de eerst mogelijke id pakken die vrij is zodat we niet een gatenkaas db krijgen..
Ik weet dat ik dit zou kunnen oplossen door een loopje te maken en zo het id te kunnen krijgen, maar dat is niet echt handig als er straks miljarden records zijn.
Weet iemand of hier een standaard functie voor is zoals insert_id()
bigint 8 bytes large-range integer -9223372036854775808 to 9223372036854775807
http://dev.mysql.com/doc/refman/5.1/en/numeric-type-overview.html
A large integer. The signed range is -9223372036854775808 to 9223372036854775807. The unsigned range is 0 to 18446744073709551615.
Van je id moet je afblijven. Een gat in je id's moet geen probleem zijn.
Past het ook niet meer in een bigint en heb je echt veel gaten dan houdt je een opschoon actie (of nog beter) zorg huur je een paar professionals in die je kunnen adviseren wat de mogelijkheden zijn en wat het beste is. Maar dan ben je al een stuk verder en moet het geld daarvoor ook geen probleem zijn.
Gewijzigd op 01/01/1970 01:00:00 door TJVB tvb
de database is een genormaliseerd database (waar alleen geen rekening is gehouden met een history_action tabel ) en deze ga ik nu toevoegen..
Elke actie die een gebruiker loslaat op een item moet gelogt worden zodat bij fouten oid terug te zien is wie wat gedaan heb.
dus het tusse tabelletje word een simpel tabel:
id - item_id - action_is - user_id
met de koppeling action_id naar een action tabbeletje:
id - discription
aangezien er 4 miljard items in kunnen, moet ik wel rekening houden met de mogelijkheid dat er op elk item minimaal 10 acties komen (40 miljard history actions dus)
Wat TJVB al aangaf:
TJVB schreef op 28.04.2009 12:52:
http://www.postgresql.org/docs/8.1/static/datatype.html
bigint 8 bytes large-range integer -9223372036854775808 to 9223372036854775807
http://dev.mysql.com/doc/refman/5.1/en/numeric-type-overview.html
A large integer. The signed range is -9223372036854775808 to 9223372036854775807. The unsigned range is 0 to 18446744073709551615.
bigint 8 bytes large-range integer -9223372036854775808 to 9223372036854775807
http://dev.mysql.com/doc/refman/5.1/en/numeric-type-overview.html
A large integer. The signed range is -9223372036854775808 to 9223372036854775807. The unsigned range is 0 to 18446744073709551615.
had ik al rekening mee gehouden, het ging mij meer om, stel een item word verwijderd (plus de history op dat item) dat er dan een mogelijk gat komt (van misschien wel 2000 rows), wat ik wil opvulle met nieuwe history, zodat de kans groter is dat ik geen db limit behaal.
- 4 miljard item
- elke actie op een item word gelogt
- stel je voor systeem draaid al 10 jaar
- klant kennende word er zo min mogelijk verwijderd (stel je voor je gooit wat weg wat je 2 jaar later nodig heb)
- etc etc
maar ik krijg de indruk dat ik me druk maak om niets dus zal wel ff wat testjes runnen hiermee, bedankt voor de feedback mensen :)
En een id is een uniek gegeven. Als jij ID's zelf gaat wijzigen krijg je vanzelf corrupte database. Tenzij dit gewenste functionaliteit is, niet doen.
TJVB schreef op 28.04.2009 13:19:
En waar haal je die 4 miljard vandaan? Dat vindt ik al interessant.
Dat is een garantie die bij het produkt verkocht word
Arjan Kapteijn schreef op 28.04.2009 13:20:
Denk zelfs dat het trager word als we jouw oplossing gebruiken, verschillende acties die 'in tijd' dicht bij elkaar liggen kunnen dan qua ID aan de hele andere kant zitten. Wat de schrijfacties van een hardeschijf weer langzamer maken.
Hier heb je inderdaad een goed punt.
Jurgen schreef op 28.04.2009 13:23:
Waarom deleten? Gewoon inactief zetten?
Als een item verwijderd word, bestaat de log nog (deze moet apart verwijderd worden, aangezien het verwijderen van het item ook een actie is), maar als de log uiteindelijk verwijderd word (wat alleen beheerders kunnen), moet deze ook gewoon weg zijn, het heeft geen meer waarde om deze te bewaren. Anders gebruik ik inderdaad de inactief methode.
Bedankt voor jullie hulp, ik zie nu dat ik de gaten niet hoef op te vullen, en mocht er ooit een dag komen dat het limiet in de beurt komt, dan is mijn ervaring vast wel zo ver om het dan alsnog op te lossen :p