nicht angemeldet
SQL Primary Key besteht aus mehreren Spalten?
Hi!
Wie kann ich in SQL angeben das mein Primary Key aus mehreren Spalten besteht?
danke
Robert
-
Hallo Robert,
es wäre nicht schlecht gewesen, wenn Du erwähnt hättest für welches DBMS Du das benötigst ;-)
Für MySQL würde ein solche CREATE Statement z.B. wie folgt aussehen
create table colors(id varchar(6) not null, name varchar(32) not null, PRIMARY KEY(id,name));
wobei der Primary Key aus den Spalten id und name bestehen würde.
Vielleicht hilft Dir das ja schon weiter.
Gruß
PreachieHi!
Wie kann ich in SQL angeben das mein Primary Key aus mehreren Spalten besteht?
danke
Robert-
sry, brauchs für Oracle 10g, da sollt aber keine Unterscheid sein!?
lg
Robert-
sry, brauchs für Oracle 10g, da sollt aber keine Unterscheid sein!?
Versuchs halt. Ich wuerd nicht drauf wetten, dass es klappt. Hast Du schonmal mit Access und nem MS SQL Server geaerbeitet? Zwei Welten.
Ich hab mal Tabellen (Struktur und Daten) kopieren muessen die ueber 100 Spalten hatten und dachte, fix nen Dump gemacht und gut. Fehlgedacht.
--
"Die Diebesgilde beklagte sich darueber, dass Mumm in aller Oeffentlichkeit behauptet hatte, hinter den meisten Diebstaehlen steckten Diebe."
- T. Prachett -
Hi,
sry, brauchs für Oracle 10g, da sollt aber keine Unterscheid sein!?
doch, sollte es. Jedes DBMS hat seinen eigenen SQL-Dialekt, bisweilen hat es signifikante Unterschiede bis hin zu kompletten Inkompatibilitäten. Im Zweifel konsultiere die Dokumentation Deines DBMS zur genauen Syntax und ihren Implikationen.
Cheatah
--
X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes
-
-
-
Hello,
Wie kann ich in SQL angeben das mein Primary Key aus mehreren Spalten besteht?
Ein Primary Key, der über mehrere Spalten geht, ist nicht datenunabhängig. Darum versuche ich sowas immer zu vermeiden. Wenn man genau darüber nachdecnkt, können sich die Werte der betroffenen Datanspalten während der Lebensdauer des Datensatzes doch meistens ändern und dann muss man so hässliche Sachen, wie Schlüsselwertweitergabe betreiben, was wieder zu Konsistenzproblemen führen kann.
Besser also nur einen generierten Key, der von den Daten unabhängig bleibt.
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
yo,
Ein Primary Key, der über mehrere Spalten geht, ist nicht datenunabhängig.
dem kann ich nicht ganz folgen. zum einen verstehe ich unter datenunabhängigkeit etwas anderes. du meinst die abhängigkeiten bei den normalisierungsprozessen ?
und auch wenn ich in der praxis immer einen kunstlichen primary key über eine spalte pro tabelle einsetzen würde, so könnten durchaus zwei fremdschlüssel einen primary key bilden, wo ich niemals die inhalte des primary key ändern müsste.
Ilja
-
Hallo,
und auch wenn ich in der praxis immer einen kunstlichen primary key über eine spalte pro tabelle einsetzen würde, so könnten durchaus zwei fremdschlüssel einen primary key bilden, wo ich niemals die inhalte des primary key ändern müsste.
Sorry, das verstehe ich nicht.
Die zwei Fremdschlüssel sind doch wohl, wenn ich den Thread richtig interpretiere, dann auch möglichst datenunabhängig, also generierte Schlüssel zu den zwei Datensätzen der n- und der m-Tabelle.
Es ist also gar nicht notwendig, sie zu ändern, nur weil ich in einem der betroffenen Datensätze ein Datum ändert.
Ich stimme dem daher zu: keine Daten für primary Keys verwenden, wenn es sich irgendwie vermeiden lässt.
Gesundheit!
Dr. Bit-
yo,
Die zwei Fremdschlüssel sind doch wohl, wenn ich den Thread richtig interpretiere, dann auch möglichst datenunabhängig, also generierte Schlüssel zu den zwei Datensätzen der n- und der m-Tabelle.
das widerspricht aber dem, was Tom gesagt hat: "Ein Primary Key, der über mehrere Spalten geht, ist nicht datenunabhängig"
zumal ich von den begriff Datenunabhängigkeit eine andere vorstellung habe.
Ilja
-
Hello und Hei,
Die zwei Fremdschlüssel sind doch wohl, wenn ich den Thread richtig interpretiere, dann auch möglichst datenunabhängig, also generierte Schlüssel zu den zwei Datensätzen der n- und der m-Tabelle.
das widerspricht aber dem, was Tom gesagt hat: "Ein Primary Key, der über mehrere Spalten geht, ist nicht datenunabhängig"
Ich habe von einer einzigen (Daten-)Tabelle gesprochen, zumindest habe ich das gemeint.
Nun kommt hier plötzlich eine Metadaten-Tabelle ins Spiel. M:N-Tabellen müssen gar keine eigenen (Stamm- oder Bewegungs-)Datenspalten enthalten, sondern es reicht, wenn sie Schlüssel enthalten.Finde ich jetzt nicht fair, wie du die Begriffe hier jetzt vermengst, oder wolltest Du nur zu einer besseren Klarstellung im Thread beitragen?
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
-
-
-