none
Volltextsuche mit kurzen Zeichenfolgen RRS feed

  • Frage

  • Ich habe wenige kurze Worte bestehen nur aus zwei Buchstaben die beim Erstellen des Volltextindex leider nicht berücksichtigt werden. Gibt es eine Möglichkeit diese Worte dem Wortstamm hinzuzufügen?

    Beispiel:

    SELECT *

    FROM dbo.Locations

    WHERE CONTAINS(name, ' "au*" ')

    Findet alle Orte die mit "au" beginnen oder "au" enthalten, nicht aber Au selber.

    Zum Einstatz kommt Sql 2008 R2

    Donnerstag, 10. Juli 2014 11:36

Antworten

Alle Antworten

  • Hallo Hanspeter,

    Sieh Dir mal diesen Thread an: Volltextsuche in FileTABLE verbessern

    "Au" fällt bei DE Sprache nun mal unter die Noise words.


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Donnerstag, 10. Juli 2014 11:56
  • Hallo Olaf,

    danke für deine Antwort. Ich hatte bei der Recherche bereits eine andere Antwort zum Thema von dir gelesen. Da geht es ebenfalls über diese Noise Words. Ofensichtlich wird "au" doch nicht als Noise Word geführt, denn wenn ich:

    SELECT * FROM sys.dm_fts_parser('"au*"', 1031, 0, 0)

    ausführe wir es als Exact Match gefunden. In der containstable Abfrage gibt es dann aber doch keine Ergebnisse. Das brachte mich auf die Idee, dass ich "au" aus der Stopliste in den Wortstamm übernehmen können müsste.

    Leider kann ich den Ansatz mit der neutralen Sprache nicht weiter verfogen, da ich dann wieder Probleme mit den Umlauten habe. Oder sehe ich das falsch?

    Donnerstag, 10. Juli 2014 13:08
  • Hallo Hanspeter,

    man sollte sich darüber klar sein, dass es sich um eine "Volltextsuche" handelt, die nach Wörtern sucht - siehe auch die Links in dem Beitrag den Du bereits gelesen hast.

    Intern muss für jeden Wortteil ein Eintrag verwaltet werden. Und nur die diese Worte können überhaupt gefunden werden. Ein "*" erweitert die Suche auf alle Einträge, die mit dem Wortteil beginnen.

    Die Sprache legt den Wortumbrauch fest, was intern auch Trennregeln beeinflusst, wie dafür sorgt das Umlaute expandiert werden (ä => ae, ß => ss etc.), siehe Auswählen einer Sprache beim Erstellen eines Volltextindex

    Darüber im Klaren sein sollte man sich:

    Die Volltextsuche mit Wortfetzen zu füttern ist niemals Sinn der Sache gewesen - "au" liefert bei Google fast eine Milliarde Ergebnisse (vernachlässigt dabei die Sprache) , BING für deutsch 20 Millionen - was zeigen sollte wie ungenau das Ganze wäre.

    In Fällen wie "au*" wäre eine Suche über LIKE 'au%' sinnvoller und wenn  Wortschnipsel nur in einem größeren Dokument zu finden wären, sind Irrläufer vorprogrammiert.

    Gruß Elmar

    Donnerstag, 10. Juli 2014 13:38
    Beantworter
  • SELECT * FROM sys.dm_fts_parser('"au*"', 1031, 0, 0)

    ausführe wir es als Exact Match gefunden.

    Weil Du dem Parser das "Au" zuzüglich dem Sternchen übergeben hast; das wäre der Suchstring, aber nicht das Wort im indizierten Text. Das hier

    SELECT * FROM sys.dm_fts_parser('"au"', 1031, 0, 0)

    liefert Noise Word.


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Donnerstag, 10. Juli 2014 15:00
  • Hallo Elmar,

    ich gehe völlig mit mit deiner Argumentaion was die Volltextsuche betrift. Es ist nicht meine Absicht das Verhalten grundlegend zu verändern. Ich habe bloß ca. 10 Worte bestehend aus nur zwei Buchstaben in meiner Tabelle, die ich gerne als vollwertige Worte behandelt haben möchte. Daher dachte ich, es müsste doch machbar sein, diese Worte der Sprache hinzuzufügen, damit dies auch wie andere Worte indexiert werden.

    Meine Suche funktioniert sonst einwandfrei, nur diese 10 Begriffe machen ärger. Begriffe ab drei Buchstaben länge werden alle korrekt gefunden.

    Die Lösung mit LIKE ist mir bekannt, würde aber bedingen, dass ich die 10 Begriffe anders behandeln muss als den Rest und das gefällt mir nicht.

    In dem erwähnten Artikel steht unten: ... indem die Sprache verwendet wird, die für die einzelnen Spalten angegeben ist, die in der Volltextklausel enthalten sind. Um dieses Verhalten zu überschreiben, geben Sie zur Abfragezeit eine nicht standardmäßige Sprache an.
    es steht nur leider nicht wie man das macht.

    Herzlichen Dank für deine Antwort

    Montag, 14. Juli 2014 09:24
  • Hallo Olaf,

    danke, jetzt verstehe ich!

    Montag, 14. Juli 2014 09:27
  • Hallo Hanspeter,

    zu ... indem die Sprache verwendet wird, die für die einzelnen Spalten angegeben ist, die in der Volltextklausel enthalten sind. Um dieses Verhalten zu überschreiben, geben Sie zur Abfragezeit eine nicht standardmäßige Sprache an.

    es steht nur leider nicht wie man das macht.

    Das steht im Folgesatz: CONTAINS-, CONTAINSTABLE-, FREETEXT- oder FREETEXTTABLE-Abfrage verwenden, um die Sprache anzugeben, die für die Abfrageausdrücke in Bezug auf Wörtertrennung, Wortstammerkennung, Thesaurus und Stoppwörter genutzt wird.

    d. h. über die LANGUAGE Klausel.

    P. S.: Olafs Beitrag präzisiert meine Aussage:

    Ein "*" erweitert die Suche auf alle Einträge, die mit dem Wortteil beginnen.

    Gruß Elmar


    Montag, 14. Juli 2014 12:56
    Beantworter
  • Hallo Elmar,

    jetzt, da ich deine Antwort lese, verstehe ich den von mir falsch zitierten/vertandenen Beitrag. Irreführend war für mich eine nicht standartmäßige Sprache. Was die LANGUAGE Klause ist habe ich vertanden. Meine Volltextabfragen funktinieren alle eiwandfrei, bis auf die erwähnten 10 Worte. Das einzige was ich will, sind diese 10 Worte der Sprache Deutsch hinzufügen. Sogesehen den Deutschen erweiteren, wie in meinem ersten Post geschrieben.

    Herzlichen Dank für eure Antworten.

    Dienstag, 15. Juli 2014 10:01
  • Hallo Hanspeter,

    was Du machen kannst, wäre mit einer eigenen Stoppwortliste zu arbeiten, siehe Konfigurieren und Verwalten von Stoppwörtern und Stopplisten für Volltextsuche

    Am besten erzeugst Du eine neue Stoppliste auf Basis der Systemliste und wirfst dort die Kombinationen raus, die Dir im Moment im Wege stehen (wie "au").

    Falls Du einige Wörter gleich behandelt sehen möchtest, wäre ein (zusätzlicher) Thesaurus eine weitere Option.

    Gruß Elmar

    Dienstag, 15. Juli 2014 11:31
    Beantworter
  • Hallo Elmar,

    dein Vorschlag mit der Stoppliste ist die Lösung. Vielen Dank.

    Eine Frage habe ich noch: bei der Auswahl der Sprache steht nur Deutsch zur verfügung. Mein Projekt verwendet aber die Schweizer Ausprägung von Deutsch, also die mit LCID 2055. Wenn ich nun folgendes mache

    SELECT * FROM sys.dm_fts_parser('"au kanton zürich"', 2055, 0, 0)

    dann gibt es tatsächlich einen exakten treffer mit "au". Wenn ich aber den Volltext mit

    ALTER FULLTEXT INDEX ON [dbo].[locations] ADD ([location_name] LANGUAGE 2055)

    anlege, dann funktioniert die CONTAINSTABLE-Abfrage wiederum nicht, bzw. "au" wird nicht gefunden. Das ist doch eigenartig, dass der Parser es unterstütz, die Volltextsuche dann wieder nicht.

    Unter Konfigurieren der Serverkonfigurationsoption Volltext-Standardsprache steht unten:

    • sys.fulltext_languages (Transact-SQL). Andere Sprachen können beispielsweise von unabhängigen Softwareherstellern verfügbar sein. Wenn keine spezielle Sprache gefunden wird, schaltet das Volltextsuchmodul automatisch in die primäre Sprache.

    da de-ch nicht über die GUI auswählbar ist gehe ich davon aus dass die Sprache nachinstalliert werden muss, bzw. von einem Anbieter erworben werden. Nur leider finde ich keine solchen Anbieter oder ich setzte meine Suche falsch ab. Eventuell ist hier ja jemadem ein solcher Anbieter bekannt. Besten Dank.

    Mittwoch, 16. Juli 2014 08:00
  • Hallo Hanspeter,

    Ich vermute, dass 2055 am Ende auf die neutrale Sprache gemappt wird. Denn wenn ich es mit einer Stoppwortliste vergleiche, so liefert mir:

    -- exact match
    SELECT * FROM sys.dm_fts_parser('"au kanton zürich"', 2055, 0, 0);
    -- noise word bei deutsch Systemstoppliste
    SELECT * FROM sys.dm_fts_parser('"au kanton zürich"', 1031, 0, 0);
    -- exact match bei deutsch Stoppliste (hier 5) ohne "au"
    SELECT * FROM sys.dm_fts_parser('"au kanton zürich"', 1031, 5, 0);

    Insofern dürfte es in Deinem Falle wenig Sinn geben.

    Ich gehe davon aus, dass Deine Dokumente in "deutsch" - d. h. vorrangig hochdeutsch mit geringen Dialekt-Anteilen wie Schwizerdütsch od. schwäbisch, Kölsch, Platt usw. ist.

    Notwendig könnte das höchstens sein, wenn man einen speziellen Wordbreaker für "Schweizerdeutsch" benötigen würde - was außerhalb meiner Kenntnisse von Schweizer Deutsch ist ;)

    Insofern solltest Du mit der deutschen Volltextsprache (1031) in Verbindung mit einer eigenen Stoppliste am besten fahren. Die verwendete Stoppliste kann man bei
    CREATE FULLTEXT INDEX angeben, die Funktion sys.dm_fts_parser kennt es als dritten Parameter (s. o.).

    Was spezielle Wordbreaker angeht kenne ich keine, und für 2055 (Schweiz) ist hier keiner hinterlegt, siehe dazu sp_help_fulltext_system_components.

    Als Filter, die zur Zerlegung von Dokumenttypen verwendet werden, würde ich nur verifizierte Komponenten verwenden, z. B. für Office:

    How to register Microsoft Filter Pack IFilters with SQL Server

    Gruß Elmar

    Als Fußnote: Im Zweifelsfall fällt die Volltextsuche auch mal auf die Systemsprache zurück, siehe http://milambda.blogspot.de/2013/03/sql-server-2012-filetables-text-files.html.


    Mittwoch, 16. Juli 2014 09:53
    Beantworter