Zwei Spalten Primary Key -> Vermeiden?
-
Der Grund warum Frameworks das nicht unterstützen könnte einfach sein dass das Framework sonst komplizierter würde.
Ist halt einfacher wenn ich jedes "Objekt" (jede Zeile in einer DB) grundsätzlich immer über einen 32 oder 64 Bit Integer identifizieren kann (+Tabellenname natürlich, der aber meist implizit ist). Wenn man das im Framework quasi festlegt vereinfachen sich wohl einige Fälle die sonst etwas aufwändiger wären.
z.B. könnte man eine "Table" Klasse machen die eine Funktion "GetRow(int64_t rowID)" hat. Ob die RowID wirklich 64 Bit ist ist dabei egal, nur *muss* dafür die ID "einspaltig" sein. Theoretisch könnte man sogar Strings als ID erlauben wenn man statt eines int64_t einen Variant übergibt.
----
Ich habe "mittel bis viel" Erfahrung mit Datenbanken, und zu dem Fall "Link-Table" kann ich aus eben dieser Erfahrung sagen: ich wüsste keinen Fall wo ein zusätzlicher Primary-Key sinn machen würde.
Wenn überhaupt, dann macht ein extra Primary-Key nur dann sinn well
a) alle anderen Candidate-Keys zu breit oder aus einem anderen Grund ungeeignet wären und
b) die Tabelle überhaupt von anderen Tabellen aus referenziert wird.Bei einer klassichen Link-Tabelle ist meist a) schon nicht gegeben (2x 32 Bit ist IMO noch nicht wirklich "zu breit") und b) schon überhaupt nicht.
----
Mein Hauptproblem am ganzen ist eigentlich, dass ich kaum praktische Erfahrung habe mit den Datenbanken.
Dann würde ich dir wirklich empfehlen dir den (gratis) SQL Server 2005 Express und das dazupassende Management Studio runterzuladen und dich damit etwas zu spielen. SQL Server 2005 Express ist auch kein "Kinderspielzeug", das ist im Prinzip der vollständige SQL Server, bloss mit einem Limit auf die max. Datenbank-Grösse und einigen fehlenden Features die du für diverse Experimente nicht brauchen wirst (Clustering, ...).
