ich weiß zwar, dass ein Primärschlüssel zur eindeutigen Identifizierung einer jeden Zeile benötigt wird. Was ist aber, wenn man nun (nur angenommen) nur eine Tabelle in der Datenbank hat? Ist es dann noch immer nötig einen Primärschlüssel zu definieren, oder kann man alle Operationen innerhalb dieser einen Tabelle auch so durchführen?
eine Tabelle ohne Primärschlüssel ist keine Tabelle, sondern ein Mülleimer. Du brauchst IMMER einen Primärschlüssel.
Primärschlüssel haben auch gar nichts mit der Menge an Tabellen zu tun, die du in der Datenbank hast, sondern damit, dass du deine Daten in dieser Tabelle wiederfinden kannst.
Gruß
Peter
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
dem kann ich nicht ganz zustimmen. Ein Primärschlüssel ist ausschließlich für RI (referenzielle Integrität) zwingend erforderlich. Um allerdings eine Eindeutigkeit der Daten zu gewährleisten reicht ein unique index.
Gruß
Thomas
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
der UNIQUE INDEX ist der entscheidende Teil am Primärschlüssel. Darauf kann man auch einen Foreign Key definieren.
Man kann auch in Höhlen leben, in einer Hütte ist es trotzdem besser.
Oder: ein Primärschlüssel erfüllt - über die rein technische Bedeutung hinaus - weitere Eigenschaften: vor allem Stabilität. Ein Primärschlüssel sollt über die gesamte Lebensdauer eines Datensatzes unverändert bleiben.
Gruß
Peter
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Ein Leben ohne Mops…
…ist denkbar, aber sinnlos (Loriot)
Moin, ALex,
der Aufwand, sich Fälle auszudenken, in denen kein Primärschlüssel notwendig sein könnte, ist größer als der, einen anzulegen.
Der Primärschlüssel ermöglicht das Wiederfinden einzelner Tabellenzeilen. Ein Update klappt auch ohne Primärschlüssel, dann werden halt alle Sätze geändert, die das Suchkriterium erfüllen.
der UNIQUE INDEX ist der entscheidende Teil am
Primärschlüssel. Darauf kann man auch einen Foreign Key
definieren.
Und dazu kann ein Unique-Index auch noch NULL-Werte enthalten, ein PK eben nicht (Ist der UK nun ein logischer, aber nicht physischer PK? Brauch ich dann auch noch einen physichen PK?)
Man kann auch in Höhlen leben, in einer Hütte ist es trotzdem
besser.
Ein paar Check-Constraints noch dazu, hie und da ein Foreign-Key und schon hat man sogar ein Haus …
Oder: ein Primärschlüssel erfüllt - über die rein technische
Bedeutung hinaus - weitere Eigenschaften: vor allem
Stabilität. Ein Primärschlüssel sollt über die gesamte
Lebensdauer eines Datensatzes unverändert bleiben.
Und nun sind wir schon fast bei den Wolkenkratzern …
die etwas verwirrende Antwort lautet: Eigentlich immer, aber im Prinzip nie.
Ich schätze das Bedarf einer Erklärung
Logisch gesehen kann ich mir eine Tabelle ohne Primärschlüssel nur sehr bedingt vorstellen. Wann immer man Daten in einer Datenbank speichert, dann will man in der Regel zukünftig auch wieder Zugriff auf den einzelnen Datensatz haben (wenn nicht, dann hast du höchstwahrscheinlich einen Fehler im Datenbankdesign). Damit das aber möglich ist, brauche ich ein(e Kombination von) Attribut(en), mit denen ich einen Datensatz immer und eindeutig von allen anderen Datensätzen unterscheiden kann. Voilà le Primärschlüssel, wie die Franzosen sagen.
Wenn man jetzt nicht von allen guten Geistern verlassen ist, dann teilt man der Datenbank auch mit, welche(s) Attribut(e) man als Primärschlüssel zu verwenden gedenkt. Dadurch kann dir die Datenbank nicht nur dabei helfen, deinen Primärschlüssel sauber zu halten (indem Doppelenigaben abgelehnt werden), sondern sie kann ggf. performancefördernde Maßnahmen bei Abfragen, Änderungen etc. setzen: Es ist - als Optimizer - mitunter sehr hilfreich, wenn man weiß, dass nur genau ein oder kein Datensatz kommen kann. Idealerweise liegt über einem Primärschlüssel auch tatsächlich ein Index (machen mW alle vernünftigen RDBMSe automatisch, lt. SQL-Standard wäre das aber separat anzugeben).
Wenn man allerdings von allen guten Geistern verlassen ist, dann muss man das nicht machen, daher das „im Prinzip nie“ ganz oben.
Nebenbei noch: Es gibt tatsächlich Entwickler, die meinen sie könnten referentielle Integrität in der Applikationslogik sinnvoll abbilden. Diesen sei das intensive und häufige Studium der Stellenagebote (ausserhalb der EDV, Regalschlichter bei $Supermarkt ist zB ein geeigneter Job) dringend empfohlen…
Angenommen Du würdest eine DB anlegen in der Du lediglich den Spezifischen Leitwert verschiedener Materialien abspeicherst.
Du hättest „Material“ und „Leitwert“. Einen Primärschlüssel bräuchtest Du noch nicht mal als ID-Zahl hinzufügen da Du ihn ja schon durch das Material hättest, das es ja in deiner DB nur einmal geben kann (zumindest von der Logik her).
Ich weiß ja nicht welch ein DB-Konstrukt Dir vorschwebt, aber eine richtige funktionierende Datenbanktabelle ohne Primärschlüssel ist quasi unmöglich. Es muß immer ein einzigartiger Wert je Datensatz vorhanden sein um eine voll funktionsfähige Datenbank zu erstellen.
Kannst ja mal versuchen die Adresse von Peter Müller aus dem telefonbuch rauszufinden. Ohne Telefonnummer wird das schwer den richtigen zu erwischen - mit ist es ein Kinderspiel.
Aber wie gesagt: GEILE FRAGE!!!
Vielleicht solltest Du mal im Unix-Board fragen „Wäre es nicht besser wenn Unix so aufgebaut wäre wie Windows?“ ;o)