Ankündigung

Einklappen
Keine Ankündigung bisher.

Nachteile bei zwei unique index (MySQL)?

Einklappen

Neue Werbung 2019

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

  • Nachteile bei zwei unique index (MySQL)?

    Hallo, ich habe einmal das ID Feld und das Username Feld, beide sind einzigartig (unique=true // UNIQUE INDEX)
    Bisher habe ich immer nur ein Feld in der Tabelle als unique index verwendet, gibt es bei 2 irgendwelche Nachteile?
    Habe online nur die Infos gefunden, dass es möglich ist, ohne sonstige Infos.

    Danke im Voraus für die Zeit zum Antworten!

  • #2
    Eine ID wird gewöhnlich als PRIMARY KEY angelegt und nicht nur als UNIQUE INDEX. Weitere Felder mit einem UNIQUE INDEX zu versehen macht Sinn, wenn die Inhalte einzigartig sind und diese Felder oft in der WHERE Bedingung vorhanden sind, da es erhebliche Vorteile in der Geschwindigkeit bringt. Wie so oft keine Vorteile ohne Nachteile. Die Nachteile liegen im erhöhten Speicherbedarf. Das gilt es abzuwägen in Abhängigkeit vom jeweiligen Anwendungsfall. Das Sind aber Grundlagen, die in (fast) jeden MySQL Tutorial zu finden sind.

    Kommentar


    • #3
      Super das beantwortet meine Frage exakt, ich danke Dir herzlich!

      PS: Forum wirft oft den Fehler beim Posten aus:
      "Fehler beim Speichern des Inhalts: SyntaxError: JSON Parse error: Unexpected identifier "RAW""

      Kommentar


      • #4
        Danke für die Info. Ich hatte den Fehler bisher nicht, hast Du irgendwelche Plugins oder Scriptblocker installiert?
        Auf welcher Systemumgebung hast Du das? Ich gebe das dann weiter an die Administration.

        Competence-Center -> Enjoy the Informatrix
        PHProcks!Einsteiger freundliche TutorialsPreComposed Packages

        Kommentar


        • #5
          Ich würde es noch etwas schärfer formulieren, wenn Du für Deine Anwendung in einer Spalte Uniquness brauchst und das Modell, die Abläufe das erfordern, dann musst(!) Du es nutzen. Wie wolltest Du es sonst kontrollieren?
          Das hat natürlich den Nachteil, den jspit genannt hat, aber so ist das eben. Jeder Index kostet Platz, es gibt nichts geschenkt.
          Die Nachteile, die ein fehlender Unique Index mit sich brächte, wo einer hingehörte, würde ich vielfach schlimmer bewerten.

          BTW: Eigentlich spricht man von einem Unique Constraint, einer Regel, die die Eindeutigkeit definiert.
          Diesen kannst Du ohne weiteres anlegen, sogar ohne den genannten Nachteil des Platzverbrauchs. Die Regel sagt tatsächlich nichts über einen zugehörigen Index.
          Die meisten DB spendieren den Unique Index aber automatisch dazu, um sich die Arbeit leichter zu machen. Das ist quasi Standard und auch nicht zu Unrecht. Im Zweifel ist es vielleicht gut zu wissen, dass beides, Index und (ursächlicher) Constraint unabhängig von einander manuell angelegt, benannt und gelöscht werden können.

          Kommentar


          • #6
            Zitat von Perry Staltic Beitrag anzeigen
            Im Zweifel ist es vielleicht gut zu wissen, dass beides, Index und (ursächlicher) Constraint unabhängig von einander manuell angelegt, benannt und gelöscht werden können.
            Whot?
            PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

            Kommentar


            • #7
              Ja, gut dass Du noch mal nachfragst.
              In MySQL geht es tatsächlich nicht. Das war schlampig von mir. Ich war davon ausgegangen, dass es nur eine der vielen blöden Automatiken ist, die man auch abschalten kann.
              Evtl. wolltest Du an der Stelle nur loswerden, dass es unter Postgres geht, oder Oracle. Aber wir wollen ja kein mysql bashing, gell?!

              Eigentlich ist mir das auch nicht wichtig. Es ging mir um die Begriffe und das Bewusstsein, dass erstmal (unique) Constraint ungleich Unique Index ist. Ein Constraint ist ein Constraint, ob not null. primary key, foreign key, range values, .. Index ist Physik und beschreibt die betroffenen Spalten und den Index-Typ/-Implementierung.
              Constraints definieren Regeln, die die DB einhalten soll. Indizierung ist technische Hilfestellung, die nichts mit der formalen Funktion von Regeln zu tun hat. Und ja, ich höre schon, ein Unique Constraint ohne den Index macht doch gar kein Sinn! Faktisch würde diese Regel ohne den Index zu einer sehr langsamen Prüfung der Einhaltung der Regel führen (Sofern viele Datensätze in der Tabelle sind).

              Die Tatsache, dass auch mySQL 2 Möglichkeiten der Definition, nämlich (benannten) Unique Constraint sowie benannten Unique Index anbietet, würde ich nicht nur auf "SQL Kompatibilität" schieben. Es ist vielleicht nur eine "fest verdrahtete Automatik", ich kann's aber nicht beweisen.

              Ok, was soll das also?
              Wie das Leben so spielt, Datenmodelle können sich ändern, Indizes können zerstört werden oder müssen reorganisiert werden, Perstistenzsysteme müssen sich bei Klassenänderung damit rumplagen, die Klassendefinition anzupassen (und kommen damit manchmal nicht zurecht, wg der Bennenung von Indizes und Constraints z.B.)

              In einem System, dass die Physik von der Logik konsequent trennt, kann ich also hergehen und meinen defekten Index einfach löschen*, der Constraint bleibt erhalten und gewährleistet, was vereinbart war. Tja, mglw bricht das System trotzdem zusammen, weil es ohne Index zu lahm ist. Gut, bevor ich den schrottigen Index lösche, lege ich schon den neuen an. (Dann reden wir nicht nur von 2 Unique Index in einer Tabelle, sondern auf dem gleichen Feld) Hier gibt mySQL / Maria lustigerweise eine Warnung aus > deprecated. Das ergibt für mich keinen Sinn, weil es im Problemfall hilfreich sein kann, aber egal, andere Systeme sehen das lockerer und ich würde auch sagen, richtiger.

              Ich kann es auch anders rumdrehen. Sagen wir, ich ändere das Modell so, dass das Feld nicht mehr unique ist. Ich lösche also den Unique Constraint, in mySQL bedeutet das, der Unique Index wird ebenfalls gelöscht. Wenn mir nicht klar ist, das Constraint und Index eigentlich(!) etwas unterschiedliches ist, werde ich mich von nun an wundern, warum die Abfragen so lahm sind. Der zum Unique Constraint gehörende unique Index ist nicht mehr da und boostet nicht mehr die Abfragen. Ich müsste also zum Ersatz einen "normalen" Index anlegen. Wenn mir die Unerschiede nicht geläufig sind, fällt es mir vielleicht schwer, das nachzuvollziehen.

              * Bei Systemen, die Index und Constraint nicht vermischen, kann beides einen expliziten Namen haben (oder einen vom System generierten). Selbst die Namen festzulegen, kann praktisch sein, wenn man Objekte gezielt löschen will.


              Kommentar

              Lädt...
              X