Garantovano je osim ako ne radis rucno update, sto nisam jos cuo da neko radi.
Ako imas ovako
1
2
3
4
5
6
i onda obrises 4, sledeci record koji dodajes je 7, znaci imas
1
2
3
5
6
7
E sad, ako si dovoljno lood pa napravis da umesto novog recorda dodas bas na mesto 4, sto je moguce, onda moze da se desi da je manji ID noviji od najveceg. Ali kao sto rekoh, to niko normalan ne radi, jer bi onda morao da cuvas informacije o obrisanim ili pre svakog unosa da pretrazis bazu, koji je obrisan.
To se nekada radilo sa binarnim stablima, kada se obrise record, one se obicno nije fizicki brisao nego se markirao flag da je obrisan, a u headeru tabele se cuvao offset tog recorda. Kada bi se dodavao sledeci, citala bi se informacija iz headera i file pointer pomerio na taj offset za upis. Na tom mestu je bio sacuvan offset prethodnog obrisanog recorda koji bi se onda upisao u header kao sledeci "slobodan". Znaci, svaki obrisani record je cuvao offset prethodno obrisanog. Ako nema, onda se belezi EOF kao znak da se sledeci record upisuje na kraj fajla. To je meni bila jednostavna ali interesanta filozofija. Nekada nisu postojali ogromni hard diskovi i moralo se voditi racuna o svakom bajtu prostora.
Zato je meni i danas cudno kada vidim da neko deklarise sva char polja u tabeli kao VARCHAR(255), a generalno je sve jedno. Mysql ionako ima svoju optimizaciju za manje od 10 a za ove vece, sve jedno je da li je varchar(35) ili varchar(255), razlika je u jednom bajtu. Jedino sto je malo sporije indeksiranje, ali generalno nema veze.
Ma secam se nekada da su se podaci pakovali u bitove, sada to samo zaludni rade
Eto, malo iskustva, kada sam ja proucavao i cak pravio neke ovakve stvari, mislim da jos uvek mogu da pronadjem kompletan BTree source koji sam pravio u C-u