Primärschlüssel ändern

hi @ all,

ich habe folgendes problem. ich möchte zwei tabellen (id, name, ....) zusammenlegen. nur haben sie den gleiche primärschlüssel auf der id spalte - somit kollidiert es ja. ich würde gerne in einer der tabellen die id spallte einfach in jeder zeile z.b. um 1000 erhöhen - sodass da die id für jeden namen nicht mehr 1,2,3,... sondern 1001,1002,1003 lautet.

gibt es da eine methode? oder etwas um das problem mit en identische PK zu umgehen?

lg marscru

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 131419

Url: https://administrator.de/contentid/131419

Ausgedruckt am: 23.11.2024 um 08:11 Uhr

8 Kommentare

Neuester Kommentar

naja - beim zusammenlegen lässt du das Feld ID aus einem der Felder einfach weg... Normal ist so eine Zusammenlegung ja eh mit einem Aufwand beim Anwendungsändern verbunden - d.h. das sollte machbar sein.

Dann gehst du einfach hin und erzeugst in einer Tabelle die notwendigen leeren Felder und lässt die Werte von Tabelle 2 in die Tabelle 1 automatisch kopieren.

Moin marscru,

willkommen im Forum.
Ergänzend zu maretz' Kommentar die Nachfragen:

Verwaltest Du deine Daten mit einem M$-Access, einem mySQL-, einem Oracle-Datenbankblech oder ist es eine Tamagochi 3000 SL?
Oder ist es eine hypothetische Frage wie "Braucht die deutsche Bundesliga eine Winterpause"?
Ist die Spalte "ID" ein AutoWert/AutoIncrement/Sequence oder wird es als Wert beim insert übergeben?
Welche Childtabellen/Foreignkeys hängen von dieser ID ab?
Wenn doch die beiden jetzt zusammenzuführenden Tabellen so friedlich bebeneinander existieren konnten - ist es nicht eher eine Mandantenlösung, die da angebracht wäre?
WTF haben denn diese Datensätze keinen natural key... wieso landen so viele begnadete Amateure immer so schnell bei diesen Kunst-IDs ohne jeglichen Informationswert?

Grüße
Biber

naja biber keine ahnung was das für beitrag sein sollte.....!!

ich möchte eigentlich ohne es 1000 mal manuell wiederholen zu müssen die ID - welche ja mein PK ist - und den betrag 'X' erhöhen! eben eine anweisung wie: erhöhe alle werte in der spalte ID um 10000. geht das irgendwie?

Zitat von @Biber:

* WTF haben denn diese Datensätze keinen natural key... wieso landen so viele begnadete Amateure immer so

schnell bei diesen Kunst-IDs ohne jeglichen Informationswert?

Grüße
Biber

Kleiner Kommentar zu dieser Aussage : Ich würde mich nach 20 Jahre DB Entwicklung nicht als "begnadeter Amatuer" bezeichnen, aber ich finde selten mal eine Natural Key, welcher wirklich als PK Kandidat geeignet ist. In der Regel wird ein "technischer" PK verwendet meiner Erfahrung nach

Gruss

Moin db-wizard,

natürlich werden in der Praxis mehr "technische Schlüssel" verwendet als "natural keys".
Das hat doch aber vor allem die Gründe:

der eindeutig Identifizierende Schlüssel eines Datensatzes wäre zu lang/zu unhandlich/zu inperformant (Beispiel "Name+Vorname+GebDatum+PLZ+...")
der eindeutig Identifizierende Schlüssel eines Datensatzes würde sich u.U. ändern bei Infos, die hohe Änderungsfrequenz haben (Beispiel: PLZ, weil Kunde umzieht)
der PK wird zwangsweise in alle Child-Tabellen vererbt (bei jedem Kundenauftrag müssten theoretisch "Name+Vorname+GebDatum+PLZ+..." als FK-Felder auftauchen.->würde JOINS unnötig aufblähen; unzumutbarer Änderungsdienst bei PK-Änderungen..

Aber::
In all diesen Fällen ist es doch (aus meiner Sicht) schon relevant zu erfahren, ob/was alles an marscrus zu änderendem PK/Id dranhängt.
Ich/Er kann doch nicht einfach über eine Parent-Tabelle ein "Update parent set myID = myId +10000" abfeuern, wenn an dieser myID noch x Childtabellen und Constraints hängen.

Grüße
Biber

Zitat von @Biber:

Moin db-wizard,

natürlich werden in der Praxis mehr "technische Schlüssel" verwendet als "natural keys".
Das hat doch aber vor allem die Gründe:

der eindeutig Identifizierende Schlüssel eines Datensatzes wäre zu lang/zu unhandlich/zu inperformant (Beispiel

"Name+Vorname+GebDatum+PLZ+...")

Eben : PK sollten "unmutable" sein...Der Name einer Person ändert ...Jemand Heiratet, jemand wird geschieden etc....Dieses Beispiel wäre eni "schlechter" PK, abgesehen das deine Beispielkombination nicht notwendigerweise UNIQUE ist

* der eindeutig Identifizierende Schlüssel eines Datensatzes würde sich u.U. ändern bei Infos, die hohe
Änderungsfrequenz haben (Beispiel: PLZ, weil Kunde umzieht)

der PK wird zwangsweise in alle Child-Tabellen vererbt (bei jedem Kundenauftrag müssten theoretisch

"Name+Vorname+GebDatum+PLZ+..." als FK-Felder auftauchen.->würde JOINS unnötig aufbähen; unzumutbarer
Änderungsdienst bei PK-Änderungen..

Aber::
In all diesen Fällen ist es doch (aus meiner Sicht) schon relevant zu erfahren, ob/was alles an marscrus zu änderendem
PK/Id dranhängt.
Ich/Er kann doch nicht einfach über eine Parent-Tabelle ein "Update parent set myID = myId +10000" abfeuern, wenn
an dieser myID noch x Childtabellen und Constraints hängen.

ja, das ist das eigentliche Problem. Falls er keine FK Referenzen auf seinen PK hat, kann er ja die Spalte droppen und korrekt neu aufbauen

Grüße
Biber

Grüsse

was ist daran falsch wenn ich die Pat_ID mit nummern beziffer(1,2,3,4,...) und die dazugehörigen B_ID (Berater) (101,102,103,...)? oder verstehen wir uns da falsch? ich soll nur 2 physisch getrennt datenbanken zusammenlegen - wo aber die PAT_ID und andere doppelt vorkommen. man merkt doch das ich auf dem gebiet voll neu bin
also drop ich sämtliche constraints, ändere meine werte und erstell die entsprechenden PK und FK neu?

geht bitte nicht zu hart mit mir ins gericht