moloch hat folgendes geschrieben :

also der key soll dazu kommen

Also dann reicht

nicht.

Du musst alle Primary Key Spalten mitnehmen:

ok, wenn du deinen PK erweitern willst:

angenommen:

Alter key Nr,
neue spalte Datum
neuer Key (nr, Datum)

dann
1.) alten key droppen
drop constraint PK ...
2.) neue Spalte mit not null anlegen
alter table add ... not null;
3.) neue Spalte mit eindeutigen Daten füllen
update table set datum = einDatum
4.) neuen Key anlegen
alter table tablename add constraint table_Pk Primary key(nr, Datum);

müsste so klappen, ich mach nu erstmal feierabend, bin erst Freitag wieder online, also

happy Vatertag

hey entschuldigt war schon weg hoffe der vatertag wurde gut überstanden.
also ich versuche eure vorschläge gleich mal..
bis später

hallo,
also für oracle muss ich in der tat die variante von zuma verwenden. also der part der mir noch gefehlt hatte war der default wert für die neue spalte. darf bei oracle nicht null sein, sonst gibt es fehlermeldung beim versuch die primären anzulegen.
also dank euch alle für die hilfe.
beste grüße

Ich denke mal, meine Variante ist für alle DB-Systeme gültig, mir ist jedenfalls noch keines untergekommen, das sich da anders verhält.
Es würde mich wundern, wenn es ein DB-System gibt, das einen Primärschlüssel mit Null-Werten (nicht 0-Werten!) zulässt.

also bei mssql und mysql habe ich den primary gelöscht und einfach wieder mit dem ergänzenden primärindex angelegt.


bei mssql lege ich so an:


bei oracle und mysql so:



ist da evtl noch der hund begraben?

also, beim ersten Beispiel hast du einen Index angelegt, beim 2ten Beispiel hast du einen Primary Key angelegt. Das ist, wie bereits oben erklärt, NICHT das gleiche!

den index den ich bei mssql angelegt habe ich aber unique und damit passiert doch das was auch bei einem primary passiert oder? also wenn ich versuche einen 2. satz anzulegen mit den gleichen inhalten auf den jeweiligen spalten (mssql -db) dann verweigert er den satz einzutragen. wie bei einem primärkey. wo liegt dann der grundlegende unterschied. ich dachte genau das soll ein primärkey machen. doppelte einträge verhindern

Das ist schon sehr ähnlich.
Ein Index ist aber 'nur' ein Performancebeschleuniger beim Suchen.
Die Angabe Unique ist für die DB das Kennzeichen, bei einer Spalte auf Eindeutigkeit 'aufzupassen'. Deine Zeile enthält also 2 Befehle für die DB.
Ein Primary Key macht sozusagen beides in einem Befehl, d.h. es wird eine Eindeutigkeit erzwungen und gleichzeitig ein Index auf die Spalte(n) gelegt.

Ich hoffe, das das so verständlich ist, ist schwer, das mit einfachen Worten und trotzdem korrekt zu erklären.

hm ja ok. und wo ist das argument den primary zu nutzen wenn ich mit meiner sql das ergebnis erziele was ich auch haben wollte? also einen satz mit den selben auf den jeweiligen spalten- inhalten zu verhindern
oder kann ich es auch so machen?

boah, wie soll ich dir das erklären ....
ich versuchs mal so:
den Primary key nutzt man in der Regel, um festzulegen, über welche(n) Wert(e) man auf einen Datensatz eindeutig zugreift. Unique Nutzt man, wenn man eine 2te Möglichkeit eines eindeutigen Zugriff's nutzen möchte.
z.B.
die Felder
Kd, Nr
bestimmen einen eindeutigen Datensatz in einer Tabelle, grundsätzlich wird auch über die beiden Felder abgefragt. (Also, Primary Key(KD, Nr) angelegt). Zusätzlich gibt es in der Tabelle ein Feld
LaufendeNr
das man z.b von einem DB-Generator belegen lässt. Dieses wird mit Unique angelegt und z.b zum verknüpfen der Tabelle mit abhängigen Tabellen genutzt.
Tabelle2 hat ein Feld ID (welches dort der PK ist), das referenziert auf Tabelle 1 Feld LaufendeNr. So kann man dann mit Hilfe von Foreign Key's die Integrität der Datenbankabhängigkeiten vom DB-System steuern lassen.

Ist sicher nicht vollkommen korrekt erklärt, aber besser weiss ich es dir im Moment nicht zu erklären.
Generell würde ich dir empfehlen, dich mal mehr mit dem Thema Datenbanken zu beschäftigen, ich kann sie zwar einigermaßen benutzen, aber zu 'Lehrerqualitäten' reichts wohl nicht so ganz ...

Ich versuch mich auch mal an einer Erklärung

Wir haben oft den Fall, dass ein Kunde einen Datensatz mit einer Nummer identifizieren möchte. Z.B. um bei der Dateneingabe über die Nummer auf den Datensatz zugreifen zu können. Viele User lernen diese Nummern erstaunlich schnell auswendig, wenn sie sie öfters benötigen.
Diese Nummer möchte der Kunde aber später nochmal ändern können. Wenn er z.B. Datensäte in Nummernkreisen umorganisieren möchte, oder Ähnliches.

Nehmen wir eine Tabelle mit Kunden:
Spalten: ID, NR, NAME
Ich mache einen Primärindex auf das Feld ID. Damit identifiziere ich innerhalb meiner Anwendung den Datensatz. Die ID wird einmal beim Anlegen des Datensatzes vergeben und nie mehr geändert. Außerdem bekommt der User die ID niemals zu sehen. Und ich mache einen Unique-Index auf die Spalte NR. Damit kann der Kunde eine Kundennummer nur einmal vergeben. Er kann die NR nach Lust und Laune ändern (mit der Einschränkung, dass die NR eindeutig bleibt), ohne dass ich in anderen Tabelle außer der Kundentabelle etwas ändern müsste.

dank euch,
ich denke jetzt hab ichs begriffen. werde auch noch mal versuchen was verständliches dazu zu finden.
danke auf jeden fall für die geduldige hilfe

Zudem beschleunigen Indizes zwar die Selektionen, verlangsamen aber DML-Abfragen ( Insert, Update, Delete). Da die Änderungen in den jeweiligen Indizes mit angepasst werden müssen.