SQL: Primary / Unique / Index : Ich verstehs noch nicht...

    Hallo,


    ich habe zwar bereits im Web gesucht, allerdings verstehe ich die Bedeutungen der verschiedenen Keys noch nicht, also PRIMARY, INDEX, UNIQUE und so weiter.


    Ich möchte ein Feld so definieren, dass es nicht zweimal eingetragen werden kann. Ich hab dieses testweise schon mit jedem dieser 3 Keys belegt. Doch mir war es dennoch möglich, einen Eintrag doppelt in diesem Feld in die Datenbank einzutragen.

    Mit gesetztem UNIQUE für diese Spalte ist das unmöglich.


    PRIMARY -> Primärschlüssel, über diesen ist jede Zeile eindeutig auffindbar, ähnlich UNIQUE. Sollte in jeder Tabelle gesetzt sein.


    INDEX -> Werte der Spalte werden indiziert => schnellere Suche und Operationen in dieser Tabelle, aber mehr Speicherverbrauch


    UNIQUE -> In dieser Spalte dürfen alle Werte nur einmal vorkommen.

    Heißt das nun, ich soll diese Spalte "Primary" zuweisen, damit die Einträge nicht doppelt eingetragen werden können? Ich bin allerdings der Meinung, das schon ohne Erfolg probiert zu haben...

    Als Primary nimmt man meistens ein Attribut (also eine Spalte), welches die Tabelle "beschreibt". Zum Beispiel wenn man eine Tabelle Studiengang mit den Attributen Abkürzung, Studiengangname erzeugt wäre dies die Abkürzung.
    Durch die Primary Option wird das Attribut automatisch einzigartig. Da der Studiengagname auch eindeutig ist, wird dieser zusätzlich auf UNIQUE gesetzt.


    Wenn du jetzt 2 (oder mehr) Attribute in gemeinsamer Kombination als einzigartig setzen willst, kannst du beide (oder mehrere) zusammen auf Unique setzen. D.h. das die Atributte nur in dieser Kombi nicht nochmal auftauchen dürfen.


    Fazit: Es ist ein Unterschied wenn du jedes Attribut einzelnd oder mehrere zusammen auf Unique setzt.

    Oh tatsächlich, es scheint zu gehen ;)


    "Duplicate entry ... for key 1".


    Sehr schön. Ich habe eben eine Teileliste mit Fahrzeugteilen, und als einzigartige Spalte habe ich eben die Spalte "Teilenummer" angelegt, auf der jetzt der Primary Key ist. Kann ich daher jetzt auf weitere Keys verzichten, oder ist für ordentliche Datenbankfunktionalität noch in bestimmter Key unerlässlich?

    Das kommt ganz drauf an wer in deiner Datenbank alles rumbasteln darf? :)


    Wenn z.B. deine Teilenummern nur einzigartig sind und die Teilenamen nicht, könnte es ein Problem geben: Mitarbeiter x glaubt, dass ein bestimmtes Teil nicht in der Datenbank enthalten ist, und erstellt eine neue Teilenummer mit denselben Teilenamen.
    D.h. du hast 2 Teilenummern die denselben Namen haben.
    Durch gezieltes setzen von Unique kannst du sowas verhindern.

    Oh, ja tatsächlich ist dieses Problem denkbar. Wie genau könnte ich das verhindern?


    Nochwas: Ich habe momentan kein "ID"-Feld (also so ein auto_increment). Sollte man sich sowas lieber anlegen, oder ist das nicht so wichtig? Immerhin könnte man aufgrund der hochzählenden IDs, dann auch nach neu-eingetragenen Teilen sortieren.

    ID's legt man generell nur an um Primary Key's zu haben, wenn nichts anderes zur Verfügung steht. Daher würde ich es bei Teilenummer belassen. Du könntest noch eine zusätzliche Spalte Date eintragen und mit Date today definieren. So kannst du nach Datum sortieren und alles sehen.


    Gib mal bitte durch welche Attribute du genau in dieser Tabelle nutzt... das hilft weiter denke ich.

    Hehe, habe gerade gesehen, dass ich überhaupt keine Attribute vergeben habe. Ich weiß bis heute nicht um deren Bedeutung...

    Dann hast du noch etwas nachholbedarf oder? Kann dir gern das Script meiens Profs schicken... find ich ziemlich gut. Zwar nicht viel Code drinne aber alles verständlich erklärt.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden