Sök+ersätt i SQL men utan att skapa dubletter

UPDATE YourTable
SET YourColumn = REPLACE(YourColumn, 'find_text', 'replace_text')
WHERE
    YourColumn LIKE '%find_text%'
AND NOT EXISTS (
    SELECT 1 FROM YourTable
    WHERE YourColumn = REPLACE(YourColumn, 'find_text', 'replace_text')
);

Du skulle nog kunna ta bort allt med ”and not exists”, vet inte riktigt vad för syfte den har?
Du har ju redan filtrerat ut alla du vill ändra på i din WHERE-sats.

En update gör som den säger, uppdaterar. Den skapar inga dubbletter . Den uppdaterar ju bara befintligt där den träffar.

Om du är rädd för att ändra data som du inte vill ändra, kan di förstås backuppa. Men annars kan du i en fråga hämta ut IDna för de rader du vill ändra . Typ ”select id from table where filtered like ’%findme%’”
Och sen tar du de IDna och trycker in i din where i replace satsen.

”Update table set foo=replace(…) where id in (dina idn här )”

Men det översta borde räcka för dig om jag förstår din fråga rätt 🙂

Problemet verkar ju vara att WHERE %find_text% ger falska positiva
Förslår du postar en bild

Om det är en prefix kör WHERE YourColumn LIKE 'find_text%' dvs bara 1 %

Det är svårt att förstå vad du menar utan att se data. Dörför blir det gissningar.

Jag tippar på att din WHERE NOT EXISTS är felformulerad. Du vill att den ska låta bli att ändra på de rader där du redan lagt till eller tagit bort ett ”prefix”, oklart vilket alternativ och oklart hur prefixet ser ut.

Men det den gör är att låta bli att agera i de tabeller där det finns någon rad alls där du redan gjort manövern. Om du har en vettig primary key[1] i tabellen, så väljer du att matcha på den också som extra villkor. Det är svårt/omöjligt att föreslå en konkret lösning utan att se tabelldefinition och helst också exempeldata.

Att du ens har problemet tyder på att databasen är feldesignad i betydelsen låg normaliseringsgrad. Återigen är det svårt att säga något bestämt, men texten bör antagligen ligga i en egen tabell och de andra tabellerna borde referera till den. Då hade ändringen inneburit att ändra en enda rad i en enda tabell. DRY.

[1] Nästan alltid är det bästa valet att låta PK vara en rent teknisk nyckel, ett auto-incrementat id-fält av ett stort heltal, alternativt en UUID/GUID, dvs i praktiken ett 128-bitars slumptal.