Ankündigung

Einklappen
Keine Ankündigung bisher.

Nächste "freie" ID finden

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Nächste "freie" ID finden

    Hallo zusammen,
    das ist mein erster Beitrag, also nicht böse sein, wenns das falsche Board ist

    Mit MySQL hab ich zwar schon ein paar Dinge gemacht, aber jetzt steh ich gerade vor einem Problem (eventuell auch ein Baum, der mir die Sicht auf den Wald nimmt). Ich habe eine Tabelle mit 3 Spalten und zwar wie folgt:
    Code:
    id    benutzer         eigenschaft
    1001  1                ABC
    1002  1                DEF
    1003  1                GHI
    1005  1                JKL
    id kann Werte zwischen X001 und X999 annehmen (X = benutzer)
    benutzer sind INT aus einer anderen Tabelle (dort ist die Nummer einem Namen etc. zugeordnet), eigenschaft ist ein TEXT-Feld
    Meine Abfrage ist momentan:
    Code:
    $req = "SELECT id FROM items WHERE benutzer = $benutzerID ORDER BY id DESC LIMIT 1";
    Als Rückgabewert bekomme ich (wie erwartet) 1005. Da ich aber keine Lücken in meiner ID-Spalte haben möchte, würde ich gerne 1004 zurückbekommen. Bloß... was muss ich dann als Abfrage verwenden? Meine Idee wäre SELECT COUNT gewesen, aber ich vermute, dass das nicht besonders performant ist. Ich hätte zwar lieber eine elegantere Lösung von der Struktur, aber so ist es am nützlichsten.

    Vielen Dank für eure Antworten

    EDIT: Gerade festgestellt


  • #2
    Zitat von DBX12 Beitrag anzeigen
    Als Rückgabewert bekomme ich (wie erwartet) 1005. Da ich aber keine Lücken in meiner ID-Spalte haben möchte,....
    Warum?
    PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

    Kommentar


    • #3
      Eigentlich aus rein optischen Gründen

      Kommentar


      • #4
        Das ist eine saudumme Idee.

        Eine ID ist zu Lebzeiten eindeutig. Die wird nie und nimmer doppelt vergeben.
        GitHub.com - ChrisAndChris - RowMapper und QueryBuilder für MySQL-Datenbanken

        Kommentar


        • #5
          Für was genau ist die Tabelle denn gut? Ich würde einfach mal so sagen, dass es Quatsch ist, die UserID nochmals in der Datensatz-ID unterzubringen, ohne genaueres zu wissen.
          Zitat von nikosch
          Macht doch alle was Ihr wollt mit Eurem Billigscheiß. Von mir aus sollen alle Eure Server abrauchen.

          Kommentar


          • #6
            Problem gelöst, aber sinnvolle Lösung?

            Also ich hab das Problem über einen Umweg gelöst. Eine 4. Spalte mit BOOL-Wert, die speichert, ob der Datensatz gelöscht wurde. So wird der Index nur einmalig vergeben und die Lücken sind auch Geschichte.

            Kommentar


            • #7
              Völliger Blödsinn!
              Die Deutsche Rechtschreibung ist Freeware! Du darfst sie kostenlos nutzen, allerdings ist sie nicht Open Source, d.h. Du darfst sie nicht verändern oder in veränderter Form veröffentlichen.

              Kommentar


              • #8
                Zitat von DBX12 Beitrag anzeigen
                Eigentlich aus rein optischen Gründen
                Eine via SERIAL (oder wie auch immer erzeugte eindeutige ID) hat nur eines zu sein: eindeutig. Nicht optisch schön oder rückwärts fortlaufend oder in den Farben des Regenbogens.
                PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

                Kommentar


                • #9
                  Zitat von DBX12 Beitrag anzeigen
                  Also ich hab das Problem über einen Umweg gelöst. Eine 4. Spalte mit BOOL-Wert, die speichert, ob der Datensatz gelöscht wurde. So wird der Index nur einmalig vergeben und die Lücken sind auch Geschichte.
                  Du irrst.
                  PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

                  Kommentar


                  • #10
                    Nächste "freie" ID finden

                    Eine in InnoDB fehlgeschlagebe Transaktion, die den Auto-Increment mutiert erhöht auch den AI-Wert. Lücken entstehen. Dafür ist es eindeutig.
                    GitHub.com - ChrisAndChris - RowMapper und QueryBuilder für MySQL-Datenbanken

                    Kommentar


                    • #11
                      Verschwende keine Zeit mit solchen Dingen. Immer eine neue ID und gut ist.

                      Kommentar


                      • #12
                        Du sollst mit deinen Tabellen keinen Schönheitspreis gewinnen, sondern sie intelligent designen und verwalten.
                        Bei Datensätzen auf Optik zu Achten ist mir mal was ganz neues.
                        Nein, nein, so kann das nichts werden.
                        Die mysql_* Erweiterung ist veraltet!
                        Besser: mysqli_* oder (noch besser) PDO

                        Kommentar

                        Lädt...
                        X