Verschachtelte REPLACE-Funktion gesucht

Wie sieht denn deine Tabelle genau aus, was für einen PK hast du? Kannst du deine Tabelle erweitern um nicht gleich am Anfang die Bestandsdaten zu überschreiben?
 
Werbung:
Ich bin schon sehr dankbar, wenn ich ein Grundgerüst habe, den Rest biege ich dann schon hin.

Die Tabelle (tKunde) ist im Grunde so aufgebaut:

kKunde = primary Key

kKunde, cVorname, cNachname, CStrasse, cPLZ, cStadt
1, Max, Mustermann, Musterstraße 2, 55555, Musterstadt
2, Maximiliane, Musterfrau, Musterlestraße 2, 44444, Musterstädtle
 
Code:
Begin
--transaction code
End;
Meinst du sowas ?

Edit: Ich verstehe gerade nicht was du mit "SQL-File anstoßen" meinst... Und was gegen eine SP spricht...
 
Ich will mir ein Tool basteln "Batchfile + SQL-Script", das ich per Aufgabenplaner oder onDemand antriggern kann.

Die Datenbank sollte hierbei nachezu unverändert bleiben, sprich es sollen keine Vorarbeiten erforderlich sein bzgl. Funktionen implementieren.

Das SQL-Script soll somit Funktion und Aktion beinhaltet und gewissen Tabellen überarbeiten.

Aktuell läuft dies ja mit meinem verschachtelten REPLACE-Script, aber es ist einfach zu unübersichtlich geworden!

Was heißt PK und SP?
 
PK = Primary Key
SP = Stored Procedure

Ich wollte eigentlich wissen welches Format dein PK hat. Integer oder Unique Identifier?

Wenn du nichts an der DB ändern willst (keine SP, keine temp Tabelle, keine zusätzlichen Spalten) musst du allerdings Probleme in Kauf nehmen. Läuft dein Script in einen Fehler weißt du nicht wo. Du weißt auch nicht welche Datensätze schon verarbeitet wurden und musst alle erneut prüfen.
 
PK hat "bigint", lässt keine NULL zu und ist eine fortlaufende Zahl / hochzählende Nummer

Ich will leider möglichst nichts an Procedure ändern, nur Werte in Tabellen prüfen und ändern.

Probleme nehme ich in Kauf, da ich ohnehin immer nur einen X Bereich Tage überarbeite.

Hilft dir das?
 
Das ist eine simple Schleife die alle Datensätze durchläuft, beliebig viele Änderungen an cStrasse vornimmt, das dann wieder in die Tabelle schreibt und fertig.
Code:
DECLARE   @pk BIGINT,
     @pk_max BIGINT,
     @cStrasse VARCHAR(255)

SET     @pk = 1
SET     @pk_max = (   SELECT   max(pk)
           FROM   tabelle )

WHILE   @pk <= @pk_max
BEGIN
   SET     @cStrasse = (   SELECT   cStrasse
               FROM   tabelle
               WHERE   pk = @pk
   IF     @cStrasse IS NOT NULL
   BEGIN
     SET     @cStrasse = replace(cStrasse,'','')
     SET     @cStrasse = replace(cStrasse,'','')
--     ...
     UPDATE   tabelle
     SET     cStrasse = @cStrasse
     WHERE   pk = @pk
   END

   SET     @pk = @pk + 1
END
Wenn du die Datensätze eingrenzt kann man da noch viel an der Performance verbessern. Aber ohne in die Tabelle zu schreiben wo eine Überprüfung bereits statt gefunden hat wird das Script immer alles durchgehen müssen. Auch wird die Tabelle immer aktualisiert, sogar wenn eventuell gar keine Änderung erfolgt ist.

Dennoch ist das erstmal ein robuster Weg, ich weiß ja nicht wie oft das erforderlich ist.

PS: Du solltest die Daten vorher sichern.
 
Das ist wohl das unsauberste was ich bisher in diesem Forum gesehen habe... Da wäre sogar sowas schöner...:
Code:
UPDATE   tabelle
     SET     cStrasse = replace(...);
UPDATE   tabelle
     SET     cStrasse = replace(...);
UPDATE   tabelle
     SET     cStrasse = replace(...);
UPDATE   tabelle
     SET     cStrasse = replace(...);
UPDATE   tabelle
     SET     cStrasse = replace(...);
UPDATE   tabelle
     SET     cStrasse = replace(...);
....
 
Angenommen man hat entschieden dass sein PK immer mindestens 8 Stellig sein soll -> Du durchläufst 10 Millionen Leerläufe
Angenommen der PK hat Nummernkreise (8- Stellig für einfache IDs, 12 Stellig für besonders wichtige...) -> Du durchläufst die ersten 10 Millionen Leerläufe + ca. 99,9 Millionen Leerläufe bis du dann bei den 12-Stelligen anfängst...

Mal ganz von Performanceeinbußen von einer Schleife gegenüber eines einzelnen Update-Statements abgesehen...
 
Da der PK ein BIGINT ist der hochzählt dürfte es keine großen Lücken geben. Das Performance hier schlecht ist habe ich ja bereits geschrieben. Es ging mir nur darum eine einfache Schleife zu zeigen die ihre Aufgabe erledigt, die einfach zu handhaben ist und auf die man(sie) aufbauen kann.

Wenn diese Prozedur regelmäßig laufen soll würde ich viele Verbesserungen empfehlen, angefangen mit einem BIT das abgearbeitete Datensätze kennzeichnet. Nachteilig ist dann definitiv das die Erstellerin hier keine Änderungen an der DB (Prozedur, Trigger) und wohl auch keine neuen Spalten erstellen möchte.

Wenn es bei einer Schleife bleiben soll die jeden Datensatz der Reihe nach ändert (sonst könnte man in der Tat einzelne Update-Statements nehmen) würde ich auch Datensätze mit ROW_NUMBER() durchlaufen.
 
Das ist wohl das unsauberste was ich bisher in diesem Forum gesehen habe... Da wäre sogar sowas schöner...:
Code:
UPDATE   tabelle
     SET     cStrasse = replace(...);
UPDATE   tabelle
     SET     cStrasse = replace(...);
UPDATE   tabelle
     SET     cStrasse = replace(...);
UPDATE   tabelle
     SET     cStrasse = replace(...);
UPDATE   tabelle
     SET     cStrasse = replace(...);
UPDATE   tabelle
     SET     cStrasse = replace(...);
....

Danke für die Tipps, allerdings wäre ich mit der Methode wieder am Anfang, denn so habe ich es.
Da ich mehrere "verschachtelte" REPLACE habe, sieht das unübersichtlich aus.

Ich habe zB für cStraße nun 75 Korrekturen, dann muss ich also 150 Zeilen dazu schreiben :-D

Daher habe ichs verschaltet mit 75 REPLACES ineinander, aber lesbar ist das nicht.

Bin daher dankbar für etwas schlankes, übersichtliches, das die Performance auch nicht einbrechen lässt.
 
Das nützt mir aber nicht viel, ich wollte ja Codes in Form von Verschachtelung einsparen :-(

Gibt es überhaupt keine Möglichkeit???
 
Werbung:
Nein... An irgendeinem Punkt MUSST du alle Replace angeben... Du kannst nur bestimmen wo du das machst...

Das einzige was du noch ändern könntest wäre vllt. aus einer Spalte 3 zu machen (Straße, Hausnummer, Nummernzusatz).... Dann könntest du dir wohl ein paar Replace sparen...
 
Zurück
Oben