Ich hab ein relativ spezielles Problem mit SQLite3:
Ich hab einen Join Table mit folgenden Spalten:
ID_1(INTEGER), ID_2(INTEGER), RELATION_DESCRIPTION(TEXT)
Nun kann es passieren, weil mir jedesmal ausprobieren zuviel performance raubt, das es zwei Rows mit gleicher ID_1 und ID_2 gibt.
Diese sind redundant und ich würde gerne eine davon löschen. Welche ist mir egal.
Ich kenne verschiedene Möglichkeiten Rows zu löschen, aber keine davon passt auf meine spezielle Situation.
Internetsuche war auch negativ, obwohl ich glaube die Situation relativ häufig ist.
Es existiert eine Table mit der Spalte NAME. Wenn NAME in dieser Table doppelt/Duplikat vorkommt, wird das Duplikat gelöscht, welches die größere ID hat (neuer).
Bei zwei Tables müsste das genauso funktionieren. In der sub selection dann einfach auf die zweite Table durchführen.
Die Spalte/Attribut NAME ist natürlich nur eine Art „Stellvertreter“ (für RELATION_DESCRIPTION?).
Da das DELETE ziemlich hart ist, vielleicht erst mal durch ein SELECT ersetzen.
Das glaube ich nicht. Dein DB-Design ist kaputt. Du hättest bei der Definition der Beziehungstabelle entweder einen Primary Key oder einen Unique Index über die Spalten ID_1 und ID_2 legen sollen.
Nun ist das Kind in den Brunnen gefallen. Mit den drei Spalten Deiner Tabelle sehe ich auch keine Möglichkeit, ein Statement zu bauen, dass nur eine Zeile löscht, die andere aber stehen lässt. Evtl. hilft hier sowas wie Row-ID weiter. Kenne SQLLite aber nicht, um das sicher sagen zu können. Darum nur als Anregung für weitere Suche.
Ansonsten empfehle ich die Definition einer neuen Beziehungstabelle (diesmal mit PK oder Unique Index). Die befüllst Du mit den Inhalten der alten. Mache hierfür ein SELECT DISTINCT … auf der alten Beziehungstabelle. Dann hast Du in der Ausgabe die Dubletten weg.
Das Kind ist zwar schon in den Brunnen gefallen, aber ich hab es extra getestet, mit zwei Spalten:
[SQL]CREATE TABLE IF NOT EXISTS JoinTable (ID_1 INTEGER, ID_2 INTEGER, REL_DES TEXT);
INSERT INTO JoinTable VALUES (1,3,‚drei‘),(2,2,‚eins‘),(3,3,‚zwei‘),(1,3,‚vier‘);
SELECT * FROM JoinTable;
SELECT * FROM JoinTable a WHERE EXISTS (SELECT REL_DES FROM JoinTable b WHERE a.ID_1 = b.ID_1 AND a.ID_2 = b.ID_2 AND a.REL_DES > b.REL_DES);
/*
liefert 1|3|vier
*/
DELETE FROM JoinTable WHERE EXISTS (SELECT REL_DES FROM JoinTable b WHERE JoinTable.ID_1 = b.ID_1 AND JoinTable.ID_2 = b.ID_2 AND JoinTable.REL_DES > b.REL_DES);
/*
deletet 1|3|vier
*/
SELECT * FROM JoinTable;[/SQL]
Funktioniert einwandfrei,
löscht diejenige doppelte Row,
deren Beschreibung größer ist.
[quote=CyborgBeta]Funktioniert einwandfrei,
löscht diejenige doppelte Row,
deren Beschreibung größer ist.[/quote]
Und was, wenn beide Beschreibungen gleich sind? Glaube nämlich nicht, dass IDC die Schwierigkeiten sonst hätte.
Naja, dann sind alle 3 Attribute gleich und SQL kann nicht entscheiden, welche gelöscht werden soll. Ist das in SQL überhaupt möglich? Workaround: Dann 4 Spalte hinzufügen.
Ja, das ist ziemlich präzise das Problem…
Ich glaub ich mach mir dann eine neue Beziehungstabelle mit Primary Key wie nillehammer vorgeschlagen hat!
Fühlt sich für mich nur irgendwie nach überflüssigen Daten an, Primary Key in Join Table
[quote=IDC]Ich glaub ich mach mir dann eine neue Beziehungstabelle mit Primary Key wie nillehammer vorgeschlagen hat!
Fühlt sich für mich nur irgendwie nach überflüssigen Daten an, Primary Key in Join Table[/quote]
Dein “Unbehagen” kann ich schon nachvollziehen. In einer Beziehungstabelle hat man ja keine echten Entitäten, die über einen Primärschlüssel identifiziert werden. Aber man braucht halt etwas, um Dubletten zu vermeiden. Stell Dir deswegen die Join-Tabelle entweder als Entitäten vor, die die Description der Beziehung darstellen. Oder nutze Unique-Index über die beiden Spalten. Technisch läuft’s auf dasselbe hinaus. Von der Beschreibung Deiner Intention mag das evtl. gefälliger sein.
*** Edit ***
Und damit das nicht falsch verstanden wird. Der Primary Key/Unique Index soll über die beiden Spalten ID_1 und ID_2 definiert werden. Keine neue Spalte für den PK einführen. Das wäre überflüssig und würde das Problem für die Zukunft auch nicht lösen.
