Datenbank Duplicates

[-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 ):

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.