suchen und ersetzen in mysql

[Sigmar]

Guten Tag,

Mein Beispiel: Spalte A enthält die Einträge:
ID1, "Eintrag1"
ID2, "Eintrag1"
ID3, "Eintrag2"
ID4, "Eintrag2,Eintrag3,SonstigerText"

Kann ich in einem Abwasch alle Enitrag2-Einträge suchen und gegen EintragXY austauschen, ohne den Rest zu verändern?

Ich kenne das suchen und ersetzen über "update set ...="...".
Ich kenne auch das suchen über select ... where like...

Aber mir fällt nichts ein, wie ich mein Vorhaben umsetzen soll?

Sigmar

[Tom]

Hello,

Mein Beispiel: Spalte A enthält die Einträge:
ID1, "Eintrag1"
ID2, "Eintrag1"
ID3, "Eintrag2"
ID4, "Eintrag2,Eintrag3,SonstigerText"

Kann ich in einem Abwasch alle Enitrag2-Einträge suchen und gegen EintragXY austauschen, ohne den Rest zu verändern?

Ich kenne das suchen und ersetzen über "update set ...="...".
Ich kenne auch das suchen über select ... where like...

Aber mir fällt nichts ein, wie ich mein Vorhaben umsetzen soll?

ist wirklich nur noch schwer zu finden, das Online-Handbuch von MySQL, aber guckt Du
http://dev.mysql.com/doc/refman/5.1/en/string-functions.html
und dort speziell die Funktion
http://dev.mysql.com/doc/refman/5.1/en/string-functions.html#function_replace

Die baust Du ins Update-Statement ein und als Quellargument nimmst Du die Spalte (den Spaltennamen).

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Sigmar]

ist wirklich nur noch schwer zu finden, das Online-Handbuch von MySQL, aber guckt Du
http://dev.mysql.com/doc/refman/5.1/en/string-functions.html
und dort speziell die Funktion
http://dev.mysql.com/doc/refman/5.1/en/string-functions.html#function_replace

Arghs, daran hab ich nicht gedacht.
Deshalb umso mehr Dank an Dich. Klappt hervorragend.

Aber zwei Fragen habe ich noch. Kann ich das ohne Rücksicht einfach immer anwenden oder hat ein gewöhnliches Update-Statement (außer der Performance) noch andere Vorteile?

Wieviel performanter ist das gewöhnliche Update-Statement im Vergleich zu meinem Update-Statement inklusive dem replace?

Variante1: update table set Spalte='EintragXY' where Spalte='Eintrag2'

Variante2: update table set Spalte= replace(Spalte, 'Eintrag2', 'EintragXY')

VG, Sigmar

[Tom]

Hello,

Wieviel performanter ist das gewöhnliche Update-Statement im Vergleich zu meinem Update-Statement inklusive dem replace?

Bevor Du über Leistungsfähigkeit und Leistungsbedarf / zu leistende Arbeit nachdenkst, solltest Du erst Vinzenz Einwand berücksichtigen und die Struktur normalisieren.
https://forum.selfhtml.org/?t=195295&m=1307043

Die Replace-Funktion wird wohl keine unangemessene zusätzliche Arbeit verursachen, denn es wird ja nur auf die Unternmenge angewendet. Schlimmer ist das Like-Konstrukt bei der Suche der Untermenge aus der Gesamtmenge, denn _das_ muss auf jeden Datensatz der Gesamtmenge angewendet werden.

Das kannst Du vermeiden, wenn Du eine indizierbare normaliserte Teilmenge in einer eigenen Tabelle schaffst, also nomalisierst.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Vinzenz Mai]

Hallo Sigmar,

Mein Beispiel: Spalte A enthält die Einträge:
ID1, "Eintrag1"
ID2, "Eintrag1"
ID3, "Eintrag2"
ID4, "Eintrag2,Eintrag3,SonstigerText"

Dein vierter Datensatz sieht nach einem Fehler im Datenmodell aus und Du hättest möglicherweise kein Problem mehr, wenn Du diesen behebst:

Tabelle A

id

id
--
 1
 2
 3
 4

Tabelle B
id
fk_a -- Fremdschlüssel zur Tabelle A
wert

id | fk_a | wert
--------------------
 1 |    1 | Eintrag1
 2 |    2 | Eintrag1
 3 |    3 | Eintrag2
 4 |    4 | Eintrag2
 5 |    4 | Eintrag3
 6 |    4 | SonstigerText

Hier kannst Du wunderbar mit

UPDATE  
    TabelleB  
SET  
    wert = 'EintragXY'  
WHERE  
    wert = 'Eintrag2'  

arbeiten.

Kann ich in einem Abwasch alle Enitrag2-Einträge suchen und gegen EintragXY austauschen, ohne den Rest zu verändern?

prinzipiell: ja

Ich kenne das suchen und ersetzen über "update set ...="...".

UPDATE mit SET und WHERE und Stringoperationen. Das geht mir REPLACE(), wie Tom Dir bereits geschrieben hat.

Wenn es jedoch so ist, wie ich vermute, rate ich Dir dazu, Änderungen an Deinem Tabellendesign vorzunehmen.

Freundliche Grüße

Vinzenz

[Sigmar]

Wenn es jedoch so ist, wie ich vermute, rate ich Dir dazu, Änderungen an Deinem Tabellendesign vorzunehmen.

Hallo Vinzens,

Du hast einen guten Riecher. Es ist genau so, wie Du vermutest. Dennoch werde ich es nicht ändern, da es in diesem Fall ganz bewusst so konstruiert wurde.

Bei einem Vorkommen von ca. 1 Promille habe ich hier bewußt das nicht normalisierte Modell gewählt. Ansonsten ist aber der komplette db-Rest schönstens normalisiert. Hier war es einfach wichtig, mit einem Blick in php-myadmin innerhalb einer Zeile alle nötigen Infos zu haben. Zudem werden diese Zeilen immer wieder kopiert und anderweitig genutzt. Das ist auf diese Art deutlich schlanker im php-code. Manchmal muss man Kompromisse schließen. Dass ich es damit jetzt etwas schwieriger habe, sehe ich ein. Aber auch das beruht auf der Tatsache, dass ich einen db-Fehler, den ich vor Jahren gemacht habe, ausmerze. Soll heißen, nach Beendigung eines update/replace-Durchlaufes benötige ich dieses Script kein 2. mal.

Den Support-Vorteil, bei einem Blick in die Zeile alle Infos beisammen zu haben, möchte ich aber ungerne aufgeben. Das wäre anders, wenn das Vorkommen der Doppeleinträge pro Spalte nicht so gering wäre.

Grüße, Sigmar

[Tom]

Hello,

Den Support-Vorteil, bei einem Blick in die Zeile alle Infos beisammen zu haben, möchte ich aber ungerne aufgeben. Das wäre anders, wenn das Vorkommen der Doppeleinträge pro Spalte nicht so gering wäre.

Spannend ist immer nur, ob man die Liste in einem Textfeld auch immer sauber durchsuchen (und ersetzen) kann. Wenn ein Teilstring mehrfach vorkommt, hast Du mit Zitronen gehandelt.

Es würde bei MySQL darüberhinaus auch immer noch der (String-)Spaltentypen SET oder ENUM für Dich interessant sein, die die Normalisierung implitzit betreiben.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Sigmar]

Spannend ist immer nur, ob man die Liste in einem Textfeld auch immer sauber durchsuchen (und ersetzen) kann. Wenn ein Teilstring mehrfach vorkommt, hast Du mit Zitronen gehandelt.

Wie wahr, wie wahr :-)
Aber das hatte ich schon bedacht und jetzt ist das Thema ist durch.

Es würde bei MySQL darüberhinaus auch immer noch der (String-)Spaltentypen SET oder ENUM für Dich interessant sein, die die Normalisierung implitzit betreiben.

Muss ich jetzt nicht verstehen, oder? ;-)

Grüße, Sigmar

[Tom]

Hello,

Spannend ist immer nur, ob man die Liste in einem Textfeld auch immer sauber durchsuchen (und ersetzen) kann. Wenn ein Teilstring mehrfach vorkommt, hast Du mit Zitronen gehandelt.

Wie wahr, wie wahr :-)
Aber das hatte ich schon bedacht und jetzt ist das Thema ist durch.

Es würde bei MySQL darüberhinaus auch immer noch der (String-)Spaltentypen SET oder ENUM für Dich interessant sein, die die Normalisierung implitzit betreiben.

Muss ich jetzt nicht verstehen, oder? ;-)

Guckst Du wieder Online-Handbuch, liest Du ganz unten auf Seite

http://dev.mysql.com/doc/refman/5.1/en/string-type-overview.html

Wenn Deine Einträge nicht mehr als 64 verschiedene Möglichkeiten kennen, die gar nicht bis gleichzeitig auftreten können und bei denen die Reihenfolge egal ist, dann ist SET der passende Spaltentyp für Dich.

Die "Normalisierung" nimmt die Datenbank dann implizit durch die Darstellung vor, sie eröffnet also intern die Nachschlagetabelle, die Du sonst explizit anlegen müsstest. Das Ganze ist aber nur dann sinnvoll, wenn sich die Bezeichner während der Lebensdauer der Haupttabelle nicht allzu hoft ändern und es niemals mehr als 64 in Gesamtheit werden können. Das ist geeigent für Klassifizierugen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Ilja]

moin,

Die "Normalisierung" nimmt die Datenbank dann implizit durch die Darstellung vor, sie eröffnet also intern die Nachschlagetabelle, die Du sonst explizit anlegen müsstest.

das hat aber mit normalisierung weniger zu tun, sondern mit eher mit datenintegrität.

Ilja

[dedlfix]

Hi!

Spannend ist immer nur, ob man die Liste in einem Textfeld auch immer sauber durchsuchen (und ersetzen) kann. Wenn ein Teilstring mehrfach vorkommt, hast Du mit Zitronen gehandelt.

Man kann die Trennzeichen beim suchen mit einbeziehen, also statt text muss man ,text, suchen. Das setzt voraus, dass jeweils am Anfang und Ende ein zusätzliches Trennzeichen steht, damit man sich eine Sonderbehandlung der Enden ersparen kann. Es lässt sich meistens ein Workaround für die zusätzlichen Probleme finden, außer für die Performance. Das Suchen nach Inhalten bleibt bei so einem Mehrfachfeld ineffizient, weil jeder Datensatz einzeln über Stringverarbeitungsfunktionen angeschaut werden muss und kein Index verwendet werden kann.

Lo!