FB Suche laut DIN5007-2 (ä=ae)

[hoika]

Halo #,

ich suche eine Möglichkeit nach der Vorschrift DIN5007-2 zu suchen,
d.h.

Müller-Ölbrig
Müller-Oelbrig
Mueller-Ölbrig
Mueller-Oelbrig

sind identisch.
es gilt ä=ae, ö=oe, ü=ue.

Lokal geht es einfach über StringReplace und Uppercase,
aber direkt per Select * From Where ?.

Es geht hier wohlgemerkt nicht um Sortierung (LATIN II oder so ähnlich),
sondern um das suchen, Hinweise auf Collations und Charsets nützen mir also (wahrscheinlich) nichts.

Natürlich könnte ich auch alle möglichen Schreibweisen des Wortes ermitteln (so wie ich es ja oben schon gemacht habe)
und dann per IN suchen.

Mein aktueller Ansatz ist lokal zu suchen (es werden noch andere Felder im Where benutzt),
ist also kein Full-Table-Scan.

Ich könnte mir auch eine UDF bauen, das wollte ich allerdings vernmeiden.


Danke


Heiko

[mkinzler]

Sollte mit regulären Ausdrücken möglich sein.

[KarstenK]

Mein Vorschlag eine extra Spalte in der DB mit dem Inhalt Mueller-Oelbrig , also mit Umgewandelten Umlauten, anlegen und nur in der suchen.
Aternativw habe ich mal eine zweite Spalten mit dem phonetischen Code angelegt und auch darin gesucht. Findet dann auch Meier und Maier.

[Morphie]

Zitat:

Zitat von hoika (Beitrag 1210041)

Lokal geht es einfach über StringReplace und Uppercase,
aber direkt per Select * From Where ?.

Replace und Upper gibt es doch auch in Firebird-SQL...

Zitat:

Zitat von hoika (Beitrag 1210041)

Ich könnte mir auch eine UDF bauen, das wollte ich allerdings vernmeiden.

Aber der Anwendungsfall schreit ja förmlich nach einer UDF... ;-)

Zitat:

Zitat von KarstenK (Beitrag 1210044)

Mein Vorschlag eine extra Spalte in der DB mit dem Inhalt Mueller-Oelbrig , also mit Umgewandelten Umlauten, anlegen und nur in der suchen.

Das würde ich nicht machen... Stell dir vor irgendwann kommt man auf die Idee noch in 10 weiteren Feldern suchen zu wollen... willst du die dann alle redundant abspeichern?
Eventuell wäre der Umweg über eine Volltextsuche mit redundanten (umgewandelten) Einträgen besser...

[Furtbichler]

Zitat:

Zitat von Morphie (Beitrag 1210048)

willst du die dann alle redundant abspeichern?

Redundanz ist der Preis für Performance.

Zitat:

Eventuell wäre der Umweg über eine Volltextsuche mit redundanten (umgewandelten) Einträgen besser...

Da liegen die Texte auch redundant vor.

Wenn Firebird die DIN5007-2 Suche nicht anbietet, und man schnell suchen will, muss man wohl oder übel eine separate Spalte einführen, da die Lösungen mit UDF und RegEx keinen Index benutzen können.

[Morphie]

Zitat:

Zitat von Furtbichler (Beitrag 1210049)

Zitat:

Zitat von Morphie (Beitrag 1210048)

willst du die dann alle redundant abspeichern?

Redundanz ist der Preis für Performance.

Zitat:

Eventuell wäre der Umweg über eine Volltextsuche mit redundanten (umgewandelten) Einträgen besser...

Da liegen die Texte auch redundant vor.

Da hast du meine volle Zustimmung, allerdings würde man bei einer Volltextsuche nicht jede Spalte doppeln, sondern nur redundante (umgewandelte) Werte in den Volltextindex eintragen. Die Erweiterung auf weitere Felder wäre somit viel einfacher und vom Tabellenaufbau unabhängig / sinnvoller.

[Furtbichler]

Zitat:

Zitat von Morphie (Beitrag 1210053)

...allerdings würde man bei einer Volltextsuche nicht jede Spalte doppeln, sondern nur redundante (umgewandelte) Werte in den Volltextindex eintragen.

Wie? Nö. Die Spalte, so wie sie ist, kommt in den VT-Index. Natürlich wird hier verdichtet, d.h. mehrfach vorkommene Wörter werden nur einmal abgelegt.

Aber, wir sind uns einig: Eine Volltextsuche muß her!

[Morphie]

Ich setze eine Firebird-Volltextsuche immer so um, dass ich eine weitere Tabelle mit folgenden Feldern anlege:
ID
QuellTabelle
QuellFeld
QuellID
Wort

den eigentlichen Daten-Tabellen füge ich dann Trigger hinzu, die mir bei jeder Änderung/Neuanlage die entsprechenden Wörter aus allen relevanten Feldern in die Index-Tabelle schreiben.
Alternativ kann man auch einen Index-Dienst auf dem Server laufen lassen, der die Indizierung in einem x-beliebigen Intervall übernimmt... (hat einen Performancevorteil bei großen Batch-Imports)

So habe ich quasi für beliebig viele Tabellen mit beliebig vielen Spalten nur eine einzige Index-Tabelle mit der ich dann gezielt nach einzelnen Wort/Tabelle/Feld-Kombinationen suchen kann.

Ich bin sogar mal so weit gegangen, dass ich über die SYS$-Tabellen alle Textfelder für eine Tabelle abgefragt und diese automatisch indiziert habe. So muss man den Trigger bei neuen Textfeldern auch nicht mehr pflegen, da er sowieso alle Textfelder (Varchar, Char, Blob Text,...) indiziert.

Das Modell klappt bis jetzt ganz gut :-)

Wenn man den Trigger, der für die Indizierung zuständig ist, jetzt so manipuliert, dass er zusätzlich zu den normalen Wörtern auch alle umgewandelten Wörter indiziert, braucht man also keine redundanten Spalten anlegen und kann nach belieben nach Müller oder nach Mueller suchen

[Furtbichler]

Zitat:

Zitat von Morphie (Beitrag 1210060)

So habe ich quasi für beliebig viele Tabellen mit beliebig vielen Spalten nur eine einzige Index-Tabelle mit der ich dann gezielt nach einzelnen Wort/Tabelle/Feld-Kombinationen suchen kann.

Das wird aber bei großen Datenmengen sehr schnell zum Flaschenhals. Zudem ist das so nicht direkt ein Volltextindex, sondern nur eine Hilfe für eine Suche nach Token/Wörtern. Nicht schlecht, aber eben kein VT. Verwende deine Methode mal zum Indexieren von langen Texten (sagen wir: 1 Mio Dokumente)...

EDIT: Aber für diesen Zweck hier durchaus ausreichend... ;-)

Ich würde eine ausgereifte (Open Source?) Lösung nehmen. Beim Googeln habe ich einige Lösungen gesehen, die auf der Lucene-Engine basieren (die es auch für Delphi gibt): Das wäre in jedem Fall eine guter Anfang.

[Morphie]

Gut, damit habe ich noch keine Erfahrungen. Wie gesagt, bis jetzt reicht mir diese Lösung voll aus...