allgemeine sinnfrage zu db-id´s und auto-increment

[RaistlinMajere]

ich hab gerade mit einem kollegen über dieses thema diskutiert und würde gerne dazu meinungen einholen.

daß bei der erstellung einer db-table zur verhinderung, daß ein eintrag 2x vorkommt, id´s verwendet werden, ist nur sinnvoll. nun gibt es praktischerweise die funktion auto-increment, die bekanntlich dafür sorgt, daß jeder neue eintrag automatisch die inkrementierte id seines vorgängers erhält. soweit, so gut.

nur... ich habe diese funktion bewußt nie verwendet, und zwar aus folgendem grund (das war der auslöser für die diskussion mit meinem kollegen):

wenn ich z.b. einen datentyp habe, der 255 zeichen fasst (z.b. TINYINT) und diesen als id verwende, so werden da von 0 aufsteigend bis 254 id´s befüllt. gut, angenommen, ich habe nun eine db mit 255 solcher einträge, die alle ihre id´s über auto-increment zugewiesen bekommen haben. nun lösche ich bis auf den letzten, den mit der id 254, alle einträge davor aus der db, daher befindet sich nur mehr ein einziger eintrag darin. und nun das große dilemma... ich möchte einen neuen eintrag hinzufügen -> BANG, geht nicht, denn die grenzen des datentyps sind erreicht.

warum also sollte ich auto-increment für eine id-vergabe verwenden? ich bin bisher immer so gefahren, daß ich darauf verzichtet habe und die id-vergabe sowie das -management über die jeweilige programmiersprache gelöst habe. so habe ich zwar auch die id´s inkrementiert vergeben, nur wenn z.b. einträge irgendwo gelöscht wurden, so rückten die mit den größeren id´s automatisch nach. die id´s erfüllten noch immer ihren zweck der eindeutigen identifikation der einträge (keine doppelten), aber die id´s beginnen immer bei 0, wodurch ich nicht an die grenzen meines datentyps stoße, so wie oben beschrieben (es sei denn ich habe wirklich zuviele einträge, aber dann hab ich einfach einen zu kleinen datentyp gewählt).
die id´s sind dann natürlich nicht fix mit den einträgen verbunden (und eignen sich damit also nicht für eine identifizierung dieser, aber dafür kann ich ja andere parameter finden, z.b. eine artikelnr.), sondern dynamisch, aber das ist ja nicht weiter schlimm.

doch jetzt zu meiner frage, bzw. meinem verständnisproblem. meine lösung wurde von meinem kollegen als richtig und sinnvoll beschrieben... doch idealistisch. er meinte, das sei doch unnötiger aufwand, diese ganze id-schachtelei, man verwendet einfach einen ausreichend großen datentyp, wo man weiß, daß man niemals an seine grenzen stoßen wird und das wars.
ok, funktioniert bis zu einem gewissen grad sicher auch... nur ist das irgendwie ein riesenpfusch. ganz abgesehen davon, daß ich keine systeme "für die ewigkeit" baue, kann ich es mir kaum vorstellen, daß ein ernstzunehmender softwarehersteller so ein system anbieten würde oder daß es irgendjemand kaufen würde. ein system, wo das passieren kann, was ich darüber beschrieben habe, wo ich also an die grenzen meiner datentypen stoßen kann. ok... wenn ich diese groß genug wähle, wird das eine weile dauern... aber irgendwann ist es soweit! das kann doch bitte nicht professionelle arbeit sein, wer würde ein solches system kaufen, das so einen bug enthält?

und ein weiterer punkt ist mir auch noch unklar. abgesehen davon, daß die lösung meines kollegen in meinen augen ein pfusch ist, der irgendwann in die hose gehen muß, würde das bedeuten, daß ich riesige datentypen verwenden muß (so müßte ich z.b. in einem krassen fall für die abspeicherung von einer handvoll einträgen in einer db für deren id´s einen datentyp vom typ BIGINT schaffen, nur weil diese paar einträge aufgrund statischer id´s halt astronomische id´s haben), was auf der hardwareseite ziemlich aufwendig ist und bei einer großen db unmengen an speicherplatz benötigt (abgesehen davon, daß suchalgorithmen sich unnötig dabei abplagen, wenn sie sinnloserweise riesige id-bereiche durchkämmen, in denen sich tatsächlich wie gesagt nur eine handvoll einträge befinden).

doch angeblich ist diese lösung meines kollegen, also der "pfusch" in meinen augen, eine gängige, die angewandt wird. ich frage mich... wo liegt da der sinn?
wäre es nicht wirtschaftlicher, 1x besseren code zu schreiben, anstatt hardwareanforderungen durch laufend steigende, aber aufgrund von schlechtem code benötigte speicherkapazitäten immer weiter zu steigern (was wie gesagt auch suchalgorithmen die arbeit erschwert, weshalb wieder schnellere systeme angeschafft werden müssen) und somit wohl weit mehr geld unwirtschaftlich zu investieren?

doch angeblich passierts... mein kollege gab mir darin recht, daß meine lösung die sinnvollere sei (wenn auch angeblich idealistisch), doch trotzdem wird die seinige praktiziert.

warum, frage ich mich, wo liegt der sinn?

ich hoffe, daß der eine oder andere aus der it-branche sich die arbeit gemacht hat, dies hier zu lesen und mir vllt. diese fragen beantworten kann.