nicht angemeldet
yo,
Also zunächstmal folgemdes: Warum sollte ich eine weitere spalte für einen primary key anlegen wenn ich diese nie abfragen würde?
der sinn einen künstlichen schlüssel ist ja, dass er keine informationen trägt, ausser dass er die den datensatz eindeutig identifiert, bzw. die tabellen über FK und PK miteinander verbindet. insofern fragst du ihn schon ab, wenn du einen datensatz bestimmen willst, bzw. wenn du joins bildest. und wenn man den pk und fk noch sinnvolle namen gibst, dann trifft ein pk immer auf einen fk in den abfragen.
speicherplatz ist heute nicht mehr so ein thema wie früher. es ist immer ein abwägen der argumente dafür und dagegen. und es sprechen viele argumte für einen künstlichen schlüssel über nur eine spalte. es ist kein muss, sondern ein rat.
die einzige abfrage die ich mache ist z.b.:
REPLACE INTO messages ('sender', 'empfaenger') VALUES...
die frage ist erst einmal, ob die spalten sender und empfaenger künstliche schlüssel sind oder aber auch andere informationen tragen wie zum beispiel namen. tun sie dass, würde ich davon abraten als schlüssel zu benutzen.
UNIQUE INDEX msg (sender, empfaenger)
PRIMARY KEY msg
so habe ich dich zumindestens verstanden!
richtig, das wäre ein sinnvolle lösung, mit der du auf jeden fall auf der sicheren seite bist.
Ilja