nicht angemeldet
mehere id's updaten
hallo,
hab ein blödes problem:
ich muss in einer mysql tabelle, mehrere schlüsselwerte gleichzeitig updaten - in dem sinne, dass einer oder mehrere schlüssel den wert eines anderen schlüssels bekommt.
also so in etwa:
ein schlüssel mit id 2 soll in diese tabelle eingefügt werden
id |
1 |
2 |
3 |
das heisst die tabelle muss nachher so aussehen:
id |
1 |
2 |
3 |
4 |
dazu wurde schlüssel 2 und 3 um eins erhöht und dann schlüssel mit id=2 eingefügt.
nun tritt das problem auf, dass ja der um eins erhöhte schlüssel schon existieren kann und somit ein dublicate entry fehler auftritt.
Allerdings ist es nicht so - dass man das ganze einfach vom größten Schlüsselwert zum einzufügenden updaten kann, da es sich nicht wie in dem Beispiel um konkret Zahlen handelt, sondern Zahlenreihen als String.
meine frage ist: wie löse ich das problem am geschicktesten, ohne einen dublicate entry fehler zu bekommen?
-
hi,
meine frage ist: wie löse ich das problem am geschicktesten, ohne einen dublicate entry fehler zu bekommen?
in dem du das datenmodell überarbeitest.
ein schlüssel ist _ausschließlich_ für die identifikation des datensatzes zuständig, und für nichts sonst.
also gibt es auch keine erkennbare notwendigkeit, einen schlüssel "zwischendrin" einfügen zu wollen.gruß,
wahsaga--
"Look, that's why there's rules, understand? So that you _think_ before you break 'em."-
@ wahsaga
hallo wahsaga,
da hast du vollkommen recht. aber - gehen wir mal davon aus, dass ich statt den schlüssel gleichzeitig zur - wohlgemerkt _eindeutigen_ identifikation eines objekts - zu verwenden, eine spalte für dieses objekt anlege, die UNIQUE ist, hätte ich beim updaten dieser spalte dasselbe problem.
meine objekte sind eindeutig über ihren string identifizierbar, und somitist es mir doch eigentlich, nach den regeln der datenmodellierung, auch erlaubt, diesen string als schlüssel zu verwenden.das problem ist, dass die objekte ihre "identifikationsnummer" ändern können, und andere objekte diese annehmen können.
ich hatte mir so eine lösung überlegt, dass ich eine TEMPORARY TABLE der aktuellen erstelle, diese mit TRUNCATE leere, damit ich den Aufbau der Original-Tabelle habe, und dann eine Spalte nach der anderen zu nehmen, den Schlüsselwert upzudaten und dann diesen Satz mit neuem Schlüssel in die temporäre tabelle zu übertragen. Wenn alles übertragen ist - die Orginaltabelle mit der temporären überschreiben.
Ist halt ziemlich unschön.Eine andere Möglichkeit wäre, einen Algorithmus zu schreiben, der die Werte so anordnet, dass es nicht zu überschneidungen kommen kann. Das ist mir aber eigentlich zu aufwendig.
Vielleicht fällt Dir ja noch was ein...
-
Moin schildi,
Ist halt ziemlich unschön.
Eine andere Möglichkeit wäre, einen Algorithmus zu schreiben, der die Werte so anordnet, dass es nicht zu überschneidungen kommen kann. Das ist mir aber eigentlich zu aufwendig.
wäre das eine einmalige Korrektur eines Fehler in der Designphase der DB?
Wie Wahsage bereits erwähnte, solltest du ansonsten die Struktur neu überdenken, ein Schlüßel ist nun mal ein Schlüßel und der wiederum sollte eindeutig sein.
Grüsse
Mike--
Freunde kommen und gehen. Feinde sammeln sich an.-
@mike
naja - aber der schlüssel IST doch eindeutig. Oder heisst für euch eindeutig auch - dass er sich niemals ändern darf.
Mir kommt einfach keine idee, wie ich das anders designen soll ;(-
Moin shildi,
naja - aber der schlüssel IST doch eindeutig. Oder heisst für
das war meine Frage: Wenn es sich um eine einmalige Korrektur handelt, dann geht das. ABER ansonsten ist der Schlüßel natürlich eindeutig und darf aus diesem Grund auch nicht geändert werden. In der Regel hat ein solcher Schlüßel 1 zu n Beziehungen oder auch 1 zu 1 Beziehungen. Mit anderen Worten wenn es kein Schlüßel ist, dann brauchst du ihn auch nicht als solchen zu deklarieren.
Also, Schlüßel oder nicht Schlüßel ist hier die Frage ;-)
Grüsse
Mike--
Freunde kommen und gehen. Feinde sammeln sich an.-
Moin shildi,
naja - aber der schlüssel IST doch eindeutig. Oder heisst für
das war meine Frage: Wenn es sich um eine einmalige Korrektur handelt, dann geht das. ABER ansonsten ist der Schlüßel natürlich eindeutig und darf aus diesem Grund auch nicht geändert werden. In der Regel hat ein solcher Schlüßel 1 zu n Beziehungen oder auch 1 zu 1 Beziehungen. Mit anderen Worten wenn es kein Schlüßel ist, dann brauchst du ihn auch nicht als solchen zu deklarieren.
Also, Schlüßel oder nicht Schlüßel ist hier die Frage ;-)
Grüsse
MikeOK. Also das heisst - für Dich - oder generell - ist ein Schlüssel nicht schon dann eindeutig, wenn er im gesamten Kontext einzigartig und damit das zugehörige Objekt eindeutig identifizierbar ist - er darf sich im Laufe der Zeit also auch nicht ändern!?
Es handelt sich nicht um eine einzige Änderung. Die ganze Tabelle verwaltet ein hierarisches System für ein veränderbares JS-Menü, dass mit PHP aufgebaut wird. Als Schlüssel verwende ich die eindeutigen Schlüssel der Einträge (diese haben eine String-ID, zb.: 02 als Hauptmenupunkt 0 -> Submenupunkt 2).
Übrigens ist mir eingefallen, dass ich den benötigten Algorithums schon habe - da ich diesen auch für eine Ausgabe benötigte.
Habe ihn mal dazwischengeschaltet und dann funktioniert dass auch 100%.
Ist es so bösartig dies zu tun - dass ich es designtechnisch unbedingt anders machen sollte?
Wenn ja - wie würdest Du die Tabelle aufbauen?
-
Moin schildi,
Ist es so bösartig dies zu tun - dass ich es designtechnisch unbedingt anders machen sollte?
ich sags mal so: Ja es ist böse einen Schlüßel zu ändern, weil es ist dann kein eindeutiger Schlüßel mehr.
Es gilt zu analysieren wozu dieser Schlüßel gebraucht wird. Wenn er sich nicht wie ein "roter Faden" durchzieht, dann es es entwender ein unnötiger Schlüßel oder nur ein Schülßel für schnelle Indizierung.
Wenn ja - wie würdest Du die Tabelle aufbauen?
Ohne die Struktur deiner Tabelle zu kennen, ist eine Antwort hier mehr als spekulativ, bzw.nicht möglich.
BTW: Tabelle = Table? Wenn es innerhalb der DB nur ein Table ist, dann benutzt du wohl das Schlüßelfeld zur schnellen Indizierung.
Wenn dieses Schlüßelfeld referenziert zu anderen Tabellen, dann ist die Änderung dieses Feldes eine potentielle Fehlerquelle.
Grüsse
Mike--
Freunde kommen und gehen. Feinde sammeln sich an. -
Moin!
OK. Also das heisst - für Dich - oder generell - ist ein Schlüssel nicht schon dann eindeutig, wenn er im gesamten Kontext einzigartig und damit das zugehörige Objekt eindeutig identifizierbar ist - er darf sich im Laufe der Zeit also auch nicht ändern!?
Eine ID, auf deutsch gerne Schlüssel (bitte mit zwei S schreiben - auch nach alter Rechtschreibung) ist eine eindeutige, sich bei erstmaliger Datensatzerstellung ergebende und danach niemals mehr änderne Identifikationsmarke.
Es handelt sich nicht um eine einzige Änderung. Die ganze Tabelle verwaltet ein hierarisches System für ein veränderbares JS-Menü, dass mit PHP aufgebaut wird. Als Schlüssel verwende ich die eindeutigen Schlüssel der Einträge (diese haben eine String-ID, zb.: 02 als Hauptmenupunkt 0 -> Submenupunkt 2).
Das ist keine ID oder kein Schlüssel, sondern ein Sortierkriterium. Das würde ich in der DB niemals als UNIQUE kennzeichnen wollen, denn dann kann man so nette Sachen wie das hier machen:
UPDATE tabelle SET sortierung = sortierung + 1 WHERE sortierung >= 2
Und schon hast du alle Felder so aktualisiert, dass du eine neue "2" einfügen kannst. Diesen Eintrag wieder zu löschen und alle nachfolgenden Sortierzahlen zurückzuzählen geht entsprechend genauso.
- Sven Rautenberg
-
danke.
ich werde also die tabelle so umstellen, dass ich eine reguläre id habe, die automatisch erzeugt wird, und eine spalte als "sortierkriterium" einrichten, welche nicht unique ist.
danke.
(ich hab doch schlüssel nicht mit ß geschrieben??)
-
-
-
-
-
-
-