Tim: Sql ID inc

tach,

habe eine tabelle, in die viele einträge rein kommen, die aber auch gelöscht werden.

wenn man nun für die ID vergabe immer die max ID um 1 erhöht ist man selbst bei großen datentypen schnell am ende.

ich suche nun einen algorithmus, mit dem man die max keinste freie ID findet.

beispiel:

ID  Name
1   Meier
2   Schulze
5   Otto
7   Schubert

nun sollte der algorithmus erst 0, dann 3, dann 4, dann 6, dann 8 usw. auswerfen.
gibt es dafür vielleicht sogar ein SQL-Statement?

kann ja nicht sein, das ich eine schleife bauen muss, bei der ich immer um 1 erhöhe und frage ob die ID frei ist.

vielen dank.
Tim.

  1. Hi,

    habe eine tabelle,

    in welchem DBMS?

    wenn man nun für die ID vergabe immer die max ID um 1 erhöht ist man selbst bei großen datentypen schnell am ende.

    Wenn Du den MySQL-Typus BIGINT oder etwas Entsprechendes nimmst und pro Sekunde eine Milliarde Datensätze anlegst, reicht das für knapp 600 Jahre. "Schnell" würde ich das in der heutigen Zeit nicht nennen - bis dahin hast Du sicher eine Migrationsstrategie entwickeln können, die das Problem auf die nächste Ebene hebt.

    gibt es dafür vielleicht sogar ein SQL-Statement?

    Das Vorhaben widerspricht dem Sinn einer ID. Es gibt keinen Grund anzunehmen, es sei leicht lösbar.

    Cheatah

    --
    X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
    X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
    X-Will-Answer-Email: No
    X-Please-Search-Archive-First: Absolutely Yes
    1. hast recht, der bereich von bigInt geht bei unsigned von 0 bis 18 446 744 073 709 551 615.

      bei ein milliarden einträge pro sekunde wären noch 18 446 744 073 übrig /60 /60 /24 /365 ergibt 585 Jahre...

      hätte ich doch mal vorher rechnen sollen, hätte nicht gadacht, das es so viele einträge sind...

  2. Hallo

    habe eine tabelle, in die viele einträge rein kommen, die aber auch gelöscht werden.

    Wie viele täglich?

    wenn man nun für die ID vergabe immer die max ID um 1 erhöht ist man selbst bei großen datentypen schnell am ende.

    Ja? Wirklich?

    Ein Beispiel: BIGINT (MySQL): The unsigned range is 0 to 18446744073709551615.

    Na ja, nehmen wir mal 50 Jahre Laufzeit, so

    18446744073709551615 : 50 ist ungefähr
    368000000000000000 pro Jahr, ergibt ungefähr
      1000000000000000 pro Tag, das sind mehr als
           10000000000 pro Sekunde

    Reicht Dir das wirklich nicht?

    Welches Datenbankmanagementsystem (DBMS) verwendest Du? Welches ist der größte Felddatentyp, den Dein DBMS bietet?

    kann ja nicht sein, das ich eine schleife bauen muss, bei der ich immer um 1 erhöhe und frage ob die ID frei ist.

    Es ist keine gute Idee, IDs wiederzuverwenden.

    Freundliche Grüße

    Vinzenz