5
SQL Dubletten löschen
Hallo zusammen,
ich suche nach einer Möglichkeit Dubletten in einer Datenbank zu löschen.
Mit folgendem Query lasse ich mir die Dubletten auflisten:
select filename, count(filename)
from `Tab1`
group by filename
having count(filename) > 1
Nun möchte ich diese löschen, sodass jeweils nur ein Eintrag bestehen bleibt.
Hat jemand eine Idee wie ich das anstellen könnte??
Grüße, fdisk
ich suche nach einer Möglichkeit Dubletten in einer Datenbank zu löschen.
Mit folgendem Query lasse ich mir die Dubletten auflisten:
select filename, count(filename)
from `Tab1`
group by filename
having count(filename) > 1
Nun möchte ich diese löschen, sodass jeweils nur ein Eintrag bestehen bleibt.
Hat jemand eine Idee wie ich das anstellen könnte??
Grüße, fdisk
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 102793
Url: https://administrator.de/contentid/102793
Ausgedruckt am: 26.11.2024 um 14:11 Uhr
5 Kommentare
Neuester Kommentar
Moin fdisk,
gehe ich Recht in der Annahme, dass wir gerade von einer Tamagochi-Enterprise-Datenbank sprechen in der aktuellen Version 8.5a?
Gibt es noch weitere Felder außer dem Filetnamen in Deiner Kochrezepte-Tabelle?
Wenn ja, ist es wurscht, welcher Satz gelöscht wird oder gibt es einen bestimmten, der erhaltenswerter ist als alle anderen Dubletten?
Menno, macht doch bitte nicht immer so eine Geheimniskrämerei aus Euren Anforderungen...
Wie soll denn jemand eine passende Antwort posten bei diesem windelweichen Geseiere?
Grüße
Biber
gehe ich Recht in der Annahme, dass wir gerade von einer Tamagochi-Enterprise-Datenbank sprechen in der aktuellen Version 8.5a?
Gibt es noch weitere Felder außer dem Filetnamen in Deiner Kochrezepte-Tabelle?
Wenn ja, ist es wurscht, welcher Satz gelöscht wird oder gibt es einen bestimmten, der erhaltenswerter ist als alle anderen Dubletten?
Menno, macht doch bitte nicht immer so eine Geheimniskrämerei aus Euren Anforderungen...
Wie soll denn jemand eine passende Antwort posten bei diesem windelweichen Geseiere?
Grüße
Biber
Moin Biber,
es handelt sich um eine mysql DB V5.0. NAtürlich gibt es noch weitere Felder - Artistname, ID3-Tag, coverlink etc....
Welcher der doppelten Einträge am Ende bestehen bleibt ist wurscht, da sie ja identisch sind.
Danke...
es handelt sich um eine mysql DB V5.0. NAtürlich gibt es noch weitere Felder - Artistname, ID3-Tag, coverlink etc....
Welcher der doppelten Einträge am Ende bestehen bleibt ist wurscht, da sie ja identisch sind.
Danke...
Moin fdisk,
hmmm, mit wirklich vollständig redundanten Dubletten habe ich eigentlich nicht gerechnet.
Okay, dann muss natürlich jetzt von mir die Nachfrage kommen:
Hey, wozu willst Du die denn jetzt Unique/eindeutig machen, wenn die Tabelle doch offensichtlich keinen identifizierbaren Primary Key hat? Ohne Eindeutigkeit/ohne PK hast Du doch übermorgen wieder "doppelte" Datensätze??
Wozu dann überhaupt der Aufwand mit einer Datenbank....
Excel, Calc oder eine große Holzkiste wären für die Datenhaltung genauso sinnvoll und wesentlich fehlertoleranter.
Egal, die beiden einfachsten Varianten unter diesen merkwürkdigen Bedingungen:
a) mit gleicher TabStruktur
b) weil Variante a) ja nach 2 tagen wieder Duplikate enthalten wird ohne PK:
--> ich würde ein AUTO_INCREMENT-Feld whateverID anfügen als PK.
Da dafür ein Zahlenwert automatisch vergeben wird, kannst Du das in eine neueTabelleMitPK reintrümmern.
P.S. Weil ich immer noch irgendwie am Kopfschütteln bin - das bring es alles nicht...
Du musst doch irgendwie verbal beschreiben können, was für Dich "gleiche" und was "unterschiedliche" Sätze sind, die Du in Deiner Tabelle sammelst....
Bist Du sicher, dass Du auf dem richtigen Weg bist?
Grüße
Biber
hmmm, mit wirklich vollständig redundanten Dubletten habe ich eigentlich nicht gerechnet.
Okay, dann muss natürlich jetzt von mir die Nachfrage kommen:
Hey, wozu willst Du die denn jetzt Unique/eindeutig machen, wenn die Tabelle doch offensichtlich keinen identifizierbaren Primary Key hat? Ohne Eindeutigkeit/ohne PK hast Du doch übermorgen wieder "doppelte" Datensätze??
Wozu dann überhaupt der Aufwand mit einer Datenbank....
Excel, Calc oder eine große Holzkiste wären für die Datenhaltung genauso sinnvoll und wesentlich fehlertoleranter.
Egal, die beiden einfachsten Varianten unter diesen merkwürkdigen Bedingungen:
a) mit gleicher TabStruktur
INSERT INTO neuetabelle (filename, Artistname, ID3Tag, coverlink, etc)
SELECT DISTINCT filename, Artistname, ID3Tag, coverlink, etc
FROM tabelle;b) weil Variante a) ja nach 2 tagen wieder Duplikate enthalten wird ohne PK:
--> ich würde ein AUTO_INCREMENT-Feld whateverID anfügen als PK.
Da dafür ein Zahlenwert automatisch vergeben wird, kannst Du das in eine neueTabelleMitPK reintrümmern.
--anderen Code brauchen wir nicht, Statement bleibt wie oben)P.S. Weil ich immer noch irgendwie am Kopfschütteln bin - das bring es alles nicht...
Du musst doch irgendwie verbal beschreiben können, was für Dich "gleiche" und was "unterschiedliche" Sätze sind, die Du in Deiner Tabelle sammelst....
Bist Du sicher, dass Du auf dem richtigen Weg bist?
Grüße
Biber
Hallo Biber,
erstmal danke für Deine Antwort.
Ich versuche mal die Problematik zu beschreiben.
Es gibt einen Online Radiosender der mehrere Channel betreibt. Bislang war es so, dass ein Track in unterschiedlichen Shows/Channeln lief - es gab also auch ein Feld names channel. bspweise lief track1.mp3 in allen vier channeln und war also 4x in der DAtenbank vorhanden, was natürlich blödsinn ist. Das Feld channel wurde nun auch rausgeschmissen, sodass nun 4x mal dieser Eintrack track1.mp3 vorhanden ist der bis auch das Feld channel (was es ja nun nicht mehr gibt) exakt identisch ist. in Zukunft wird natürlich darauf geachtet, dass es keine redundanten Einträge mehr geben wird.
Ich bin wirklich nicht fit in der Materie, meine Aufgabe ist nur mich um die Dubletten zu kümmern. Wenn ich das alles recht verstehe, dann sollte der filename in Zukunft der PK sein!?
Grüße, fdisk
erstmal danke für Deine Antwort.
Ich versuche mal die Problematik zu beschreiben.
Es gibt einen Online Radiosender der mehrere Channel betreibt. Bislang war es so, dass ein Track in unterschiedlichen Shows/Channeln lief - es gab also auch ein Feld names channel. bspweise lief track1.mp3 in allen vier channeln und war also 4x in der DAtenbank vorhanden, was natürlich blödsinn ist. Das Feld channel wurde nun auch rausgeschmissen, sodass nun 4x mal dieser Eintrack track1.mp3 vorhanden ist der bis auch das Feld channel (was es ja nun nicht mehr gibt) exakt identisch ist. in Zukunft wird natürlich darauf geachtet, dass es keine redundanten Einträge mehr geben wird.
Ich bin wirklich nicht fit in der Materie, meine Aufgabe ist nur mich um die Dubletten zu kümmern. Wenn ich das alles recht verstehe, dann sollte der filename in Zukunft der PK sein!?
Grüße, fdisk
Moin fdisk,
Wenn also gewährleistet ist, dass Du anhand des "filename" unterscheiden kannst, dass es sich beim Track "Alles Gute zum Geburtstag" um die Version von Motörhead oder die Version von Xavier Naidoo handelt und ob es sich um die Liveversion des Wülferoder Bahnhofskonzerts oder die jugendfreie Studioversion handelt...
---> dann ist "filename" als natürlicher PK ausreichend.
Wenn es mehrere gleiche "filenames" geben könnte mit eigentlich unterschiedlichen Inhalten/Bedeutungen, dann wird es wahrscheinlich auf eine Kombination von "filename" und "filezize" oder sogar auf so etwas wie die Checksum des gezogenen mp3s herauslaufen.
Der "filename" wäre mir vor allem deshalb zu unsicher, weil Du darauf vertrauen müsstest, dass dieser immer gleich (z.B. nicht mal mit Umlauten und mal ohne) geschrieben sein wird.
Oder eben überhaupt immer gleich bzw. richtig. Da hätte ich meine Zweifel.
Denn soweit ich weiß, hat zwei Drittel der PISA-Generation massive Rechtschreibprobleme.
Und die übrigen 40% können nicht richtig rechnen.
Grüße
Biber
Wenn ich das alles recht verstehe, dann sollte der filename in Zukunft der PK sein!?
Der PK sollte IMHO die Kombination aus denjenigen Attributen sein, die diesen Eintrag für Deine Betrachtung als "eindeutig" oder "doppelt" beschreiben.Wenn also gewährleistet ist, dass Du anhand des "filename" unterscheiden kannst, dass es sich beim Track "Alles Gute zum Geburtstag" um die Version von Motörhead oder die Version von Xavier Naidoo handelt und ob es sich um die Liveversion des Wülferoder Bahnhofskonzerts oder die jugendfreie Studioversion handelt...
---> dann ist "filename" als natürlicher PK ausreichend.
Wenn es mehrere gleiche "filenames" geben könnte mit eigentlich unterschiedlichen Inhalten/Bedeutungen, dann wird es wahrscheinlich auf eine Kombination von "filename" und "filezize" oder sogar auf so etwas wie die Checksum des gezogenen mp3s herauslaufen.
Der "filename" wäre mir vor allem deshalb zu unsicher, weil Du darauf vertrauen müsstest, dass dieser immer gleich (z.B. nicht mal mit Umlauten und mal ohne) geschrieben sein wird.
Oder eben überhaupt immer gleich bzw. richtig. Da hätte ich meine Zweifel.
Denn soweit ich weiß, hat zwei Drittel der PISA-Generation massive Rechtschreibprobleme.
Und die übrigen 40% können nicht richtig rechnen.
Grüße
Biber
