Datenbank Massenverarbeitung

  • Gibt es eine Möglichkeit in der Datenbank Forenbeiträge massenhaft abzuarbeiten?


    Speziell geht es um die Änderung der Domain.


    Es hieß früher allaboutsims.net und jetzt allaboutsims.de


    Gibt es eine Möglichkeit, diesen String zu ersetzen, ohne das etwas anderes davon betroffen ist?


    Also aus dem kompletten Kontext z.B. http://www.allaboutsims.net nur allaboutsims.net in allaboutsims.de zu ändern.

    Rest bleibt wie es war.


    Geht das?


    Weil sonst muß ich jeden Link im Forum manuell bearbeiten ;(

  • Leichter (und wesentlich performanter) fänd ich eine Lösung mittels SQL-Abfrage, z.B. so:


    SQL
    UPDATE `tabellenname` SET `feldname` = REPLACE(`feldname`, "altedomain", "neuedomain");


    Allerdings ohne Gewähr. Kurzer Test klappte zwar, weiß aber nicht, ob man sich dadurch ggf. das Board zerschießt. Aber ein Backup sollte man so oder so bei solchen Aktionen vorher anlegen. :)

  • Und mit einer WHERE Bedingung erspart man sich den sinnlosen Updateversuch bei allen anderen Einträgen:


    SQL
    UPDATE `table_xyz` SET `field_xyz` = REPLACE(`field_xyz`, 'example.com', 'example.org') WHERE `field_xyz` LIKE '%example.com%';

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • SQL
    UPDATE `wbb1_post` SET `message` = REPLACE(`message`, 'allaboutsims.net', 'allaboutsims.de') WHERE `message` LIKE '%allaboutsims.net%';


    Das betrifft dann aber nur die Beitragstexte. Thementitel oder z.B. PMs müsste man, falls Bedarf besteht, mit einer weiteren Abfrage bearbeiten.

  • Durch die Where-Bedingung kann er von vornherein nur die Einträge raussuchen die auch den Text überhaupt beinhalten.

    Ob das jetzt überhaupt tatsächlich einen Vorteil bringt ist imho aber zweifelhaft. Der Optimizer wird evtl. dafür sorgen nur die Texte zu nehmen die überhaupt die Replace-Bedingung treffen können...


    Da müsste man also tiefer forschen :)

  • Manchmal macht es aber durchaus Sinn die längere Variante zu bevorzugen wenn die Intentionen dadurch klarer werden.


    In C macht es auch Sinn den Programmcode ausführlicher zu machen, damit er leichter gelesen werden kann - der Compiler kümmert sich drum sinnlose Redundanzen zu entfernen.


    Um das ganze aber mal zu untermauern, hab ich kurz getestet.


    -> Das ist natürlich nur eine Momentaufnahme, aber es sieht so aus als sei das überprüfen auf die Where-Bedingung tatsächlich aufwendiger als simpel den Update immer zu versuchen. Die Unterschiede sind aber so gering dass es wohl keinen wirklichen Unterschied macht...

  • @ThomasChr Auch wenn es bei solchen Spalten unwahrscheinlich ist, dass es so etwas gibt: Setz mal einen Index drauf und teste es nochmals. Würde mich interessieren, ob es sich dann gleich verhält.



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Ich ging aber auch ursprünglich davon aus, dass mySQL die Query bereits intern optimiert und hatte mich daher anfangs auch für die kürzere Variante ohne where-Zusatz entschieden. Eine kurze Recherche dazu ergab allerdings kein Ergebnis. Würde mich nun auch mal interessieren, ob in diesem Fall tatsächlich ein Performanceunterschied feststellbar wäre. Vor allem in Hinblick auf größere Datenmengen. :D

  • KB19 Ein schneller Test zeigt dass es mit dem Index sogar deutlich langsamer ist:

    Ohne Index: 3.53s

    Mit Index: 11.68s


    Der Unterschied ergibt sich dadurch dass der Index beim Update natürlich auch mit geschrieben werden muss. Somit sind es nicht 236936 Blöcke die auf die Platte geschrieben werden müssen, sondern 685584.


    Read-IO haben wir in beiden Fällen nicht gehabt da ich diesmal auf das Neustarten verzichtet habe.


    Ist in diesem Fall sind übrigens alle Test mit InnoDB gemacht. Scheinbar der Default bei MariaDB.

  • Sauberer auf keinen Fall.

    Längerer Query-String, Redundanz.


    Da beides gleich gut performt, ist definitiv die kürzere Variante zu bevorzugen.

    Es sieht nur so aus, als würde es gleich gut performen. Ohne die Where-Klausel wird jeder Datensatz in die Datenbank zurückgeschrieben, mit dem where nur, wenn auch ein Treffer stattgefunden hat. Bei den Datenmengen, über die hier geredet wird fällt das zeitlich nicht ins Gewicht, aber bei richtig großen Datenbanken (noch weit unterhalb von Big-Data) macht das durchaus einen Unterschied. Das IO teuer ist, lässt man die Where-Klausel nie weg. BTW, wegoptimieren lässt sich das Schreiben nur unter bestimmten Bedingungen, und nicht jede Datenbankengine tut es. Siehe z. B. SQL-Server.