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.

[mkinzler]

Und die Anlage einer Collation ist hier wirklich mit Kanonen auf Fruchtfliegen schiessen

[-187-]

Also ich habe ja das Problem das ich Duplicates überhaupt erst hinzufüge bereits behoben. Es geht nur noch darum die vorhandenen zu entfernen.

Zitat:

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.

Das wäre in diesem Fall ok, ich würde danach einfach nochmal alle Daten hinzufügen. Wie würde der Command dafür aussehen ?

MFG


Edit: Ich habs nochmal getestet ! Trotz ixCaseInsensitive macht das DBMS Unteschiede zwischen Name, name, NAme und NAME ! Wie es scheint habe ich das falsch verstanden... Wofür ist ixCaseInsensitive dann gut ?

[idefix2]

alle Duplikate löschen müsste in etwa so gehen (ohne Garantie :wink:):

SQL-Code:

delete from tabelle t1 where (select count(*) from tabelle where upper(name)= upper(t1.name))>1

[mkinzler]

Es wurde dir doch schon der einfache Weg über die neue Tabelle gezeigt. was sprcht den dagegen dass du dich so vehement dagegen wehrst?

[idefix2]

Ich verstehe nicht, was an der Verwendung der für den Zweck geeigneten Collation "kanonenhaft" sein soll. Mit einer case-insensitiven Collation wird dem DBMS gesagt, dass in dieser Spalte die Gross/Kleinschreibung generell nicht berücksichtigt werden soll. Alles andere sind Workarounds, die nur mühsam sind und in der Folge immer wieder zu Fehlern führen werden, weil man leicht bei irgend einer Abfrage darauf vergessen kann. Je nachdem, welcher Zeichensatz verwendet wird, gibt es möglicherweise schon eine geeignete Collation, dann braucht man bei der Felddefinition nur "collate ..." hinzufügen. Wenn nicht, kann mit einem einzigen kurzen SQL Statement auf der Basis einer schon vorhandenen Collation eine case-insensitive erstellt werden und die dann verwendet werden.

Alles andere ist nicht weniger, sondern im Endeffekt mehr Aufwand.

Code:

Trotz ixCaseInsensitive macht das DBMS Unteschiede zwischen Name, name, NAme und NAME !

Womit der vorige Satz bestätigt wäre. Man kann sich natürlich jetzt damit spielen, zu suchen, wie das "ixcaseinsensitive" der KOmponente in der Datenbank umgesetz wird und warum es nicht so funktioniert, wie man sich vorstellt (Du kannst Dir ja mit irgend einem Tool anschauen, wie der Index aussieht, der auf die Art erzeugt worden ist.) - oder man macht es gleich so, dass es ohne weitere Geschichten funktioniert.

[mkinzler]

Zitat:

Ich verstehe nicht, was an der Verwendung der für den Zweck geeigneten Collation "kanonenhaft" sein soll.

Man kann bei einem Auto auch einen Bremsfallschrirm benutzer, auch wenn dies eine Bremse hat.
Neuere FB Versionen bieten die Möglichkeit expression indices anzulegen, bei älteren kann man eine "Schattenfeld" verwenden. Es gibt also keine Notwendigkeit eine eigene Sortierung zu implementieren.

Zitat:

Alles andere sind Workarounds, die nur mühsam sind und in der Folge immer wieder zu Fehlern führen werden,

Du findest also eine Funktion des DBMS ( expression index) als fehlerhaften Workaround und die Implementierung einer eigene collation als leichter? Was passiert wenn du vergisst diese mit auszuliefern oder bei deren Änderung diese mit auzuliefern? Bei einem Index ist der automatisch Teil der DB ( auch bei Schattenfelder, welche per Trigger ge"Upper"rt gefüllt werden, funktioniert es auf jeden Fall.

[idefix2]

Wenn Du eine eigene Collation "erstellen" müsstest, hättest Du Recht. Aber es geht ja ganz einfach, z.B.:

SQL-Code:

create collation collate_filename
    for ISO8859_1   <- verwendeter Zeichensatz
    from de_de      <- Basiscollation, aus der eine mit den gewünschten Eigenschaften gemacht wird
    case insensitive        
    accent sensitive;

Da brauchst Du nichts "erstellen" und schon gar nichts mit ausliefern, das ist ein ganz normales DDL Statement wie auch create table.
Der Vorteil ist, dass dann diese Collation auf den Feldwert standardmässig überall wirkt, wo das Feld angesprochen wird, und Du in weitere Folge nicht mehr daran denken musst. Ich verwende diese Collation zum Speichern von Dateinamen (im Windows system).

[mkinzler]

Bei einem expression index auch.

[idefix2]

Der Expression Index isrt NICHT das Feld. Wenn Du später irgendwo das Feld verwendest, darfst Du NIE auf das UPPER vergessen, und das sind mögliche Fehler von der Art, die extrem mühsam zu finden sind, weil sie sich u.U. irgendwo auswirken, wo man nicht damit rechnet.