Rupesi tuossa ihmetyttämään, että mitenkä tietokannoissa esim. ID-numeroiden kanssa menetellään kun ne loppuvat? Jos vaikka kuvitellaan, että olisi määritelty johonkin tauluun viisimerkkinen ID, jota aina yhdellä korotetaan kun lisätään arvoja, niin nehän loppuu joskus. Pystyykö tauluja vaikka tiivistämään jotenkin niin, että kun ID-numeroissa alkaa olla rakoja (poistettuja tietoja), niin raot voisi jotenkin tiivistää?
Jos noin käy niin ei voi sanoa tietokannan suunnittelijalle kuin EVO :D
Jos ID-kenttää käyttää, ei ikinä pidä käyttää loogisinta vaihtoehtoa, vaan aina suurinta mahdollista kokonaislukuvaihtoehtoa. MySQL:llä tämä olisi BIGINT joka nielaisee lukuja aina 18 446 744 073 709 551 615 asti (eli hieman reilu 18 446 triljoonaa jos muistin oikein).
Joo, ei ole itsellä noin käynyt, mutta tuli mieleen. :)
Normaali INT tyyppinen arvo käyttää 32 bittiä muistia, ja unsigned arvolla sillä voidaan ilmaista lähes 4 300 000 000, eli 4,3 miljardia, kokonaislukua. Täten useimmissa tapauksissa BIGINTin käyttö (64 bit) on vähintäänkin turhaa, maailman suurimmalla keskustelufoorumillakaan ei ole edes miljardia viestiä. Liian laajoiksi määritellyt datatyypit vievät vain turhaa muistia, ja syövät palvelimen suorituskykyä ihan turhaan (ja tätäkautta tietenkin hidastavat itse sovelluksen suoritusta).
Eli yleisesti ottaen suunnitella ne datatyypit vastaamaan sitä todellista käyttöä. Datatyyppejä voi sitten tarvittaessa muuttaa alter table komennolla. Tietenkään hirveän tiukasti niitä ei kuitenkaan kannata määritellä, ettei niitä tarvitse jatkuvasti olla rukkaamassa.
Nyt en enää löytänyt sitä vertailutestiä joka tehtiin 4 miljardilla tietueella, aluksi avaimena 32bit ja tämän jälkeen avaimena 64bit. Nopeuserot oli kuitenkin luokkaa "joitakin mikrosekunteja", ja ainoa käytännön ero oli, että 64bit avaimella tilanvienti oli muistaakseni noin 15 megatavua enemmän. Tosin kantana oli PostgreSQL, en tiedä mikä olisi tulos MySQL:n alla.
Mutta totta: järkeä pitää käyttää tietokantaa suunnitellessa. Jos arvioi että tietueita tulee olemaan jokunen miljoona, on INT UNSIGNED ihan riittävä. Jos taas veikkaa että tietueita tulee olemaan jokunen miljardi, pitää harkita BIGINT käyttöä.
Ok, mutta niitä ID-numeroita ei pysty millään automatiikalla tiivistelemään kuitenkaan? Sen automatiikanhan pitäisi ottaa huomioon myös suhteet toisiin tauluihin.
Kyllähän taulun kenttien tyyppiä voi vielä myöhemminkin muuttaa, joten ei täyttyminen mikään ongelma ole.
ALTER TABLE taulu MODIFY kentta INT(10) ...
Ilmeisesti tarkoitat tiivistämisellä tyyliin: ID-numeroita käytössä 1, 2, 4, 7, 8, 9, 10 ja tiivistämisen jälkeen ne olisi 1, 2, 3, 4, 5, 6, 7 ? Tämä on mahdollista muutamalla kyselyllä, mutta tuolloin tuhoutuu ID-numeroiden kertakäyttöisyys, joka kuppikunnasta riippuen on joko loppu jolloin maailmat räjähtää (tähän kuulun itse) tai ainakin ei suositeltavaa. Toinen vaihtoehto on toki (MySQL) ALTER TABLEn avulla muuttaa AUTO_INCREMENT pienemmäksi, jolloin välissä olevia tyhjiä numeroita käytetään aina niiden ollessa vapaita, mutta jälleen kerran ID:llä 3 ollut tärkeä asia A onkin hetken päästä jotain ihan höpöhöpö B:tä.
Aihe on jo aika vanha, joten et voi enää vastata siihen.