nicht angemeldet
alle IDs um einen bestimmten Wert erhöhen
0 1 0 
MudGuard
0
alle IDs um einen bestimmten Wert erhöhen
Hallo zusammen,
habe eine DB mit einer Tabelle mit IDs, die natürlich einzigartig sind. Außerdem ist die Spalte mit einem auto-inc versehen.
Was möchte ich machen:
Alle IDs um einen Wert ( z.B. 50 ) erhöhen. Das habe ich mir folgendermaßen vorgestellt:
UPDATE tablename SET spaltenname=spaltenname+50
Geht aber nicht, da er das scheinbar nicht auf Einmal updated sondern Zeile für Zeile - so entstehen doppelte Einträge und er spuckt einen Fehler aus ...
Ideen?
MfG
Eric Teubert
-
Hi,
Ideen?
ja, zweischrittig vorgehen.
Humph
-
ja, zweischrittig vorgehen.
Das heißt? ó_ò
Erst den gesamten table per PHP auslesen, Werte aktualisieren, table leeren und erneut füllen?
Geht das nicht ohne PHP?Eric
-
Hi,
ja, zweischrittig vorgehen.
Das heißt? ó_ò
die Datenmanipulation so vornehmen, dass keine Fehlermeldung des Datenserversystems kommt. Sollen "doppelte IDs" vermieden werden, bietet sich das sequentielle Absenden (Exekutieren) zweier verschiedener SQL-Statements an.
Erst den gesamten table per PHP auslesen, Werte aktualisieren, table leeren und erneut füllen?
Geht das nicht ohne PHP?Du exekutierst doch nur mithilfe von PHP SQL-Statements auf Datenserverebene.
Humphy
-
die Datenmanipulation so vornehmen, dass keine Fehlermeldung des Datenserversystems kommt. Sollen "doppelte IDs" vermieden werden, bietet sich das sequentielle Absenden (Exekutieren) zweier verschiedener SQL-Statements an.
Na gut, dann werde ich das wohl mal so probieren.
Danke ...
-
-
-
-
Hallo Eric,
habe eine DB mit einer Tabelle mit IDs, die natürlich einzigartig sind. Außerdem ist die Spalte mit einem auto-inc versehen.
welches Datenbankmanagementsystem (DBMS) verwendest Du? Es sieht nicht nach MS SQL-Server aus, da dieser Identitätsspalten nicht aktualisieren kann. Ist es MySQL? Dann sollte Dir das Handbuch, Abschnitt UPDATE-Syntax weiterhelfen. Mit Hilfe der ORDER-BY-Klausel kannst Du die Reihenfolge der Zeilen bestimmen.
Alle IDs um einen Wert ( z.B. 50 ) erhöhen. Das habe ich mir folgendermaßen vorgestellt:
Sorge dafür, dass keine doppelten Einträge vorkommen können, indem Du die Zeilen mit den größten ID-Werten zuerst aktualisierst. Welche Sortierreihenfolge Du verwenden solltest, dürfte damit klar sein.
Aber ohne Dein DBMS zu kennen, kann man Dir nicht konkret helfen. In nahezu allen Fällen ist es übrigens keine besonders gute Idee, die Werte der Primärschlüsselspalte ändern zu wollen.
Freundliche Grüße
Vinzenz
-
Hi,
habe eine DB mit einer Tabelle mit IDs, die natürlich einzigartig sind. Außerdem ist die Spalte mit einem auto-inc versehen.
Was möchte ich machen:
Alle IDs um einen Wert ( z.B. 50 ) erhöhen.Darf man nach dem Sinn fragen? ID-Spalten in der Datenbank dienen üblicherweise ausschließlich der Identifizierung des jeweiligen Datensatzes.
Irgendetwas anderes in den ID-Wert hineinzuinterpretieren sollte man unterlassen.cu,
Andreas--
Warum nennt sich Andreas hier MudGuard?
Schreinerei Waechter
Fachfragen per E-Mail halte ich für unverschämt und werde entsprechende E-Mails nicht beantworten. Für Fachfragen ist das Forum da.
-
Hi,
Darf man nach dem Sinn fragen? ID-Spalten in der Datenbank dienen üblicherweise ausschließlich der Identifizierung des jeweiligen Datensatzes.
Irgendetwas anderes in den ID-Wert hineinzuinterpretieren sollte man unterlassen.gerade die auto increment Spalten verfuehren dazu "etwas in diese hineinzuinterpretieren", was auch ein wenig daran liegt, dass sie eben selbst Bedeutung generieren. ;-)
Abend noch!
Mikey-
yo,
gerade die auto increment Spalten verfuehren dazu "etwas in diese hineinzuinterpretieren", was auch ein wenig daran liegt, dass sie eben selbst Bedeutung generieren. ;-)
und welche bedeutung wäre das ?
Ilja
-
Hi,
gerade die auto increment Spalten verfuehren dazu "etwas in diese hineinzuinterpretieren", was auch ein wenig daran liegt, dass sie eben selbst Bedeutung generieren. ;-)
und welche bedeutung wäre das ?
die zeitliche Reihenfolge der Datensatzerstellung wird als potentiell nutzbare Information generiert und steht somit weniger erfahrenen Kraeften bei Bedarf zur weiteren Verwendung erst einmal zur Verfuegung. ;-)
(Klar, wenn man da wie der Threadinitiator herumfuhrwerkt, dann geht diese Information zumindest in Teilen verloren, aber das macht man ja auch normalerweise nicht.)BTW - es kann sich - wenn man etwas Phantasie hat - aus geschaeftlichen Gruenden durchaus die Notwendigkeit ergeben die o.g. Information zu nutzen. Darum ist es natuerlich immer besser - wie Muddy ganz richtig anmerkt - bedeutungsfreie Primaerschluessel zu erstellen und zu pflegen, damit solche Anforderungen erst gar nicht entstehen, meine ich.
Das Gekaempfe des Threadinitiators mit den FK constraints wuerde zudem dann entfallen. :-)
Humph
-
yo,
die zeitliche Reihenfolge der Datensatzerstellung wird als potentiell nutzbare Information generiert und steht somit weniger erfahrenen Kraeften bei Bedarf zur weiteren Verwendung erst einmal zur Verfuegung. ;-)
ich würde davon abraten, aus einer ID die zeitliche reihenfolge ablesen zu wollen, weil man sich darauf nicht verlassen kann. sicherlich verleitet der autoincrement dazu, aber trotzdem ist das der falsche weg. die id mit autoincrement hat ergo keine zusätzliche bedeutung.
Ilja
-
Hi,
die zeitliche Reihenfolge der Datensatzerstellung wird als potentiell nutzbare Information generiert und steht somit weniger erfahrenen Kraeften bei Bedarf zur weiteren Verwendung erst einmal zur Verfuegung. ;-)
ich würde davon abraten, aus einer ID die zeitliche reihenfolge ablesen zu wollen, weil man sich darauf nicht verlassen kann. sicherlich verleitet der autoincrement dazu, aber trotzdem ist das der falsche weg. die id mit autoincrement hat ergo keine zusätzliche bedeutung.
richtig, aber - wie bereits ausgefuehrt - es koennen kaufmaennische Anforderungen hochkommen und die ID kann im o.g. Sinne genutzt werden, und das sogar moeglicherweise sinnfrei.
Es ging ausschliesslich darum die relative Minderwertigkeit einer bedeutungsbeladenen ID zu belegen.
Humph
-
yo,
richtig, aber - wie bereits ausgefuehrt - es koennen kaufmaennische Anforderungen hochkommen und die ID kann im o.g. Sinne genutzt werden, und das sogar moeglicherweise sinnfrei.
jeder DBA, der so etwas verzapft, die ID für kaufmänsiche anforderungen zu benutzen gehört erschossen. ;-)
Ilja
-
Hi,
jeder DBA, der so etwas verzapft, die ID für kaufmänsiche anforderungen zu benutzen gehört erschossen. ;-)
Du magst lachen, aber z.B. Vertragsnummern dienen oft als Primaerschluessel, auch mit der Extra-Anforderung fortlaufend zu sein.
Mal davon abgesehen, dass man fuer diese benutzerfruendlichen IDs keinesfalls den PK nutzen sollte, gibt es auch koestliche Probleme, wenn Datenhaltungen zusammengefuehrt werden sollen (siehe dieser Thread) oder auch wenn bspw. die Vertragsnummer um eine Niederlassungskennung erweitert werden soll.
Alles schon gesehen, sowas.
Gruesse!
Humph-
yo,
Du magst lachen, aber z.B. Vertragsnummern dienen oft als Primaerschluessel, auch mit der Extra-Anforderung fortlaufend zu sein.
das sind dann aber sprechenende schlüssel und wohl eher keine fortlaufende nummerieung. da steckt informationen in den pk drinne, was aber bei einem auto-incrementwert nicht der fall ist.
Mal davon abgesehen, dass man fuer diese benutzerfruendlichen IDs keinesfalls den PK nutzen sollte, gibt es auch koestliche Probleme, wenn Datenhaltungen zusammengefuehrt werden sollen (siehe dieser Thread) oder auch wenn bspw. die Vertragsnummer um eine Niederlassungskennung erweitert werden soll.
da kenne ich auch ein gutes beispiel, wo ich im auftrag eines rathauses mir mal die alb datenbank vorgeknöpft habe. die treiben es mit den pk noch bunter, hat mich einige zeit gekostest, darauf zu kommen, dass die für ein und dasselbe objekt mehrere pk's haben. da fängt der spass erst an....
Ilja
-
Hi,
die treiben es mit den pk noch bunter, hat mich einige zeit gekostest, darauf zu kommen, dass die für ein und dasselbe objekt mehrere pk's haben.
uebel, uebel.
Das Schlimme ist auch noch, dass man es - wenn man solche Sachverhalte diskutiert - oft auch noch mit Leuten zu tun hat, die fuer bspw. hier uebliche und erfolgreiche Argumentationen nicht zugaenglich sind. Man geraet sogar in Verdacht Besserwisser zu sein oder noch schlimmer ineffizient zu sein (Die anderen sind ja immer produktiv, haben durch eigene Fehler typischerweise am Datendesign immer schoen viel zu tun. In Extremfaellen reagieren die nur noch mit Aussagen wie "Ich habe keine Zeit" (sinngemaess)).
Interessant ist die daraus folgende Frage:
Soll man sich ueberhaupt freuen, wenn man einen brauchbaren Zugang zur Softwareentwicklung gefunden hat?"Sozial kompetente" Leute (i.p. Fachkenntnis Dumpfbacken) bringen es oft ziemlich in den Firmen. Nach dem Motto:
Fuer die Entwicklung die "bornierten Programmierer", fuer die Personalfuehrung die Leute, "mit denen man reden kann"
Das liest sich auch ganz gut, schlimm kann das Ganze aber werden wegen der Weisungsbefugnis der "sozial kompetenten Leute" auch in Fachfragen.So, habe ich mich hier mal ausgeweint. ;-)
Gruesse!
Humph-
yo,
Das Schlimme ist auch noch, dass man es - wenn man solche Sachverhalte diskutiert - oft auch noch mit Leuten zu tun hat, die fuer bspw. hier uebliche und erfolgreiche Argumentationen nicht zugaenglich sind.
willig zu helfen waren sie im rathaus schon, trotzdem haben sie mich auf eine falsche fährte geführt. aber das lag mehr daran, das sich wohl keiner so richtig über die problematik gedanken gemacht hat.
das ALB ist so geregelt, dass sich bestimmte schlüssel für grundstücke im liegenschaftsbuch zum großen teil auch aus schlüsseln deren besitzern bildet. das ist nicht nur sehr unangenhem, wenn sich der besitzer ändert und sich damit auch die bezeichnung des grundstücks ändert, sondern es weil natürlich auch mehrere besitzer geben kann, zum beispiel bei eigentumswohnungen. jeder hatte dann eine eiegen nummer für das gleiche grundstück....
was mir letztlich am meisten geholfen hat, waren aufzeichnungen von anno dazumal, die sie fast weggeschmissen hätten. das papier war so alt, dass es schon vergilbte und noch von datensichtgeräten (neudeutsch Monitore) die rede war....
Ilja
-
-
-
-
-
-
-
-
-
-
Darf man nach dem Sinn fragen?
Klar darf man das :)
Habe zwei Foren. Das eine "neuere" online, das "ältere" offline. Die Datenbankstruktur ist dieselbe. Nun möchte ich die Threads des Einen im Anderen zur Verfügung stellen ( Archiv ).
Habe es nun so gelöst, dass ich alles alles erst auslese - allerdings mit absteigenden IDs. So konnte ich diese ohne Probleme erhöhen.
-
Hi,
Darf man nach dem Sinn fragen?
Klar darf man das :)
Habe zwei Foren. Das eine "neuere" online, das "ältere" offline. Die Datenbankstruktur ist dieselbe. Nun möchte ich die Threads des Einen im Anderen zur Verfügung stellen ( Archiv ).
Habe es nun so gelöst, dass ich alles alles erst auslese - allerdings mit absteigenden IDs. So konnte ich diese ohne Probleme erhöhen.
darf man einen Kommentar zum beschriebenen Sinn abgeben? ;-)
Also, Dir ist schon klar, dass Du die Probleme mit den (bequemen?!) auto-increment Datenfeldern (Primaerschluesseln) hausgemacht hast?
Aber, hausgemacht schmeckt es ja immer noch am Besten...
Mumph
-
Also, Dir ist schon klar, dass Du die Probleme mit den (bequemen?!) auto-increment Datenfeldern (Primaerschluesseln) hausgemacht hast?
Die Datenbankstruktur ist nicht von mir, ich versuche nur damit zu leben ... :)
-
-
-
-
yo,
eher unwahrscheinlich, dass du nochmal hier reinschauen wirst. aber fürden fall, hier noch eine andere möglichkeit.
du kannst den pk contrainst der entsprechenden tabelle entfernen. damit hast du keine schwierigkeiten mehr beim update.
nach dem update nicht vergessen, den pk wieder zu setzen und autoincrementwert wieder einzubinden, wobei es einen neuen höchsten wert in der tabelle geben wird, sprich man muss den counter neu setzen.
Ilja