Hallo Alex,
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…
Gruß
Martin