Ganzes Wort suchen

[Sir Rufo]

Zitat von Bernhard Geyer:

Zitat von Sir Rufo:

Zitat von Jürgen Thomas:

Am sinnvollsten dürfte tatsächlich eine Nachfilterung per RegEx sein.

Wieso Nachfilterung, wenn Firebird das schon beherrscht?

Und mit welchem SQL? Dein Beispiel-SQL kann das nämlich nicht!

Anforderung:

Zitat:

nach einem ganzen Wort zu suchen.
Nur leider werden ja bei dieser Variante auch Ergbnisse angezeigt, wo der gesuchte Begriff innerhalb einer kompletten Zeichenkette steht.

habe ich das gesagt ... mir war so als ob ich (zu dem Beispiel-SQL) sagte ...

Zitat von Sir Rufo:

Und wenn nur die Groß-/Kleinschreibung egal sein soll, dann doch mit:
select * from tab where UPPER(field1)=UPPER('TRichEdit')

aber ich kann mich da ja auch irren ...

Das Zauberwort heißt "SIMILAR" und ist im SQL-99 definiert (siehe hier)

[Jürgen Thomas]

Zitat von Sir Rufo:

Das Zauberwort heißt "SIMILAR" und ist im SQL-99 definiert (siehe hier)

Schön und gut, aber wo und wie gibt es das in FB? Ich finde es weder in den FB-ReleaseNotes noch bei der IBExpert-Dokumentation.

Jürgen

[Sir Rufo]

Zitat von Jürgen Thomas:

Zitat von Sir Rufo:

Das Zauberwort heißt "SIMILAR" und ist im SQL-99 definiert (siehe hier)

Schön und gut, aber wo und wie gibt es das in FB? Ich finde es weder in den FB-ReleaseNotes noch bei der IBExpert-Dokumentation.

Jürgen

Da ich FireBird nicht einsetze habe ich mich auf das Firebird-Wiki verlassen

[nahpets]

Hallo,
@RWarnecke

Du baust da gerade etwas, was ich vor einiger Zeit gemacht habe, daher hier eine kurze Beschreibung meiner Lösung:

• Eine Tabelle für alle vorkommenden Wörter.
• Eine Tabelle für die Texte, in denen gesucht werden soll.
• Eine Tabelle, die diese 1:n-Beziehung auflöst.

Wenn ein Text gespeichert wird, so wird er in seine Wörter zerlegt, die Wörter werden (soweit nicht vorhanden) in die Worttabelle aufgenommen und die 1:n-Beziehung wird entsprechend ergänzt. Mehrfach im Text vorkommende Wörter werden natürlich nur einmal in die 1:n-Tabelle aufgenommen.

Damit muss beim Suchen nicht im SQL und/oder im Quelltext "herumgehampelt" werden, sondern die Abfrage kann über reines SQL erfolgen und ist durch die Benutzung des entsprechenden Index auch bei großen Datenmengen schnell, da Like und Co. entfallen können.

Als Schmakerl enthält die Worttabelle eine zusätzliche Spalte mit den Werten für die Kölner Phonetik, so dass auch nach (leichten) Unschärfen gesucht werden kann, ohne den Abfrageaufwand zu erhöhen. Durch das Parsen der Texte vor dem Speichern (Auflösung in Worte, Erstellung der Kölner Phonetik) dauert das Speichern geringfügig länger, aber der Vorteil für die Suche, sowohl bei den Inhalten als auch bei der Geschwindigkeit, macht diesen Aufwand locker wieder wett.

Ansonsten:

select * from tabelle where textspalte like '% :Suchwort %' Dabei muss die zu suchende Zeichenfolge alleine stehen.
Probleme:

• Erstes Wort im Text, da ein '% ' zuviel
• hinter dem Wort befindliche Satzzeichen.
• ggfls. letztes Wort, wenn kein Leerzeichen folgt.

[IBExpert]

Der Aufwand ist immer abhängig von der Datenmenge. Für eine 60GB Datenbank brauchst du andere Techniken als für eine 60 MB Datenbank.
Bei der kleinen reicht immer die Auswertung über integrierte Funktionen zu machen, da gibt es diverse Stringvergleiche
siehe hier: http://www.firebirdsql.org/refdocs/l...-position.html
Die Position Funktion ist case sensitive.

Das problem mit den trennzeichen kannst du serverseitig am besten so lösen, das du neben dem originaltext noch eine verdichtete version mit fixem Worttrenner schreibst, in dem alle sonderzeichendurch den trenner ersetzt werden und zum Beispiel nur noch A-Z und 0-9 vorkommen, dabei kannst du dann auch das verhalten für äöüß selbst festlegen (zum Beispiel ersetzen durch aeoeuesz oder einfach aous). Das kann dein client machen oder alternativ auch auf dem Server als service laufen. Das kann man dann auch für große Datenbanken (siehe oben) gut gebrauchen. Wenn es extrem schnell reagieren soll kann man das ganze noch in den Arbeitsspeicher packen, ist aber meist nicht notwendig.

Die Wortliste auflösen in Wort, Dokument, und WortDokument Tabelle hatten wir mal gemacht, da waren wir aufgrund der Datenmengen aber doch an Grenzen gekommen, die den Overhead nicht mehr rechtfertigen. Das ergibt bei größeren Datenbanken shcnell mal einige Milliarden Datensätze in der Verbindungtabelle.

Wir haben einfach die eindeutige Wortliste verdichtet und sortiert mit trenner im Extra Blob gespeichert.

beispiel:

SQL-Code:

original text:
Willkommen in der freundlichen Community rund um Embarcaderos/CodeGears Entwicklertool "Delphi". Unser Ziel ist es, eine Diskussionsplattform für den Gedankenaustausch zwischen Menschen zu schaffen, die sich beruflich oder privat mit Delphi befassen (müssen oder wollen *g*). In unserem Archiv mit über 965.000 Beiträgen findet sich für fast jedes Problem eine Lösung.

Verdichtung 1 für Wortreihenfolge casesensitive:
Willkommen#in#der#freundlichen#Community#rund#um#Embarcaderos#CodeGears#Entwicklertool#Delphi#Unser#Ziel#ist#es#eine#Diskussionsplattform#
für#den#Gedankenaustausch#zwischen#Menschen#zu#schaffen#die#sich#beruflich#oder#privat#mit#Delphi#befassen#müssen#oder#wollen#In#unserem#
Archiv#mit#über#965000#Beiträgen#findet#sich#für#fast#jedes#Problem#eine#Lösung#

Verdichtung 2 für wortexistenz non casesensitive mit ersetzung umlaute
965000#ARCHIV#BEFASSEN#BEITRAEGEN#BERUFLICH#COEDEGEARS#COEMMUNITY#DELPHI#DELPHI#DEN#DER#DIE#DISKUSSIOENSPLATTFOERM#EINE#EINE#EMBARCADEROES#
ENTWICKLERTOEOEL#ES#FAST#FINDET#FREUNDLICHEN#FUER#FUER#GEDANKENAUSTAUSCH#IN#IN#IST#JEDES#LÖSUNG#MENSCHEN#MIT#MIT#MUESSEN#OEDER#OEDER#PRIVAT#
PROEBLEM#RUND#SCHAFFEN#SICH#SICH#UM#UNSER#UNSEREM#WILLKOEMMEN#WOELLEN#ZIEL#ZU#ZWISCHEN#UEBER#

Das rechnet sich aber erst bei richtig großen Datenbanken, aber damit durchsuchen wir beim Kunden diverse Gigabyte und haben sehr schnell Ergebnisse.

[nahpets]

Hallo,

@IBExpert:

Die Idee gefällt mir, bei der Verdichtung 2 hätte ich aber noch die "Doppelten" entfernt und als dritte Verdichtung noch die Kölner Phonetik hinzugefügt. Das muss ich bei Gelegenheit mal direkt ausprobieren.

Wie sieht denn in euren Systemen das Mengengerüst aus, in der Zahl von Datensätzen, Wörtern... nicht unbedingt in MB oder GB? Wie groß sind die einzelnen Texte? Sind sie einsprachig oder müsst ihr da auch mit einem Gemisch verschiedener Sprachen in einer Tabelle/Datenbank bzw. in einem Blob zurechtkommen?

Und wenn man bei der Verdichtung 2 die Umlaute entfernt und bestimmte Wortendungen wegnimmt, dann könnte die Suche nach der Einzahl auch die Mehrzahl hervorbringen bzw. andersherum. Das wäre dann genau das, was ich brauche.

[IBExpert]

die doppelten sollten da eigentlich auch nicht mehr drin sein

Bei einer Kundendatenbank haben wir ca 5 Millionen Datensätze mit jeweils ca 800 Worten
80% deutsch, 10% englisch, 10 % sonstige Sprachen. Mit den verdichteten Varianten der Texte
für die Volltextsuche liegen wir da bei ca 60 GB Datenbankgröße, von den Tabellen wird
ca 50GB belegt, der rest sind andere Tabellen, Indexdaten etc.

Wenn du selbst den Verdichter programmierst hast du auch noch den Vorteil, dir jegliche
andere Variante da einzubauen. Wir haben zum Beispiel noch bestimmte tags automatisch
eingebaut, wie zum Beispiel #SPRACHE=DE#DATUM=20090921#, so kannst du über

... containing '#DATUM=2009'

zum Beispiel auf texte eingrenzen, die in 2009 geschrieben wurden, ohne mit anderen
Tabellen zu joinen, in denen natürlich das Datum auch noch steht, aber manchmal ist
eine globale Abfrage auf den Inhalten einfacher zu realisieren, ohne zum Beispiel
extract(year from datum). könnten ja auch andere Daten relevant sein,
Veröffentlichungsdatum, Änderungsdatum, Rechungsdatum Lieferscheindatum,
Patentanmeldungsdatum, ....

[nahpets]

Hallo IBExpert,

danke für die Antwort, Ihr scheint da ein richtig celveres System gebaut zu haben, höchst flexibel, wenn es um die Abfrage geht. Die Systematik ist einfach und beliebig ausbaubar. Das gefällt mir, die Ideen werde ich mir merken und bei Gelegenheit umsetzen.
Das sieht mir aus wie eine gezielte und äußerst sinnvolle Denormalisierung.

[IBExpert]

genau, und damit das Datenmaterial in der Menge beherrschbar bleibt auch komplett ohne XML, da wäre für das gleich Material statt 60GB mindestens 500GB in der Datenbank ohne für mich erkennbare Vorteile, aber mit deutlich langsamerer Reaktionszeit, weil der Zugriff über 500GB physikalisch nun mal langsamer ist als über 60GB.

Noch ein Tip: mach für jede Variante der Verdichtung eine eigene Tabelle und die Echtdaten in eine andere Tabelle. Wenn du zum Beispiel über ein indiziertes Feld der Haupttabelle bereits einschränken kannst, dann ist es oft performanter, die jeweiligen zusatztabellen erst dann für die noch überig gebliebenen Datensätzen einzubinden, wenn man die auch braucht. Das geht über Stored procs relativ simpel oder super dynamisch mit gleicher Syntax als Block.

sinngemäß

SQL-Code:

for select id,bla from hauptdatenmenge where .... into :idmain
do
begin
  select count(*) from verdichtung2 where id=:idmain and txt containing '#ABC#' and txt containing '#123#' into :cnt;  --sind beide worte enthalten?
  if cnt=1 then select count(*) from verdichtung1 where id=:idmain and txt not containing '#ABC#123#' into :cnt;       --dürfen aber nicht hintereinander stehen
  if cnt=1 then suspend;
end

der ganze innere teil kann dann dynamisch zusammengebaut werden für alle Kriterien, die dein User haben will. Wir haben das mal mit google syntax gebaut, ist ziemlich simpel und dem User angenehm einfach zu erklären. Lässt sich später auch gut skalieren, in dem man die Daten zum Beispiel auf mehrere Server oder Serverinstanzen verteilt und man die Abfragen einfach in eine Tabelle stellt und serverbasierende Dienste die Antworten dazu in die Datenbank schreiben. Ist bei der Datenmenge von Google sicherlich nicht ganz so schnell wie die, hat aber den vorteil, das auch die aktuellsten Einträge immer im Index sind, das kann google nämlich nicht (wir haben sowas auch schon speicherbasierend aufgebaut, aber da braucht man schon einen Server mit diversen Gigabyte RAM und diversen CPU Kernen, damit das deutlich schneller ist, aber machbar ist alles, und sogar mit Delphi Win32, Bei erreichen von 2GB splittet man einfach über mehrere Serviceprozesse).


[edit=mkinzler]SQL-Tag eingefügt Mfg, mkinzler[/edit]

[nahpets]

Hallo,

okay, so gigantisch brauche ich es nicht, aber euer Vorgehen zeigt, dass auch mit einfachen Mitteln immernoch hervorragende Systeme gebaut werden können. XML ist für mich bisher keine Alternative für irgendeine Form der Datenhaltung. Das ist meiner Meinung nach "Overhead" pur.