Announcement

Collapse
No announcement yet.

Was wenn das ID Feld voll ist?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Was wenn das ID Feld voll ist?

    Hi!

    Habe hier gerade folgenden Sachverhalt festgestellt.
    In einer Tabelle habe ich ein ID Feld der Größe int. In diese Tabelle werden sehr oft Datensätze geschrieben und auch wieder herausgelöscht. In wenigen Wochen ist die ID auf 8 Mio angeschwollen. Tatsächlich sind aber nur rund 500 Datensätze in der Tabelle. Die müssen halt laufend aktualisiert werden.

    Ich muss hier zugeben ich habe bei der Auswahl der Feldgröße nur daran gedacht, dass da nie mehr als 1000 Einträge drin stehen werden. Ich habe nicht bedacht, dass jeder Datensatz ja eine neue ID bekommt.

    Ich bin mir jetzt aber auch nicht sicher, ob das ein Problem ist. Ich meine mich zu erinnern, dass wenn die ID die Grenze von Int überschreitet wieder auf 1 springt und dann wieder hoch läuft bis an die Grenze.

    Kann das jemand bestätigen?

  • #2
    Kannst du das Feld nicht auf GUID ändern? Damit wären deine Probleme gelöst.
    Neustart bei "1" wird vermutlich nicht automatisch passieren.

    Comment


    • #3
      Hallo Weisswurst,

      INT geht bis 2^31-1 (2.147.483.647) = 2 GB; etwas Platz hast Du also noch; vorerst.

      Kann das jemand bestätigen?
      Nein, mitnichten und das lässt sich leicht austesten:

      [highlight=SQL]CREATE TABLE #DUMMY
      (myID int identity(2147483646, 1));
      GO
      INSERT INTO #DUMMY DEFAULT VALUES;
      INSERT INTO #DUMMY DEFAULT VALUES;
      INSERT INTO #DUMMY DEFAULT VALUES;

      SELECT * FROM #DUMMY
      GO
      DROP TABLE #Dummy;[/highlight]
      Beim dritten INSERT rumst es dann: Grenze erreicht, schicht im Schacht.

      Aber Du kannst dann ohne Datenverlust un Applikationanpassung auf BIGINT umändert =
      2^63-1 (9.223.372.036.854.775.807)
      Wenn es wirklich nur 500 DS sind, sollte das auch fix gehen
      Olaf Helper

      <Blog> <Xing>
      * cogito ergo sum * errare humanum est * quote erat demonstrandum *
      Wenn ich denke, ist das ein Fehler und das beweise ich täglich

      Comment


      • #4
        Ja, die Lösung BigInt ist mir auch schon eingefallen. Aber das ändert am lausigen Konzept auch nichts. Ich muss mich drum kümmern, dass die App Updates durchführen kann und nicht immer alle Werte neu rein schreibt...

        Vielen Dank euch!

        Comment


        • #5
          Hast du mal nachgerechnet?
          Bei INT (bis 2.147.483.647) und 500 Datensätzen müsste man jeden einzelnen Datensatz 117 mal pro Tag ändern, damit man nach 100 Jahren an die Grenze stösst. Also im Moment nicht wirklich erforderlich, den Typ zu ändern.
          Ob es Sinn macht, jedesmal ein Insert statt einem Update zu machen ist wieder etwas anderes

          bye,
          Helmut

          Comment


          • #6
            Ich hab das mal hochgerechnet und festgestellt, dass bei der momentanen Insertrate in frühestens 4 Jahren damit zu rechnen ist, dass es eng wird.

            Comment


            • #7
              Hi,

              wenn alle Stränge reissen, gibt es auch noch

              Code:
              DBCC CheckIdent (tablename, RESEED 0)
              Allerdings müßte die Tabelle dabei einmal leer sein.

              Gruß
              Tino
              Ich habs gleich!
              ... sagte der Programmierer.

              Comment

              Working...
              X