8
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
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
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 131419
Url: https://administrator.de/contentid/131419
Printed on: April 23, 2024 at 06:04 o'clock
8 Comments
Latest comment
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.
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:
Grüße
Biber
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?
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:
Grüße
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:
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
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:
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
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)
Ä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.
Änderungsfrequenz haben (Beispiel: PLZ, weil Kunde umzieht)
- der PK wird zwangsweise in alle Child-Tabellen vererbt (bei jedem Kundenauftrag müssten theoretisch
Ä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
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
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
Hallo,
geht nicht ein UPDATE personen SET id=(id+1000); ?
geht nicht ein UPDATE personen SET id=(id+1000); ?
