Datenbank Duplicates

[mkinzler]

Da ist aber der Weg über den Expression Index einfacher

[-187-]

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

[mkinzler]

Nein, werden sie wohl nicht. was aber geanu passiert, kann ich dir nicht sagen.

[TBx]

Zitat von -187-:

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

[idefix2]

Zitat:

Da ist aber der Weg über den Expression Index einfacher

Es kommt darauf an. Bei einer kleinen Anwendung mit nur einer derartigen Spalte und einer Abfrage ist das etwas einfacher - wobei ja eine case-insensitive Collation in einem einzeiler von einer case-sensitiven abgeleitet werden kann, also auch nicht sehr kompliziert ist.

Bei einer grösseren Anwendung, wenn man viele Datenbankfelder standardmässig case insentiv haben will, sollte man aber auf jeden Fall besser eine collation erstellen. Sonst muss man bei jeder SQL-Abfrage auf Gleichheit an das Uppercase denken. Prinzipiell sollte man beim Design einer Anwendung eher darauf schauen, möglichst viel Logik in die Datenbank-DLL auszulagern (Trigger, Collations, Calculated Fields, Views). Dann ist die Programmierung der Anwendungen nachher schneller und weniger fehleranfällig.