Text sucherei

[Gruber_Hans_12345]

Hallo

foglendes Problem, ich habe eine DB wo ich Strings drinnen stehen habe die auch umlaute habe, diese sind als "normale" Varchar ohne COLLATE usw angelegt, und das kann ich auch nicht so schnell ändern.

Nun muß ich in diesen Feldern suchen

ein
WHERE UPPER(BEZEICHNUNG) LIKE '%TEST%';
funktioniert

nur was nicht funktioniert ist wenn im Suchtext ein umlaut drinnen ist, da ja das UPPER aus "testäödr" ein "TESTäöDR" macht.

was funktioniert wäre ja folgendes

Code:

UPPER(CAST(BEZEICHNUNG AS BLOB CHARACTER SET ISO8859_1) COLLATE DE_DE) LIKE '%TEÖÄ%'

nur das problem ist, das es so grotten langsam ist, dauert statt noramlerweise 2 Sekunden, 4 Minuten

Habe ich da noch eine andere möglichkeit?

[tsteinmaurer]

Hallo,

* Mit welchem Zeichensatz wurde die Datenbank erstellt?
* Von welchem Typ ist BEZEICHNUNG?
* Mit welchem Zeichensatz wurde BEZEICHNUNG erstellt?
* Mit welchem Zeichensatz verbindest du dich zur Datenbank?

[Gruber_Hans_12345]

Also ich suche in zwei Feldern

BEZEICHNUNG VARCHAR(200)
BESCHREIBUNG BLOB SUB_TYPE TEXT

Zeichensatz wurde weder beim erstellen der DB noch bei den Feldern was eingestellt (Wie und wo kann ich da nachschauen, was da drinnensteht)
es ist einfach ein gewachsenes System, daher sind änderung nur sehr sehr schwer durchzuführen ;) (Oder auch verbesserungen ;) )

[Gruber_Hans_12345]

so das hier meinst oder?

Code:

CREATE DATABASE 'test.fdb' PAGE_SIZE 8192
 DEFAULT CHARACTER SET NONE                                                                                         


CREATE TABLE "ARTIKEL" 
(
  "ID"   INTEGER NOT NULL,
  "BEZEICHNUNG"   VARCHAR(200),
  "BESCHREIBUNG"   BLOB SUB_TYPE 0 SEGMENT SIZE 80
);

[tsteinmaurer]

Zitat:

Zeichensatz wurde weder beim erstellen der DB noch bei den Feldern was eingestellt (Wie und wo kann ich da nachschauen, was da drinnensteht)

Schlecht, weil dann läuft alles im Kontext von NONE. Im Prinzip akzeptiert hier Firebird alles, ohne dabei irgendwelche Überprüfungen im Kontext des verwendeten Zeichensatzes durchzuführen inkl. weiss Firebird hier dann eben nicht was mit Umlauten etc. zu tun ist. Ganz vereinfacht dargestellt.

Kurzfristig kann man sich mit den unterschiedlichen CASTs drüberhelfen, aber das ist längerfristig keine Option. LIKE '%...%' würde dir zwar eh keinen Index verwenden, aber z.B. bei LIKE '...%' auf einem VARCHAR sehr wohl, allerdings wird das durch ein CAST mit COLLATE etc. wieder ausgehebelt und es wird somit kein Index verwendet.

Ich befürchte, längerfristig solltet ihr eine Migration auf einen Zeichensatz eurer Anforderungen entsprechend anstreben.

[Gruber_Hans_12345]

Hmmm, auf was soll man da dann migrieren, ich habe ja das problem, das die gleiche datenbank ja auch in anderne ländern funktionieren sollte (Also Tschechei, Ungarn, Slowakei, Serbien ... )
ich hatte bis vor kurzen eine "Lösung" indem ich eine UDF Funktion gemacht habe, die halt ein ANSIUPPERCASE macht aber das problem war halt das diese UDF halt wieder bestimmte anzahl von zeichen zurückgeben muß

Das COLLATE ist so langsam das ich es wieder rausgeben mußte ...

Siehst du einen kurzfristigen weg, mit dem man das lösen kann OHEN die Db anzugreifen (ich möchte nun ungern über 100 DB's umändern ... )
vorrangig geht es mir nur um die äöü die ich mit dem UPPER nicht schaffe...

[Blup]

Alle Kombinationen der Umlaute angeben:

Code:

WHERE (UPPER(BEZEICHNUNG) LIKE '%TESTäöDR%') or
      (UPPER(BEZEICHNUNG) LIKE '%TESTÄöDR%') or
      (UPPER(BEZEICHNUNG) LIKE '%TESTäÖDR%') or
      (UPPER(BEZEICHNUNG) LIKE '%TESTÄÖDR%');

In der Regel werden höchstens 1 bis 2 Umlaute im Suchtext sein.
Sind mehr als 3 enthalten, würde ich den Suchtext nach dem 3. Umlaut einkürzen.

[tsteinmaurer]

Zitat:

Hmmm, auf was soll man da dann migrieren, ich habe ja das problem, das die gleiche datenbank ja auch in anderne ländern funktionieren sollte (Also Tschechei, Ungarn, Slowakei, Serbien ... )

Naja, mit Unicode wärst halt auf der sicheren Seite. Aber damit das Sinn macht, muss auch die Client-Anwendung, Delphi etc. mitmachen.

Zitat:

Das COLLATE ist so langsam das ich es wieder rausgeben mußte ...

Du könntest mal versuchen den CAST im Falle von BEZEICHNUNG nicht auf einen BLOB sondern auf einen VARCHAR zu machen. Vielleicht hilft das bzgl. Performance. Ein Index wird dir da aber nie verwendet werden.

Zitat:

Siehst du einen kurzfristigen weg, mit dem man das lösen kann OHEN die Db anzugreifen (ich möchte nun ungern über 100 DB's umändern ... )

Ehrlich gesagt keinen Vernünftigen. Haben sich deine Kunden noch nie beschwert, dass z.B. auch die Sortierung nach Textfeldern eine Katastrophe ist?

[Iwo Asnet]

Wieso baut man sich dafür keine UDF?

SQL-Code:

WHERE UDFMatches(Field,'%Sörtschtäxt%')

[Gruber_Hans_12345]

Das mit der sortierung ist unsofern "kein Problem", da dies der Client erledigt.

Das mit dem UDF Match wäre sicher mal ne interessante lösung, brauche zwar dann zwei (einmal varchar und einmal blob)

gibt es irgendwo ein tutorial wie ich die Datenbank von meinem NONE CHARSET in ein vernünftiges (passt dieses ISO8859_1) wandeln kann?

[tsteinmaurer]

Zitat:

passt dieses ISO8859_1

Dies läßt mich darauf schließen, dass du dich noch nicht wirklich mit Firebird-Zeichensätzen auseinandergesetzt hast? Mit ISO8859_1 kannst du Probleme bekommen, weil du ja auch Tschechien bedienen mußt. Würde mal vorschlagen dir Stefan's Seite anzusehen: http://www.destructor.de/charsets/index.htm bzw. auch seine Konferenz-Talks zu diesem Thema: http://www.destructor.de/talks/index.htm. Ein Verständnis über Zeichensätze sind IMHO genau so wichtig, wie die Kenntnis über die Syntax einer FOR-Schleife. Die Zeit ist gut investiert!

Zitat:

gibt es irgendwo ein tutorial wie ich die Datenbank von meinem NONE CHARSET in ein vernünftiges (passt dieses ISO8859_1) wandeln kann?

Der offizielle Weg ist:
* Datenbankstruktur in ein Skript-File extrahieren
* Alle Zeichensatz-relevante Informationen mit dem neuen Ziel-Zeichensatz anpassen
* Datenbank über das Skript neu erstellen
* Datensätze transferieren

Der inoffizielle Weg wäre ev. über Systemtabellen-Updates, aber da spielt man mit dem Feuer.

Der offizielle Weg hat allerdings einiges an Automatisierungspotential, d.h. je nach Datenbankgröße würde ich auch nicht vor 100 Datenbanken zurückschrecken. Solltest hier technische Unterstützung benötigen, siehe http://www.delphipraxis.net/169151-b...it-delphi.html

[himitsu]

Alternativ könnte man auch ein Backup machen (z.B. als SQL-Datei mit vielen INSERTs exportieren, aber ohne Datenbankstrukturen)
und dann die DB platt machen, neu aufbauen, mit den richtigen Charsets und das Backup wieder einspielen.

Zitat:

SQL-Code:

UPPER(BEZEICHNUNG) LIKE '%TESTäöDR%'

Einige DBMS kennen auch sowas wie ein ILIKE (caseinsensitives LIKE)
und vom MySQL kenn ich caseinsensitive Tabellenfelder, bzw. caseinsensitive CharSets oder wie das nochmal genau aussah, wo der Index caseinsensitiv ist und wo dann auch caseinsensitiv gesucht wird.