Wie kann ich doppelte Zeilen aus einer Tabelle löschen?
Hm, Du könntest eine neue Tabelle anlegen, die identisch ist mit der alten jedoch über allen Spalten einen unique-Index besitzt. Dann kopierst Du die komplette alte Tabelle in die neue Tabelle und ignorierst die Fehler. Damit hättest Du eine Tabelle, in der alle Zeilen aus der alten drin sind, aber nie doppelt.
unter ORACLE hätte ich folgenden, wenn wahrscheinlich auch nicht den elegantesten Vorschlag:
declare
cursor c_doppelt is
select rowid, name
from doppeltab;
begin
for rec_doppelt in c_doppelt loop
delete from doppeltab
where name = rec_doppelt.name
and rowid rec_doppelt.rowid
end loop;
end;
/
declare
cursor c_doppelt is
select rowid, name
from doppeltab;
begin
for rec_doppelt in c_doppelt loop
delete from doppeltab
where name = rec_doppelt.name
and rowid rec_doppelt.rowid
end loop;
end;
/
hm, cursor mit einem delete drinnen … naja … ein „delete from a where exists (select 1 from b where a.rownum != b.rownum and a.feld1 = b.feld1);“ würde doch auch reichen, oder?
hm, cursor mit einem delete drinnen … naja … ein „delete
from a where exists (select 1 from b where a.rownum !=
b.rownum and a.feld1 = b.feld1);“ würde doch auch reichen,
oder?
grüße,
tomh
Hi tomh,
ich sag ja: nicht gerade elegant und vor Allem nicht performant, da innerhalb der Loop u.U. n mal ein Full-Table-Scann durchgeführt wird.
Also nichts um das Ding 20 x am Tag laufen zu lassen. Aber ich vermute das jemand der doppelte DS in einer Tabelle hat daraus lernt und sich nach dem delete überlegt wie er das in Zukunft vermeiden kann.
Solche Sachen bieten sich aus meiner Sicht an, wenn man zusätzlich noch weitere Infos in einen Logfile/Logtable schreiben möchte.
war nur als „kürzerer“ vorschlag gedacht (mit änderungen in einem cursor hab ich äußerst schlechte erfahrungen (auf einer produktiv-db *argh*)
und vor Allem nicht
performant, da innerhalb der Loop u.U. n mal ein
Full-Table-Scann durchgeführt wird.
sowas nennt man dann „einen patch einspielen“, oder?
Also nichts um das Ding 20 x am Tag laufen zu lassen. Aber ich
vermute das jemand der doppelte DS in einer Tabelle hat daraus
lernt und sich nach dem delete überlegt wie er das in Zukunft
vermeiden kann.
ein typischer fall, in dem ein analyst ein „dieser fall wird nicht auftreten“ vorausschickt und das er-modell und db-design von den entwicklern im nachhinein umgekrempelt wird … (nur einmal möchte ich in einem projekt das „exact fetch returns more than one row“ NICHT sehen - es ist doch nicht so schwer, zumindest ein paar unique-keys zu definieren)
Solche Sachen bieten sich aus meiner Sicht an, wenn man
zusätzlich noch weitere Infos in einen Logfile/Logtable
schreiben möchte.