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.

[kikakater]

Zu autoincrement: Ja, ein großes Zahlentypfeld ist vonnöten.

Die Autoincrement Funktionalität ist erstens wegen der Eindeutigkeit der Einträge im Datenbanktabellenindex gegeben, aus diesem Grund also sinnvoll. Pro Tabelle kann man einen oder mehrere Indices mit einem oder mehreren Tabellenfeldern (also columns) anlegen. So ist die Sortierung und die Eindeutigkeit eingefügter Datensätze in Bezug auf ihre Indexfelder gewährleistet. Zweitens: Wenn man nun während des Tages im Zug einer Transaktion genau einen spezifischen Datensatz benötigt braucht man eben dieses Autoincrement Feld um an die Information heranzukommen und zwar über die regulären Felder und über das Autoincrementfeld implizit von der Logik her und explizit von der tatsächlichen Vorgangsweise her (dies resultiert in einem SELECT ... WHERE ... AND autoinc_column = xyz_zahl). Nicht jedoch verwenden kann man so ein Autoincrementfeld um eine ständige Zuordnung von einem Datensatz zu einem anderen zu machen, da es im Verlauf einer Reorganisation der Daten in einer Datenbank zur Veränderung der Nummerierung in einem Autoincrementfeld kommt.

Die Methode ein Autoincrement Feld zu verwenden kann man getrost beiseite lassen, wenn man das Datum und die Uhrzeit in Millisekunden aufgelöst verwendet um die Eindeutigkeit der Datensätze zu gewährleisten. Sollten mehr als 1000 Datensätze pro Sekunde in die Tabelle eingefügt werden können und müssen, ist eine Erweiterung auf eine Zehntausendstelsekunde vorstellbar.

Das Problem mit den Nummernkreisen für Artikelnummern, Datentypkonvertierungen oder eben Autoincrementfeldern ist nur durch das Verwenden eines Metadatentyps zu vermeiden. Ein Metadatentyp ist ein Datentyp, der ausreichend und hinreichend Platz bietet, die größte Zahlengröße aufzunehmen, die für einen Zweck benötigt wird sowie für Anwendungen jenseits einer Schnittstellengrenze.

Zusammenfassung:

• Autoincrementfeld: Grundsätzliche Eindeutigkeit aber nur sessionweite Gültigkeit der Zuordnung von Datensätzen zu ihren Autoincrementfeldwerten
  
• Eindeutigkeit erreicht man auch durch die Verwendung von Datum und Uhrzeit als Timestamp für Datenbankeinfügungen (Insertdate)
  
• Verwendung eines Metadatentyps für die problemlose Erfassung von Vereinigungsmengen von Daten, Beispiel: Farbspektrum 65536 Farbwerte, 16 Mio. Farbwerte - oder 16bit Auflösung Audio CD zu 24bit bei Audio DVD.

mfg Kikakater

[Tarjan]

Wenn ich die Zuordnung Primärschlüssel - Datensatz verliere führe ich den Primärschlüssel ja ad absurdum. Ich brauche ja dann einen 2. Schlüssel mit dem ich einen Datensatz wieder eindeutig referenzieren kann und kann den gleich zum Primärschlüssel machen. Entweder man verwendet sowieso dementsprechenden Primärschlüssel oder man nimmt eben die Incrementfunktion weil es einfacher ist. Und was hindert mich daran einen 64 Bit breiten Schlüssel zu verwenden. Dann hätte der, der es braucht 2^64 Möglichkeiten für Datensätze. Das sollte ausreichen.

[kikakater]

Die Autoincrement Funktion dient der temporären Zuordnung, keinesfalls der Identifizierung außerhalb einer Session. Wenn ein export / import von Datensätzen erfolgt ist, stehen im Autoincrement Feld der Datensätze Nachname = Schuhmacher sowie Nachname = Schuhmacher nicht mehr 11 und 17 sondern 3 und 4.

Ein unique Index, der der primäre oder ein alternativer (also weiterer) - Index - zu einer Tabelle ist, muß durch eine eindeutige Artikel-, Lieferanten- oder Kundennummer etc. realisiert werden. Im Fall von Schuhmacher Ralf 1 sowie S.Ralf 2 müsste dann ein Timestampfeld als ID herhalten um zum Beispiel nach der Wohnadresse, die in einer Tabelle ADRESSE abgelegt ist, eindeutig suchen zu können. In dieser Tabelle bzw. deren Index gibt es neben bzw. anstatt dem Nachnamen ein Feld Timestamp_Individuum, das als Zuordnung zu einer Person dient und deren Wert sich aus dem Einfügezeitpunkt in die Tabelle INDIVIDUUM ergibt.

[Tarjan]

Wennst den Wert den du durch die Autoincrementfunktion in ein Datenfeld speicherst so ist dieser Wert fix. Aisserdem hat sowieso nicht jede Datenbank ein Autoincerement.

Und ob man jetzt einen Timestamp, eine Zahl eine Buchstabenkombination als Primärschlüssen verwende ist egal, solange er unique ist.

[kikakater]

Das ist nicht alles dasselbe: Ein Autoincrementfeld einer Tabelle 1 als Referenz für eine Tabelle 2 heranzuziehen, muß schiefgehen. Da die Werte des Autoincrementfeldes dynamisch vergeben werden und im Fall des Neuanlegens gerade exportierter Datensätze mittels import die ursprünglichen Werte des Autoincrementfeldes der Tabelle 1 verlorengehen. In Tabelle 2 stehen aber noch immer diese alten Referenzwerte im dortigen Feld, das eigentlich die selben Werte wie in der Tabelle 1 verzeichnet haben soll.

So etwas wird über eine ID und nicht über ein Autoincrementfeld gelöst. Ob das ID Feld alphanumerisch oder ziffernmäßignumerisch bzw. binär numerisch ausgeprägt ist, hängt von der Leistungsfähigkeit der Applikation ab und nicht von unterschiedlichen Notwendigkeiten datenbanktechnischer Natur.