Index oder Primary Key?

Dieses Thema im Forum "Datenbanksysteme für das Web" wurde erstellt von 2nd, 13.08.2006.

  1. 2nd

    2nd Thread Starter MacUser Mitglied

    Beiträge:
    8.902
    Zustimmungen:
    242
    MacUser seit:
    25.07.2004
    Moin,

    ich brauch mal Hilfe fürs Grundverständnis in MySQL Datenbanken:

    Ich habe ja die Möglichkeit, folgende Schlüssel zu definieren: Primary Key, Index und diese dann noch Unique oder nicht. Ist es eine dumme Frage zu fragen, wo der Sinn hinter beiden Schlüsseln steckt?

    Ich habe 2 Tabellen in meiner Datenbank, in der einen (Tabelle 1) habe ich einen Auto_Increment Index, auf den sich aus Tabelle 2 bezogen wird (dort wird nur der Bezug auf den Index in Tabelle 1 gespeichert).

    Macht das Sinn so? Oder brauche ich einen Primary Key? Oder einen Unique Index?

    Danke,

    2nd
     
  2. goddess

    goddess MacUser Mitglied

    Beiträge:
    229
    Zustimmungen:
    10
    MacUser seit:
    26.02.2006
    Ein Index in einer relationalen Datenbank ist abstrakt gesehen genauso wie der Index in einem Buch. D.h. du hast die Suchbegriffe in geordneter Reihenfolge, was das suchen erleichtert und die Geschwindigkeit, zu einem Ergebnis zu kommen, wesentlich erhöht. Wenn du eine Spalte in einer DB-Tabelle mit einem Index versiehst, baut die Datenbank im Hintergrund ein Indexverzeichnis auf, in welchem sie dann suchen kann (d.h. nach Index kann man schneller suchen). Suchst du ein nicht-indexiertes Feld, dann muss die Datenbank-Engine sequentiell suchen, d.h. jeden Datensatz durchgehen und vergleichen --> irre langsam.

    Unique bedeutet, dass du ein Feld einzigartig machen kannst. Das macht z.B. Sinn wenn du eine eindeutige Email-Adresse eintragen willst (wie in der meisten Forums-Software).

    Mit einem Primärschlüssel kann man einen Datensatz eindeutig (unique) kennzeichnen. Eindeutig bedeutet, dass es kein Feld in der Spalte geben kann, welches ident ist, es besteht also keine Verwechslungsgefahr. Gleichzeitig wird über eine Spalte, die ein Primärschlüssel ist, ein Index gelegt (siehe oben). Das tolle ist, dass du den Primärschlüssel aus mehreren Feldern zusammenbauen kannst. D.h. der eindeutige Schlüssel ist die Kombination aus den Feldern.

    Wenn ich dich richtig verstanden habe ist in Tabelle2 der Index aus Tabelle1 der Fremdschlüssel. Es hängt jetzt davon ab, ob das Feld Index aus Tabelle1 einen mehrfachen Bezug (1:n) zu Tabelle2 hat, sprich es kann mehrfach vorkommen. Wenn ja, dann bau dir zusätzlich zum Fremdschlüssel-index einen eindeutigen Bezeichner für Tabelle2. Über beide Felder legst du dann den Primary Key.

    Code:
    CREATE TABLE `test` (
    `tab1_index` INT NOT NULL ,
    `tab2_index` INT NOT NULL ,
    PRIMARY KEY ( `tab1_index` , `tab2_index` )
    );
    Wenn es jeweils nur einen Bezug zu Tabelle1 geben soll (1:1), also für jeden Datensatz in Tabelle1 nur e i n e Entsprechung in Tabelle2, dann genügt es, wenn du den Primarykey über den Fremdschlüssel legst.

    Ich hoffe, das war jetzt nicht zu verwirrend. Einfacher kann ichs leider nicht mehr erklären :o
     
  3. 2nd

    2nd Thread Starter MacUser Mitglied

    Beiträge:
    8.902
    Zustimmungen:
    242
    MacUser seit:
    25.07.2004
    Uff, habe ich mir doch gedacht, dass das Ganze nicht ganz trivial ist :( Danke für Deine ausführliche Antwort, leider verstehe ich die Zusammenhänge noch nicht so ganz.

    Gibt es da gute Literatur im Netz oder in Buchform? Ich muss mich unbedingt damit beschäftigen, das scheint Sinn zu machen.

    Also in der Tabelle 1 sind z. B. Bilder gespeichert und in Tabelle 2 die Kommentare dazu. Deswegen gehe ich davon aus, das es für die Datensätze in Tabelle1 m e h r e r e Entsprechungen in Tabelle 2 gibt oder?

    Was nun? Das hier?

    Nach meiner beschränkten Logik müsste es doch so funktionieren:

    Tabelle 1:

    content_id <- das ist der Index (AutoIncrement)___________BildURL ___________Fotograf

    12_________________________________________________http://www....._______Müller-Meier
    13
    ..



    Tabelle 2:

    comment_id <- das ist der Index (AutoIncrement)___________Kommentar___________Autor___________ID

    50 ______________________________________________________Blablabla___________Lehmann________12
    51
    52
    ..


    Damit bezieht sich der Kommentar von Lehmann doch auf das Bild von Müller-Meier mit dem Index 12 in Tabelle 1. Geht das nicht? Was ist der Nachteil, fernab von Primary Keys? Die Indicies in beiden Tabellen sind doch auch "unique", da bei jedem neuen Datensatz hochgezählt wird?!?

    2nd
     
    Zuletzt bearbeitet: 14.08.2006
  4. dpr

    dpr MacUser Mitglied

    Beiträge:
    519
    Zustimmungen:
    0
    MacUser seit:
    04.04.2006
    Jedes Datenbank-Lehrbuch sollte die notwendigen Grundlagen vermitteln können. Achte darauf, daß auch die Entwurfsphase abgedeckt ist, anderenfalls endet die Geschichte als "Datenbankentwurf aus der Praxis".

    Das ist noch immer eine 1:n-Beziehung, die aus Richtung der Kommentare betrachtet zwingend ist: Einem Kommentar wird genau ein Bild, einem Bild können (d.h. optional) mehrere Bilder zugeordnet werden. Ein Fremdschlüssel in den Kommentaren bezüglich der Bilder setzt das um.

    Apropos, um nocheinmal die Ausgangsfrage aufzugreifen:

    Primär- und Fremdschlüssel sind im Relationenmodell enthaltene Integritätsbedingungen und spielen damit auf der konzeptuellen Ebene. Eine Stufe tiefer befindet sich die interne Ebene, dort gibt es Dateiorganisationen und Zugriffspfade und damit die Möglichkeit, diese Strukturen zu beeinflussen. Du hast also Begriffe zweier unterschiedlicher Ebenen gebraucht: Ein (Primär-)Schlüssel identifiziert ein Tupel, ein Index ist in erster Linie ein Zugriffspfad, der auch "identifizierend" sein kann, aber nicht muß.
     
  5. 2nd

    2nd Thread Starter MacUser Mitglied

    Beiträge:
    8.902
    Zustimmungen:
    242
    MacUser seit:
    25.07.2004
    Auch an Dich Danke dpr :)

    Also kann ich mein Modell der Kommentare und Bilder mit Index und ohne Primary Key erstmal so umsetzen ohne Sorge haben zu müssen, dass ich in ein paar Monaten die komplette Datenbankstruktur in die Tonne kloppen muss?

    2nd
     
  6. dpr

    dpr MacUser Mitglied

    Beiträge:
    519
    Zustimmungen:
    0
    MacUser seit:
    04.04.2006
    Nimm Dir pro Relation einen Primärschlüssel und in den Kommentaren einen Fremdschlüssel bezüglich der Bilder. Den physischen Entwurf (Stichwort Index) kannst Du später immernoch verfeinern.
     
  7. 2nd

    2nd Thread Starter MacUser Mitglied

    Beiträge:
    8.902
    Zustimmungen:
    242
    MacUser seit:
    25.07.2004
    Sorry wenn ich noch mal doof nachfragen muss:

    Der Primärschlüssel soll in die Tabelle mit den Bildern, z. B. kann ich den über das Datum und den Fotografen legen?

    Und als Fremdschlüssel in der Kommentartabelle kann ich wie oben in meinem Modell einfach die ID mit Bezug auf den Index in Tabelle 1 speichern?

    2nd
     
  8. dpr

    dpr MacUser Mitglied

    Beiträge:
    519
    Zustimmungen:
    0
    MacUser seit:
    04.04.2006
    Kandidaten für den Primärschlüssel hast Du ja bereits: content_id in der einen, comment_id in der anderen Relation. Jetzt brauchst Du sie eigentlich nur noch als solche auszeichnen:

    Code:
    create table Bilder (
      content_id ...,
      ...,
      primary key (content_id)
    );
    
    create table Kommentar (
      comment_id ...,
      ...,
      id ...,
      primary key (comment_id),
      foreign key (id) references Bilder(content_id)
    );
    
    Damit das mit mysql funktioniert, wirst Du (sofern sich das nicht zwischenzeitlich geändert haben sollte) als Tabellentypen InnoDB verwenden müssen.

    EDIT: ich habe mal der Vollständigkeit wegen das fehlende Klammernpaar der FK-Klausel ergänzt.
     
    Zuletzt bearbeitet: 14.08.2006
  9. 2nd

    2nd Thread Starter MacUser Mitglied

    Beiträge:
    8.902
    Zustimmungen:
    242
    MacUser seit:
    25.07.2004
    Ok, das mit den Primarys habe ich jetzt hinbekommen und ich denke auch verstanden, zumindest das mit einfachen Primary Keys.

    Jetzt komme ich aber mit der Foreign Keys noch nicht ganz klar, genauer gesagt mit der SQL Syntax. Ich habe meine beiden Tabellen in InnoDB-Tabellen geändert, jedoch sagt der SQL Parser einen Fehler an bei folgender Syntax:

    HTML:
    alter table comments (
      foreign key ID references content(content_id)
    )
    Also meine Kommentartabelle heisst "comments" und die Spalte heisst "ID", die Bildertabelle heisse "content" und der Primary Key dort "content_id".

    Was ist in meinem SQL Statement falsch? Es gibt bei phpMyAdmin leider keinen Button für einen Foreign Key :noplan:


    Noch eine Frage: Was ist von dem kurzen Text hinter folgender URL zu halten?

    http://www.little-idiot.de/mysql/mysql-45.html

    Bis jetzt konnte ich immer meine Datenbanken dumpen (Online & Offline) und hatte nie ein Problem mit dem Wiedereinspielen. Geht das durch die Foreign Keys verloren?

    2nd
     
  10. dpr

    dpr MacUser Mitglied

    Beiträge:
    519
    Zustimmungen:
    0
    MacUser seit:
    04.04.2006
    Innerhalb der create-table-Anweisung klappt es. BTW: Ich habe oben wohl die Klammern um das Attribut vergessen, also foreign key (id) references...

    Exakt nichts. Ich habe noch nie solch eine sinnfreie Begründung gelesen, auf integritätssichernde Maßnahmen zu verzichten.
     
Die Seite wird geladen...

Diese Seite empfehlen