Datenbank Duplicates

[-187-]

Das war kein Push mir ist nur noch was eingefallen ...

Folgender Code ergibt 267 Duplicates auf 30000 Records.

Code:

'SELECT UPPER(VORNAME) FROM NAME GROUP BY UPPER(VORNAME) HAVING (COUNT(*)>1)'

Der Index besteht schon seit dem ersten Record.

Zitat:

Sollte es einen UNIQUE-Index auf dem Feld geben, wird es sicherlich keine Duplikate enthalten.

Es bringt nichts wenn du das in Frage stellst. Deswegen frage ich ja schließlich !

[fkerber]

Hi!

Du kannst innerhalb von 24h deine Beiträge editieren, um weitere Informationen hinzuzufügen.


Ich stelle nicht in Frage, ich stelle fest.
Und zwar: Wenn es einen UNIQUE-Index gibt, kann es keine Duplikate geben.


Sind Name und Vorname jetzt nur Platzhalter oder heißen Tabelle/Feld wirklich so?
Kannst du einen Dump der Tabelle mal anhängen?

Wie sehen diese Duplikate aus? Sind es wirklich "echte" Duplikate oder unterscheiden sie sich vllt. doch durch Groß/Kleinschreibung, sodass man vllt. dort den Fehler suchen sollte?


Grüße, Frederic

[mkinzler]

Zitat:

Das Feld Vornamen war nur ein Bsp. Genauso wie das "Namen"

In Wirklichkeit heißen meine Felder anders

Dann wäre es vielleicht ratsam, immer die selben "Tarnbezeichnungen" zu verwenden.
Hat die Tabelle noch mehr Felder?

[-187-]

Also die Tabelle sieht jetzt so aus:

Tabelle: Name
Field1: Vorname
Field2: Nachname
Field3: Telefon
Field4: Bewertung

Der Unique Index liegt auf "Nachname". Und die SQL Duplicate Abfrage auf "Nachname" ergibt ca 270 Duplicates. Warum sollte es ein groß-/kleinschreibungs Problem sein, schließtlich ist der Index CaseInsensitive!

[mkinzler]

Ich würde den UNIQUE Index eher über NAME und VORNAME legen, denn ein Nachname darf ja sicherlich öfters vorkommen ( wenn sich der Vorname unterscheidet).
Und was assiert, wenn 2 wirklich gleich heissen?

[TBx]

Zitat:

Zitat von -187- (Beitrag 1031011)

Angenommen ich füge diesen Index im nachhinein ein, werden dann die (jetzt neuen) Duplicates rausgeschmissen oder wie verhält sich das?

Nein, die Duplicates werden definitiv nicht rausgeschmissen. Abre Du kannst die DB dann nicht mehr backupen und restoren, beim restoren wird er die Dupes nicht mehr schreiben können, was zu inkonsistenten Daten führen könnte.

[-187-]

mkinzler Nachname wurde absichtlich als Unique ausgewählt, die Anforderung der Anwendung sind nunmal so. Hat auch relativ wenig mit dem Problem an sich zu tun ;)

Wie gesagt, ein INDEX besteht ja, aus welchem Grund kann ich den nicht für das Deleten der Duplicates verwenden?

[mkinzler]

Weil dieser nicht eindeutig zu sein scheint.

[idefix2]

Das Problem ist, dass Du dann alle Duplicates löschen würdest (dort, es Duplicates gibt, alle vorkommen, sodass keiner übrigbleibt), was Du wahrscheinlich auch nicht willst.

Wenn Gross-Kleinschreibung bei der Duplicates-Erfassung ignoriert werden sollen, soll sie mit ziemlicher Sicherheit in der Spalte generell ignoriert werden, auch bei Abfragen, die Dir später irgendwann in Deiner Anwendung einfallen. Deshalb ist unbedingt die Lösung mit Hilfe einer Collation der Lösung über einen Index vorzuziehen. Mit einem unique Index kannst Du zwar Duplikate verhindern, aber wenn Du später in Deinem Programm eine Abfrage auf Gleichheit, kleiner oder grösser brauchst, musst Du immer an das Upcase denken. Wenn die Spalte über die Collation caseinsensitiv defniert ist, sparst Du Dir das.

Es ist wirklich das einfachste, eine neue Tabelle zu machen, und die mit den alten Werten der alten Tabelle zu füllen. Wenn Du statt insert den Befehl update or insert ... matching eindeutigespalte verwendest und diese Spalte in der neuen Tabelle case-insensitiv ist, werden nur für die eindeutigen Felder Tabellenzeilen eingefügt - Was soll übrigens mit den anderen Tabellenspalten passieren? Die Werte die jetzt bei den Duplicates in den anden anderen Spalten stehen, gehen ja verloren, wenn die Duplicates rausfliegen.

[DeddyH]

Ich löse das immer old-fashioned-style: es gibt ein Feld Name und ein Feld Uppername. Auf Uppername liegt ein UNIQUE-Index und es wird in einem BI-/BU-Trigger befüllt (erst trimmen und dann in Großschreibung wandeln). Wenn ich das richtig gelesen habe, ist das zwar seit FB 2.1 nicht mehr notwendig, aber ich habe mich daran gewöhnt und es funktioniert zuverlässig.