Warum ist ein einzelner Primärschlüssel besser als zusammengesetzte Schlüssel?

Warum ist die Ablehnung von zusammengesetzten Schlüsseln zu Gunsten von alle Tabellen mit einem einzigen Primärschlüssel mit der Bezeichnung id? Ursache in der Regel alle ORM Folgen.

BEARBEITEN

Ich gerade angefangen zu lernen, ruby on rails und in das Buch der agilen Entwicklung von pragmatischen gibt es eine Zeile:---
Schienen wirklich nicht allzu gut funktionieren, es sei denn, jeder Tisch hat einen numerischen Primärschlüssel. Es ist weniger wählerisch über den Namen der Spalte.
Gleiche Art von Linie, die ich Lesen, als ich lernte die Lehre.

EDIT2
Bitte überprüfen Sie diesen link auch. Ich bin immer mehr und mehr verwirrt über diese Sache:---
Composite primary keys versus eindeutige Objekt-ID-Feld

Aus dem obigen link:--

*der primary key sollte konstant sein und bedeutungslos; nicht-Ersatzschlüssel in der Regel nicht, eine oder beide Voraussetzungen, schließlich

Wenn der Schlüssel ist nicht konstant, Sie haben eine Zukunft-update Problem, das kann kompliziert werden
wenn der Schlüssel ist nicht sinnlos, dann ist es wahrscheinlicher, sich zu ändern, d.h. nicht konstant sein; siehe oben

Nehmen Sie ein einfaches, typisches Beispiel: eine Tabelle von Inventar-Gegenstände. Es mag verlockend sein, um die Artikelnummer (SKU-Nummer, barcode, Artikel-code, oder was auch immer) der Primärschlüssel, aber dann ein Jahr später, alle Artikel-Nummern ändern und Sie sind Links mit einer sehr chaotisch update-die-ganze-Datenbank problem...

EDIT: es gibt ein zusätzliches Problem, das ist mehr praktisch als philosophisch. In vielen Fällen sind Sie gehen, um herauszufinden, eine bestimmte Zeile irgendwie, später dann aktualisieren Sie es oder finden Sie es wieder (oder beides). Mit zusammengesetzten Schlüsseln gibt es mehr Daten zu verfolgen und mehr Einschränkungen in der WHERE-Klausel für die neu zu finden oder zu aktualisieren (oder löschen). Es ist auch möglich, dass einer der wichtigsten Segmente in der Zwischenzeit geändert haben!. Mit einem Ersatzschlüssel, es gibt immer nur einen Wert zu behalten (Surrogat-ID) und per definition kann es nicht ändern, das vereinfacht die situation erheblich.*

InformationsquelleAutor der Frage Mohit Jain | 2010-04-19

  1. 22

    Ich glaube nicht, dass es eine Pauschale Erklärung, dass Sie sollten immer nur einen einzigen Primärschlüssel namens id.

    Meisten Leute benutzen ein Surrogat Primärschlüssel haben, wie eine automatische generieren von int, denn es isoliert den Primärschlüssel jemals brauchen, um geändert werden, wie wenn Sie die PK den Benutzernamen, den Sie später änderten Sie Ihren gesetzlichen Namen. Sie hätte ein update der PK und alle FK-Spalten, um den neuen Namen widerspiegeln. wenn Sie verwendet hatten, ein Surrogat Primärschlüssel, den Sie gerade aktualisieren Sie den Namen des Benutzers an einer Stelle (da die Tabellen-join für die int nicht den Namen).

    In der Größe eines primary-key ist wichtig, da die PK wird dupliziert, in jeder index, den Sie erstellen auf dem Tisch. Wenn die PK ist groß (wie ein string) Sie haben weniger Tasten pro Seite auf dem index und wird der index mehr cache-Speicher zu speichern. Ints sind klein.

    Mit einem auto-Inkrement int PK eignet sich für ein clustered-index gut, wie die Zeilen gespeichert sind, in dieser Reihenfolge und es gibt keine Notwendigkeit, zurück zu gehen und bump-Reihen aus dem Weg, um eine neue Zeile einzufügen, werden Sie immer hinzufügen, um die Tabelle zu Ende.

    InformationsquelleAutor der Antwort KM.

  2. 12

    Die einzige wirkliche Einschränkung, die ich habe, laufen Sie in die Verwendung von zusammengesetzten Schlüsseln betrifft die Verwendung eines IN Ausdruck mit einer Unterabfrage. Dies ist ein problem, weil eine Unterabfrage in einem Ausdruck muss wieder eine einzelne Spalte (zumindest in T-SQL).

    SELECT
    emp.Name,
    emp.UserDomain,
    emp.UserID
FROM
    employee emp
WHERE
    ???? IN (SELECT e.UserDomain, e.UserID FROM ... /* some complex 
                                                       non-correlated subquery 
                                                       or CTE */
            )

    Gibt es immer wieder Workarounds, natürlich, aber manchmal kann es ein ärgernis sein.

    Ist dies kaum ein Grund, um zu vermeiden, einen zusammengesetzten Schlüssel in Orten, wo es Sinn macht.

    InformationsquelleAutor der Antwort Jeffrey L Whitledge

  3. 7

    Können Sie beides verwenden. In einigen Fällen bei der Herstellung einer Assoziation zwischen einer Entität können Sie die beiden entitätsschlüssel als einen zusammengesetzten Schlüssel.

    Als Faustregel nutze ich generierte ids für Entitäten und zusammengesetzte Schlüssel für Beziehungen.

    InformationsquelleAutor der Antwort James Westgate

  4. 4

    Gut, es ist im Grunde über das halten Schließt sich einfach - welches ist einfacher zu verstehen:

    SELECT
   p.ID, p.Name, p.City,
   c.ID, c.Country, c.ISOCode
FROM
   dbo.Parent p
INNER JOIN
   dbo.Child c on c.ParentID = p.ID

    oder

    SELECT
   p.ID, p.Name, p.City,
   c.ID, c.Country, c.ISOCode
FROM
   dbo.Parent p
INNER JOIN
   dbo.Child c ON c.ParentName = p.Name
     AND c.ParentCity = p.City
     AND c.ParentCountry = p.Country

    Wenn Sie composite primary keys, wer den Beitritt zu Ihrem Tisch, aus einer untergeordneten Tabelle muss "zusammen zu ziehen" alle diese Spalten, und alle diese Spalten sind auch vorhanden sein, in der Kind-Tabelle und der JOIN-Anweisungen sind ziemlich chaotisch. Viel besser, einen einzigen (auch Ersatz) Schlüssel für die VERKNÜPFUNG!

    InformationsquelleAutor der Antwort marc_s

  5. 2

    Arbeitete ich an einer app mit einem 11 Spalte primary key. Es war immer ein großer Spaß Abtippen der Liste über und über und über jedes mal, wenn ich wollte, um zu garantieren, war ich die Aktualisierung einer Zeile. Es war ein Treiber Fehler, MS-Access konnte nicht zu bewältigen mit mehr als 10 Spalten in einer PK, etc.

    Große zusammengesetzte Schlüssel sind design-riecht bedeutet, dass der Tisch hält heterogenen Entitäten oder der designer war nicht wirklich sicher, was es ist, einzigartig zu jeder Person. (Wie vorausgesetzt, die Haarfarbe, die Augenfarbe und das Körpergewicht sollte ausreichend sein, um eindeutige Identifizierung eines Mitarbeiter-- das ist nicht ein guter Schlüssel, da bräuchte man mehr und mehr und mehr Spalten zu machen, arbeiten und schließlich, die Felder, sind flüchtig und ändern eine Menge, wie Gewicht, oder für einige Menschen, die Haarfarbe oder das fehlen von dort.)

    InformationsquelleAutor der Antwort MatthewMartin

  6. 1

    1. Für ein ORM einer einzigen identifizieren
      Spalte mit einem einheitlichen Namen wie
      table_id ist einfacher, als einen composite
      Schlüssel. Aber jedes gute ORM-Unterstützung
      zusammengesetzte Schlüssel.

    2. Einen einfachen PK kann leicht sein
      'autoincremented' von der Datenbank.
      Diese halten uns nicht für eine composite
      Schlüssel.

    3. Einem einfachen PK ist auch einfacher zu bedienen in der
      Abfragen. Wenn Sie brauchen, um Mitglied zu werden,
      nur verwenden Sie eine Spalte der beiden
      Beziehungen.

    Dies ist nicht zu sagen, dass einfache PKs sind besser als composite diejenigen, though.

    InformationsquelleAutor der Antwort Exception e

  7. 0

    Objekte in der OO-Programmierung eine Identität unabhängig von Ihrem Inhalt. Zeilen (Tupel) in relationalen Datenbanken werden identifiziert durch Ihre Inhalte nur. Also, wenn Sie wirklich tun, ORM, D. H. mapping der Objekte aus einer objektorientierten Programmiersprache in einer relationalen Datenbank, eine extra-ID muss zur Verfügung gestellt werden, deutlich von den Feldern und/oder Eigenschaften, die das Objekt in das Programm - es sei denn, eine oder mehrere von denen sind irgendwie bekannt, zur eindeutigen Kennzeichnung von Objekten.

    InformationsquelleAutor der Antwort reinierpost

  8. 0

    Deine Frage ist stark in Bezug auf die Surrogat (oder künstlichen) Schlüssel vs. natural keys alternative. Ich denke, es ist nicht so, dass composite Tasten sind weniger verwendet, aber das natürlichen Tasten (werden Sie composite-oder einfach) sind weniger bevorzugt als künstliche Tasten.

    Traditionellen, relationalen Datenbank-Theorie Beschäftigten sich vor allem mit "natürlichen" Schlüssel, (um die, die Bedeutung haben, von der business-domain-Sicht) und in diesem Szenario composite-Tasten sind Häufig zu finden... natürlich.

    Aber in den späteren Jahren, Datenbank-design hat bevorzugt (jedoch nicht ausschließlich) den "künstlichen" (Ersatz) Schlüssel-Muster, typischerweise eine fortlaufende Nummer, die keinen geschäftlichen Sinn, dient lediglich der eindeutigen Identifizierung der Datensatz in der Tabelle (und vielleicht das Objekt in der oberen Schicht).

    InformationsquelleAutor der Antwort leonbloy

  9. 0

    Obwohl ich Stimme mit den meisten von den Gründen, die anderen Befragten, ist mein Hauptgrund für den Vorzug einer einzelnen Spalte integer-Schlüssel ist, dass es macht das schreiben einer Benutzer-Schnittstelle, die viel, viel einfacher.

    Wenn Sie mit irgendeiner Art von Liste-Steuerelement zum darstellen Ihrer Daten (eine Liste, Liste Ansicht, combo-box, etc.) können Sie individuell betreffen jeden Eintrag wieder auf seine Datenbank Vertretung durch einen einzelnen integer-Wert gespeichert, mit dem Element. Die meisten pre-written-Komponenten ermöglichen es Ihnen schon jetzt zu befestigen, die eine ganze Zahl in jedem Punkt und für diejenigen, die nicht, es ist sehr einfach zu erweitern, die Komponente zu tun.

    Wenn Sie die Weitergabe der Daten zwischen server-Anwendung und einer web-Seite, es ist viel einfacher zu speichern, die einzelnen identifizieren Wert in das id-Attribut des widget, das die Daten darstellt, die als zu Komponieren und zu analysieren, multi-Wert-ids.

    InformationsquelleAutor der Antwort Larry Lustig

Schreibe einen Kommentar