Ankündigung

Einklappen
Keine Ankündigung bisher.

PHP Anwendung, geeignetes ID System

Einklappen

Neue Werbung 2019

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

  • PHP Anwendung, geeignetes ID System

    Hi zusammen,

    ich bin zwar neu hier im Forum, habe aber doch gleich mal eine Frage.
    Und zwar versuche ich mich gerade in Eigenarbeit an einer PHP Anwendung die mit MySQL als Datenbank arbeitet.
    Bei dieser Anwendung brauche ich z.B. um Einträge oder Bilder zu identifizieren, eine geeignete ID. Derzeit nutze ich die bigints von MySQL,
    da diese aber auch irgendwann einmal ein Ende erreicht haben und PHP außerdem ein Problem damit hat mit diesen umzugehen, bin ich derzeit auf der Suche nach einem alternativen ID System.

    Nun mal hier die Frage an die PHP Profis. Gibt es hier bereits irgendwelche fertigen Libraries? Oder wie wäre es möglich eine möglichst "unendliche" ID einzuführen mit der auch MySQL gut klarkommt?

    Danke schon mal im Vorraus


  • #2
    Mit bigint kann man verdammt viele IDs anlegen. Genug dass nur sehr wenige Anwendungsgebiete sich Sorgen darueber machen werden muessen dass die mal ausgehen koennten.

    Selbst ein "normaler" int reicht fuer alltaegliche Anwendungen in der Regel voellig aus.
    Und ich bin mir ziemlich sicher dass am Ende nicht die Anzahl der moeglichen IDs bei dir das bottleneck sein wird.

    Kommentar


    • #4
      Ja, entweder GUIDs verwenden oder einmal rechnen, dass mit einem UINT schon 4 Mrd. Zeilen möglich sind.
      GitHub.com - ChrisAndChris - RowMapper und QueryBuilder für MySQL-Datenbanken

      Kommentar


      • #5
        Was auch gerne mal vergessen wird: IDs müssen nicht zwingend eine fortlaufende Nummer sein. Bswp. kann man eine User-Tabelle theoretisch wunderbar über die E-Mail-Adresse oder den Usernamen indizieren. Der einzige Grund, dass alle Welt hier integer verwendet ist, weil sie einfacher zu handhaben sind.

        Auch mal drüber nachdenken, ob man überhaupt IDs braucht, die sind nur dann wirklich sinnvoll, wenn man die Datensätze auch in anderen Tabellen referenziert.

        Oder noch was: Zusammengesetzte Primärschlüssel.
        Lerne Grundlagen | Schreibe gute Beispiele | PDO > mysqli > mysql | Versuch nicht, das Rad neu zu erfinden | Warum $foo[bar] böse ist | SQL Injections | Hashes sind keine Verschlüsselungen! | Dein E-Mail Regex ist falsch

        Kommentar


        • #6
          Es gibt auch noch unsigned.

          Aber ich gehe davon aus, du wirst bei BIGINT NIEMALS das Ende erreichen und verschwendest Zeit in unnütze gedanken.

          Ich gehe davon aus, dass du bereits geguckt hast wie groß BIGINT ist.

          Kommentar


          • #7
            Ja, zusammengesetzte Primärschlüssel sind super. Die beherbergen nur Gefahrenpotential bei einem Join (der ist "mühsamer", da man die ON-Klausel ausschreiben muss und kein USING verwenden kann). Ansonsten tatsächlich eine gute Variante für 1:n:1-Relationen

            Als Primärschlüssel eine E-Mail-Adresse muss nicht unbedingt gut sein, da sich hier unter Umständen Performance-Probleme bei grossen Datenmengen heraus kristallisieren.
            GitHub.com - ChrisAndChris - RowMapper und QueryBuilder für MySQL-Datenbanken

            Kommentar


            • #8
              Zitat von ChristianK Beitrag anzeigen
              Ja, zusammengesetzte Primärschlüssel sind super. Die beherbergen nur Gefahrenpotential bei einem Join (der ist "mühsamer", da man die ON-Klausel ausschreiben muss und kein USING verwenden kann). Ansonsten tatsächlich eine gute Variante für 1:n:1-Relationen
              Du kannst auch mit USING mehrere Felder nehmen, aber USING ist Sackgang da die Felder nur in den zu joinenden Tabellen auftauchen dürfen.

              Zitat von ChristianK Beitrag anzeigen
              Als Primärschlüssel eine E-Mail-Adresse muss nicht unbedingt gut sein, da sich hier unter Umständen Performance-Probleme bei grossen Datenmengen heraus kristallisieren.
              Eine Mail-Adresse als PK fällt eigentlich schon dadurch raus, dass sie, in den meisten Fällen, änderbar sein muss. Es kommt natürlich auch auf den Kontext drauf an, in einen simplen Mailverteiler schon grenzwertig (z.B. zukünftige Erweiterung), in einem Forum auf keinen Fall. Von der Performance macht das nicht so das Problem, es kostet aber mehr Ressourcen. Graden bei einem User Account kann man davon ausgehen das der PK öfters als FK auftaucht. Der Unterschied zwischen 4 Byte und x Byte kann dann schon etwas ausmachen.


              Zum eigentlichen Thema. Ich denke der unterschied im Wertebereich zwischen einer GGID und ein Bigint ist rein theoridischer Natur in einer Datenbankanwendung. Ich kann mir nix vorstellen was auch nur ansatzweise mit Bigint an die grenzen stoßen würde, selbst bei der NSA nicht. Bei der GGID muss man auch vorischtig sein, als String gespeichert ist der Speicherbedarf natürlich massiv hoch, Binär gespeichert wird das Handling verkompliziert.

              Kommentar


              • #9
                Hmm... Mir war nicht bekannt, dass USING mehrere Felder unterstützt, da muss ich mich einmal informieren.

                Das Problem betreffend änderbar und E-Mail als Primärschlüssel sollte jedoch kein Problem sein, man kann eine Änderung auf einem Primärschlüssel ja auch an die Fremdschlüssel kaskadieren. Dass das bezüglich Performance nicht gut ist, bin ich mir bewusst.

                Zur Speichereffizienz von E-Mails als Primärschlüssel bin ich einig mit dir, ein Integer ist eindeutig besser.

                Für eine GUID als Primärschlüssel spricht, dass es viel einfach zu replizieren ist, falls man ein Master-Slave-System einsetzt. Die Wahrscheinlichkeit, dass (aus welchen Gründen auch immer) ein Primärschlüssel doppelt vergeben wird ist mit einer GUID bei ~0%.
                GitHub.com - ChrisAndChris - RowMapper und QueryBuilder für MySQL-Datenbanken

                Kommentar

                Lädt...
                X