Tabelle immer mit Primärschlüssel? (hier: MySQL)

  • Allgemein

Es gibt 4 Antworten in diesem Thema. Der letzte Beitrag () ist von Marcus Gräfe.

    Tabelle immer mit Primärschlüssel? (hier: MySQL)

    Ich frage mich gerade, ob man möglichst immer einen Primärschlüssel bei Datenbanktabellen (hier: MySQL) definieren sollte oder ob man es in manchen Fällen auslassen kann. Beispiel:

    SQL-Abfrage

    1. CREATE TABLE uploads_statistics (
    2. `uploadID` INT NOT NULL ,
    3. `timestamp` INT NOT NULL ,
    4. `userID` INT NOT NULL
    5. );

    Die Tabelle speichert, wann welcher User welchen Download gemacht hat (der Download ist die "uploadID"). Keines dieser Felder lässt sich als Primärschlüssel definieren, weil alle mehrfach identische Werte bekommen können.

    Nun gibt es drei Möglichkeiten:

    - Neues Feld "ID" und das als Primärschlüssel setzen (das Feld wäre dann aber wirklich nur dafür da, damit es überhaupt einen PK gibt)
    - Primärschlüssel zusammensetzen aus allen drei Feldern
    - Keinen Primärschlüssel erstellen

    Wie ist da die optimale Lösung?
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum

    jepp - immer Primärschlüssel.

    Ohne Primärschlüssel kann ADO.Net oder Entity-Framework einen Datensatz garnicht geändert rückspeichern oder löschen, weil der PrimKey ist halt die Identität eines Datensatzes.
    Manchmal kann man auch aufs Anlegen einer Extra-Primkey-Spalte verzichten, nämlich, wenn mehrere Spalten-Werte gemeinsam die Identität eines Datensatzes ausmachen. Das kann man in der DB auch so als mehrspaltigen PrimKey anlegen.
    Typisches Beispiel können Mittler-Tabellen von m:n - Relationen sein - gugge zusammengesetzter Primkey

    Na gut, ob Upload-Statistics Primkeys brauchen ist auch Ansichtssache - da kann ich mir vorstellen, dass solche Datensätze eh niemals verändert werden sollen.
    Da würde man ja vlt. allenfalls ältere Statistiken iwann mal löschen wollen, mit einem Sql-Statement, was auf alte TimeStamps matcht.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Das sieht für mich nicht unbedingt nach einer Notwendigkeit für Primary-Key aus, aber ggf. könnte man auf den Timestamp und/oder UserID einen Index legen (nicht unique), falls die Tabelle mal nach einem der Felder sortiert oder abgefragt werden soll.

    Primary Keys sind bei 1:1 oder 1:n Beziehungen unabdingbar, aber bei n:m ist es wichtiger die Indexe richitg zu legen.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    svenk2 schrieb:

    Ich würde einfach den Primary Key auf upload_id setzen und dass ganze also auto_increment machen.

    Nein, das geht nicht, weil die verweist auf die Tabelle "Uploads".

    @ErfinderDesRades: Danke für deine Antwort. Dann verzichte ich hier wohl auf den PK, merke mir aber, dass ich dann eher einen zusammengesetzten machen würde. Wären es nur uploadID und userID, so hätte ich wahrscheinlich einen zusammengesetzten erstellt, aber mit dem Timestamp zusammen fand ich das "seltsam" (wobei der zwangsweise dazu müsste).

    @petaod: (dein Post kam während meines Postschreibens dazu) Danke auch dir. Dann habe ich nun auch noch eine Bestätigung und bin mir noch sicherer. Die Erstellung von Indizies werde ich in Erwägung ziehen.
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum

Facebook