Announcement

Collapse
No announcement yet.

Auto_Increment Probleme mit InnoDB

Collapse
X
Collapse
  • Page of 1
  • Filter
  • Time
  • Show
Clear All
new posts
Previous template Next
  • #1

    Auto_Increment Probleme mit InnoDB

    Hallo zusammen,

    ich habe enorme Probleme mit einem Auto_Increment-Feld zweier InnoDB-Tabellen.

    Die Datenbank besteht nur aus zwei Tabellen (InnoDB) und hat auch relativ wenig Einträge. Als Primärschlüssel jeder Tabelle wird ein Auto-Increment-Zähler eingesetzt. Irgendwie ist dieser Zähler bei der Eingabe durcheinander geraten und der Wert für den nächsten Eintrag besitzt einen wahnsinnig hohen Wert (in einer Tabelle z.B. 2149697089), obwohl nur 5 Einträge dort überhaupt vorhanden sind und diese auch nicht mit so hohen Werten.

    Über die Funktion "ALTER TABLE `t_menue` AUTO_INCREMENT =6" kann ich den Zähler wohl neu initialisieren, leider bleibt das nur bis zum nächsten Neustart des MySQL-Dienstes so. Dann sind die Werte wieder utopisch hoch.

    Wie kann ich die Datenbank davon überzeugen, dass doch bitte etwas kleinere Zahlen verwendet werden sollen. Ich habe schon alles mögliche probiert (Datenbank kopieren, ex-/importieren, Tabellen neu anlegen, ...)

    Viele Grüße
    sky
    Tags: None
  • #2
    Warum überlässt du das nicht der DB?
    Christian

    Comment

    • #3
      Hallo Christian,

      das wollte ich eigentlich, aber in der Datenbank herrscht irgendwie Chaos. Ist der Zähler in einer Tabelle bei 5 Einträgen bei knapp 2 Milliarden, ist er nach ein paar mehr Einträgen schon doppelt so hoch. Irgendwie ist die Zählung nicht nach dem Motto "x = x +1" sondern scheinbar willkürlich. Was macht es auch für einen Sinn, dass der Index einen so wahnsinnig hohen Wert bei nur fünf Tabelleneinträgen hat (mehr waren da auch noch nie drin)? Die Weiterverarbeitung (u.a. PHP) macht dann auch Probleme - scheinbar laufe ich aus dem Wertebereich heraus.

      Einzige mir bisher bekannte Lösung scheint die Umstellung auf MyISAM. Dann bleibt der Auto_Increment-Wert auch nach dem Neustart erhalten. Leider erkaufe ich mir das dann mit der fehlenden referentiellen Integrität.

      Grüße
      sky

      Comment

      • #4
        Tritt das Problem auch mit einer neu erzeugten Tabelle auf? Falls nicht, kannst Du dir mal überlegen die alte Tabelle zu löschen und neu anzulegen.

        Wie befüllst Du denn die Tabelle? Läßt Du die Spalte in deinem Insert leer oder übergibst Du einen eigenen Wert?

        Dim
        Zitat Tom Kyte:
        I have a simple philosophy when it comes to the Oracle Database: you can treat it as a black box and just stick data into it, or you can understand how it works and exploit it as a powerful computing environment.

        Comment

        • #5
          Die Weiterverarbeitung (u.a. PHP) macht dann auch Probleme - scheinbar laufe ich aus dem Wertebereich heraus.
          Wie kann das sein?

          Das Feld sollte nie irgendwo in der Geschäftslogik genutzt werden.
          Christian

          Comment

          • #6
            Das Feld sollte nie irgendwo in der Geschäftslogik genutzt werden.
            Die Logik dass Geschäftslogik keinen PK nutzen darf soll mir mal jemand erklären.

            Dim
            Zitat Tom Kyte:
            I have a simple philosophy when it comes to the Oracle Database: you can treat it as a black box and just stick data into it, or you can understand how it works and exploit it as a powerful computing environment.

            Comment

            • #7
              Originally posted by dimitri View Post
              Die Logik dass Geschäftslogik keinen PK nutzen darf soll mir mal jemand erklären.

              Dim
              Es geht prinzipiell darum, dass man den PK nicht verwenden sollte, weil es an ALLEN Stellen in der Geschäftslogik Änderungen geben kann. Änderungen an PKs sind aber alles andere als toll.
              Deswegen sollte der PK nur Datenbankintern benutzt werden. Wenn Du eine laufende Nummer z.B. für Aufträge brauchst kann man dafür ein extra Feld vorsehen.
              Bei kleinen überschaubaren Projekten kann man diese auch für die AuftragsId verwenden. Steht allerdings fest, dass es ein größeres Projekt wird, sollte man das vermeiden.

              Comment

              • #8
                Ups, ich hab den Fehler gefunden. Die Primärschlüssel mit auto_increment hatten als Datentyp "double", statt einen ganzzahligen Typ *schäm*. Das scheint wohl keinen Sinn zu machen - war ich gestern zu blind zu.

                Ich habe den Typ nun auf "bigint" geändert und alles läuft perfekt. Werden nun Datensätze gelöscht, wird der auto_increment-Zähler sogar wieder auf den letzten Wert + 1 gesetzt (nach dem Serverneustart).

                Trotzdem danke für eure Hilfe!

                Gruß
                sky

                Comment

                • #9
                  Es geht prinzipiell darum, dass man den PK nicht verwenden sollte, weil es an ALLEN Stellen in der Geschäftslogik Änderungen geben kann. Änderungen an PKs sind aber alles andere als toll.
                  Es geht nicht um Änderungen am PK sondern darum den PK zu verwenden sprich zu selektieren. Jedes Persistenzframework macht das, falls ich keines verwende muss ich den PK manuell selektieren und wenn ich über den FK auf den übergeordneten Datensatz zugreifen will brauche ich ihn auch.

                  Dim
                  Zitat Tom Kyte:
                  I have a simple philosophy when it comes to the Oracle Database: you can treat it as a black box and just stick data into it, or you can understand how it works and exploit it as a powerful computing environment.

                  Comment

                  • #10
                    Ich denke Christian meinte genau das. PK sollen nur verwendet werden um Daten miteinander zu verknüpfen. Somite wäre es egal ob dort ein "schöner" Wert steht oder ob der bei 2309457340502093 liegt.
                    Das interessiert weder das Persistenzframework noch beim manuell selektieren, aber sehr wohl in der Business Logic, wenn gefordert wird, dass man z.B. eine "schöne" Auftragsnummer hat.
                    Primärschlüssel haben grundsätzlich nichts in der Business Logic verloren. Meist nimmt man sie dort mit rein, weil dann die Zuordnung zum jeweiligen Datensatz wesentlich leichter fällt.

                    Originally posted by Wikipedia
                    Geschäftslogik (engl. Business Logic, auch Anwendungslogik) ist ein abstrakter Begriff in der Softwaretechnik, der eine Abgrenzung der durch die Aufgabenstellung selbst motivierten Logik eines Softwaresystems von der technischen Implementierung zum Ziel hat. Allerdings ist der Begriff unscharf, da eine klare Trennung oft nicht möglich ist.
                    Quelle

                    Ein PK in der Datenbank ist somit technische Umsetzung und hat nichts mit der Business Logic zu tun.
                    Zuletzt editiert von fanderlf; 15.02.2010, 14:27.

                    Comment

                    • #11
                      Jedes Persistenzframework macht das,
                      Sicher, dem ist ja auch egal, ob da 2 oder 20000 drin steht.

                      "Nicht verwenden" i.S.v. Sortierkriterium, Anzahl usw.
                      Christian

                      Comment

                      Previous template Next
                      Working...
                      X