1. Willkommen im Forum für alle Datenbanken! Registriere Dich kostenlos und diskutiere über DBs wie Mysql, MariaDB, Oracle, Sql-Server, Postgres, Access uvm
    Information ausblenden

Zusammengesetzer Primärschlüssel oder nicht

Dieses Thema im Forum "Datenmodellierung, Datenbank-Design" wurde erstellt von exzel, 7 Juli 2014.

  1. exzel

    exzel Datenbank-Guru

    Hallo zusammen,

    in einer Datenbank werden Verträge erfasst mit der Möglichkeit unterschiedliche Versionen davon anzulegen.

    Also gibt es einmal eine id (autoincrement) für den Vertrag selbst und dazu noch eine Versionskennung. In den restlichen Spalten stehen die Vertragsdaten.

    In diesem Kontext müsste die id und die Versionskennung ein zusammengesetzter Primärschlüssel sein, oder?

    Auf der anderen Seite wird die Versionskennung rein über PHP ermittelt und neu vergeben, wenn dies der Anwender will. Also kein increment etc. Auch die zwingende Abfrage wird alles über PHP vorgenommen. Inwiefern macht es dann Sinn die Versionskennung und die id als zusammengesetzten Primärschlüssel zu setzen?

    Gruß

    Alex
     
  2. akretschmer

    akretschmer Datenbank-Guru

    Jede Tabelle sollte einen PK haben. Was also hast Du für Alternativen?
     
  3. exzel

    exzel Datenbank-Guru

    Ich meinte genügt da nicht die id als alleiniger PK? Macht der zusammengesetzte überhaupt einen Sinn?
     
  4. akretschmer

    akretschmer Datenbank-Guru

    Aso, ich dachte, daß ein Vertrag immer eine eindeutige ID hat, also über alle Versionen. Wenn das ein Serial ist und Unique und NOT NULL dann reicht das natürlich.
     
  5. exzel

    exzel Datenbank-Guru

    Aha, also es handelt sich um den Datentyp INT aber das sollte ich noch ändern. Aber die ids werden jedesmal neu vergeben.

    Halten wir fest. Wäre es eine feste ID für den gleichen Vertrag unabhängig von den Versionen, dann müsste es ein zusammengesetzter PK sein. Wenn für jeden Vertrag aber eine neue ID vergeben wird, dann ist die Versionskennung ein Nicht-Schlüsselattribut und die id als alleiniger PK genügt.

    Danke!
     
  6. ukulele

    ukulele Datenbank-Guru

    Und wenn der Anwender eine neue Version erstellt aber keine neue Versionskennung vergibt? Wird dann der alte DB Eintrag überschrieben, hast du einen eindeutigen, zusammengesetzten PK. Wird der Eintrag dupliziert und du hast identische Vertrags ID und Version hast du ein Problem.
     
  7. exzel

    exzel Datenbank-Guru

    Diesen Fall gibt es nicht. Der Anwender muss zuerst auf den Knopf "Neue Version anlegen" klicken. Dann wird der Vertrag mit neuer automatisch generierter Versionskennung und neuer id dubliziert.
     
  8. exzel

    exzel Datenbank-Guru

    Da ist mir noch was aufgefallen. Wenn der Benutzer keine neue Versionskennung vergeben würde könnte doch noch immer der Datensatz über die id identifiziert werden. Dann wäre es doch kein zusammengesetzter PK, oder?
     
  9. ukulele

    ukulele Datenbank-Guru

    Wenn es nur eine Version (die ursprüngliche) gibt, ist deine ID eindeutig und ID = PK. Wenn zu einem Dokument mehrere Versionen vorliegen (und auch alle in der DB gespeichert wurden), ist nur ID+Versionsnummer eindeutig.

    Wenn der Benutzer keine Versionskennung vergibt brauchst du nichtmal die Spalte Versionskennung...
     
  10. exzel

    exzel Datenbank-Guru

    Also es gibt mehrere Versionen. Aber die id wird per autoincrement vergeben. Datenbanktechnisch lassen sich so die Datensätze auseinander halten, oder?
     
  11. ukulele

    ukulele Datenbank-Guru

    Bei Autoincrement denke ich auch. Dann sollte es aber noch einen FK geben der auf die original Version zeigt denn sonst würde dieser Zusammenhang verloren gehen.
     
  12. exzel

    exzel Datenbank-Guru

    Das Original und die Versionen werden alle in einer Tabelle gespeichert. Also id (PK), version, Daten der Verträge. Als FK dient der PK aus der Kundentabelle, mit denen die Verträge dem Kunden zugeordnet werden können.
     
  13. ukulele

    ukulele Datenbank-Guru

    Nun dann ist bei einer Version 2 mit ID 23 nicht erkennbar welche Version 1 zugrunde liegt.
     
  14. exzel

    exzel Datenbank-Guru

    Ok, das bedeutet also ein zusammengesetzter PK wäre hier notwendig, richtig? Es ist so, dass ich die Abfrage und Vergabe der Versionskennung rein über PHP gelöst habe. Bevor die Verträge überhaupt bearbeitet werden könnten, muss der Anwender zuerst eine Version auswählen. Sobald eine neue Version angelegt wird erfolgt eine Datenbankabfrage, mit der die letzte (höchste) Version ermittelt wird und diese Kennung +1 wird dann als neue Version hinterlegt und dann für die weitere Bearbeitung beibehalten. Also die Vergabe der id erfolgt per autoincrement aber die Vergabe der Version über PHP manuell. In der DB habe ich keinen zusammengesetzen Primäschlüssel hinterlegt und es funktioniert dennoch einwandfrei.

    Was wäre der Vorteil, wenn ich den Schlüssel aber nun in der DB als zusammengesetzt definieren würde?

    Gruß und Dank
     
  15. ukulele

    ukulele Datenbank-Guru

    Du verstehst nicht worauf ich hinaus will. Du brauchst keinen zusammengesetzten PK, das ist eher ein "Sparmodell" um mehr Spalten zu vermeiden und in der Theorie natürlich total toll. In der Praxis kann man einfach eine Spalte mehr machen und einen künstlichen PK erstellen und vermutlich wird weder die DB explodieren noch wird sich jemand beklagen.

    Fakt ist, du hast einen Vertrag, der einen Eintrag darstellt. Die neue Version dieses Vertrages hat einen weiteren Eintrag. Beide haben unterschiedliche IDs per Autoincrement. Wie ermittelst du jetzt (egal ob in PHP oder SQL), was die höchste Version deines Vertrages ist? Du brauchst dazu einen Foreign Key oder irgendeine weitere "Erkennungsmethode".

    ID (Autoincrement) | Version | Titel
    1 | 1 | Bausparvertrag
    2 | 2 | Bausparvertrag
    3 | 2 | Bausparvertrag
    4 | 1 | Bausparvertrag
    5 | 3 | Bausparvertrag
    6 | 1 | Bausparvertrag
    7 | 2 | Bausparvertrag

    Finde den Vorgänger von Vertrag 5 Version 3.
     
Die Seite wird geladen...

Diese Seite empfehlen

  1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden