Datenbank Duplicates

[idefix2]

Ja, Du hast recht, so wie oben geschrieben geht es nicht. aber so:

SQL-Code:

select upper(ip_name) from musik
group by upper(ip_name) having count(*)>1

Das hab ich in meiner DB probiert, ip_name -> feld, musik -> tabelle

[-187-]

Hm wie es scheint bist du dem Problem auf die Schliche gekommen. Da ist die genau die Anzahl an Duplicates. Meine SQL Kenntnisse sind minimal. Was genau machen wir jetzt anders ? Wir selektieren alle UPPER CASE records die es öfter als einmal gibt. Wieso wurden die vorher nicht mit überprüft ? Oder macht das DBMS einen unterschied zwischen AAA und aaa ?

[mkinzler]

Natürlich besteht ein Unterschied zwischen 'AAA', 'aaa' und 'Aaa' usw. Willst das nicht musst du einen Expression-Index auf UPPER() anlegen ( geht ab FB 2.1)

[borwin]

Bei der Abfrage wird der Inhalt des Feldes genau überprüft. Dabei erflogt die Überprüfung Zeichenweise und ein 'A' ist dann etwas anderes als ein 'a'. Um das zu umgehen werden alle Zeichen auf UPPER gesetzt. Eine weitere Falle beim abfragen von Texten sind die Leerzeichen. Für die Datenbank ist 'MEIER' und 'MEIER ' nicht gleich. Um auch diesen Fall zu umgehen noch ein TRIM um die Felder legen.
Dann sieht das ganze dann so aus

Code:

SELECT TRIM(UPPER(ip_name)) 
FROM musik
GROUP BY TRIM(UPPER(ip_name)) 
HAVING COUNT(*)>1

Um das Einfügen von doppelten Datensätzen zu verhindern musst Du Deinen Index verändern.
Lege ein sogenantes COMPUTER BY Feld an mit Index an

Zitat:

create index idx_name on musik computed by (trim(upper(ip_name)));

Das verhinder schon doppelte Datensätze. Geht ab FB 2.0

Gruß Borwin

[-187-]

Hm borwin also doppelte Einträge bekomme ich nicht dank dieser Zeile:

IBTable1.AddIndex('UNIQUE', 'NAMES', [ixUnique, ixCaseInsensitive]); Ich glaube ich werde die strings bevor ich zu der DB hinzufüge einfach einmal vorbehandeln:


MyStr:= LowerCase(MyStr); Damit sollte das Problem endlich gelöst sein, Danke !

[idefix2]

Zitat:

Natürlich besteht ein Unterschied zwischen 'AAA', 'aaa' und 'Aaa' usw.

So natürlich ist es nicht. Wenn eine Collating Sequence für die Spalte angegeben ist, der Case-insensitiv ist, behandelt Firebird nach dem, was ich bis jetzt gelesen hat, unterschiedliche Case-Werte auch im Vergleich als identisch.

Die neusten Versionen von Firebird erlauben eigene Collating Sequences zu erstellen, wenn Du willst, dass Gross und Kleinbuchstaben in dem Feld als gleich behandelt werden, müsstest Du eine entsprechende Collating Sequence erstellen und bei dem Feld angeben.

[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.

[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.