Välj ett språk när du skapar ett fulltextindex

gäller för:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

När du skapar ett fulltextindex, ange ett kolumnnivåspråk för den indexerade kolumnen. Fulltextfrågor i kolumnen använder ordbrytaren och rösterna i det angivna språket. Tänk på hur Full-Text Engine tokeniserar och sedan indexerar din text när du väljer kolumnspråket.

Anmärkning

Om du vill ange ett språk på kolumnnivå för en kolumn med fulltextindex använder du LANGUAGE <language_term> -satsen när du anger kolumnen. Mer information finns i CREATE FULLTEXT INDEX och ALTER FULLTEXT INDEX.

Språkstöd i Full-Text Search

Det här avsnittet innehåller en introduktion till ordbrytare och stemmers och beskriver hur Full-Text Search använder språkkodidentifieraren (LCID) för kolumnnivåspråket.

Introduktion till ordbrytare och stemmers

Databasmotor för SQL Server innehåller ordbrytare och stamningsfunktioner för många språk, som är aktiverade som standard. Microsoft Natural Language Group (NLG) implementerar och stöder dessa språkkomponenter. För en lista över stödda språk, se sys.fulltext_languages.

Externa komponenter som ordbrytare och filter bör signeras för att förbättra säkerheten. För att verifiera signaturen, kör följande kommando:

EXECUTE sp_fulltext_service 'verify_signature';

Så här använder Full-Text Search namnet på språket på kolumnnivå

När du skapar ett fulltextindex, ange ett giltigt språknamn för varje kolumn. Om ett språknamn är giltigt men sys.fulltext_languages katalogvyn inte returnerar det, faller Full-Text Search tillbaka på det närmaste tillgängliga språknamnet i samma språkfamilj, om det finns något. Annars återgår Full-Text Search till den neutrala ordavgränsaren. För att undvika detta reservbeteende, ange ett giltigt och tillgängligt språknamn.

Anmärkning

LCID används mot alla datatyper som är berättigade till fulltextindexering (till exempel tecken eller nchar). Om du har sorteringsordningen för en kolumn av typen char, varchar eller texttyp inställd på en annan språkinställning än det språk som identifieras av LCID, används LCID ändå under fulltextindexering och frågekörning av dessa kolumner.

Ordbrytning

En ordavgränsare delar upp den text som indexeras vid ordgränser, vilka är språkberoende. Därför skiljer sig ordbrytande beteende mellan olika språk. Om du använder ett språk, , xför att indexering av flera språk {x, y, och z}, kan en del av beteendet orsaka oväntade resultat. Till exempel kan ett bindestreck (-) eller ett komma (,) vara ett ordbrytningselement som kastas bort i ett språk men inte i ett annat. Sällan kan oväntat stämmbeteende uppstå eftersom ett givet ord kan ha olika ursprung i olika språk. På engelska är ordgränser till exempel vanligtvis blanksteg eller någon form av skiljetecken. I andra språk, såsom tyska, kan ord eller tecken kombineras. Därför bör det språk på kolumnnivå som du väljer representera det språk som du förväntar dig att lagra i rader i den kolumnen.

Västerländska språk

Om du är osäker på vilka språk som ska lagras i en kolumn för den västerländska språkfamiljen eller om du förväntar dig att fler än ett ska lagras, är en allmän lösning att använda ordbrytaren för det mest komplexa språket som kan lagras i kolumnen.

Du kan till exempel förvänta dig att lagra engelskt, spanskt och tyskt innehåll i en enda kolumn. Dessa tre västerländska språk har liknande ordbrytande mönster, där de tyska mönstren är de mest komplexa. Därför är det i detta fall ett bra val att använda den tyska ordbrytaren, som kan bearbeta engelsk och spansk text korrekt. Däremot kanske den engelska ordbrytaren inte bearbetar tysk text perfekt på grund av tyskans sammansatta ord.

Att använda ordbrytaren för det mest komplexa språket i en språkfamilj garanterar inte perfekt indexering av alla språk i familjen. Det kan förekomma specialfall där den mest avancerade ordbrytaren inte kan hantera text på ett annat språk korrekt.

Icke-västerländska språk

För icke-västerländska språk (såsom kinesiska, japanska, hindi och så vidare) fungerar inte den tidigare lösningen nödvändigtvis, av språkliga skäl. För icke-västerländska språk, överväg en av följande lösningar:

  • För språk från olika familjer

    Om en kolumn kan innehålla dramatiskt olika språk, till exempel spanska och japanska, bör du överväga att lagra innehållet i olika språk i separata kolumner. Denna separation låter dig använda den språkspecifika ordbrytaren för varje kolumn. Om du väljer den här lösningen och inte känner till frågespråket vid frågetillfället kan du behöva utfärda frågan mot båda kolumnerna för att säkerställa att frågan hittar rätt rad eller dokument.

  • För binärt innehåll (såsom Microsoft Word-dokument)

    När det indexerade innehållet är av binär typ kan Full-Text Search-filtret som bearbetar textinnehållet innan det skickas till ordbrytaren hedra specifika språktaggar i den binära filen. I det här fallet genererar filtret vid indexeringstillfället rätt LCID för ett dokument eller ett avsnitt i ett dokument. Full-Text Engine anropar sedan ordbrytaren för språket med det LCID:t. Efter att ha indexerat flerspråkigt innehåll, kontrollera dock att innehållet var korrekt indexerat.

  • För oformaterad text

    När innehållet är oformaterad text kan du konvertera det till xml-datatypen och lägga till språktaggar som anger det språk som motsvarar varje specifikt dokument- eller dokumentavsnitt. För att detta ska fungera måste du dock känna till språket före fulltextindexering.

Härstamning

Ett annat övervägande när du väljer språk på kolumnnivå är stemming. Stamning i fulltextfrågor innebär att man söker efter alla böjningsformer av ett ord i ett visst språk. När du använder en allmän ordbrytare för att bearbeta flera språk fungerar härstamningsprocessen endast för det språk som anges för kolumnen, inte för andra språk i kolumnen. Till exempel fungerar tyska stemmers inte för engelska eller spanska (och så vidare). Detta beteende kan påverka din återkallelse beroende på vilket språk du väljer vid frågetillfället.

Effekt av kolumntyp på Full-Text Search

Ett annat övervägande i språkvalet är relaterat till hur data representeras. För data som inte lagras i en kolumn med varbinary(max) utförs ingen särskild filtrering. I stället skickas texten i allmänhet genom ordbrytningskomponenten as-is.

Dessutom är ordbrytare främst utformade för att bearbeta skriven text. Om din text innehåller markering (som HTML) kan språklig noggrannhet vid indexering och sökning minska. I så fall har du två val: den föredragna metoden är att lagra textdata i en varbinär (max)- kolumn och att ange dess dokumenttyp så att den kan filtreras. Om det inte är ett alternativ, överväg att använda neutral ordbrytare och, om möjligt, lägga till markeringsdata (som 'br' i HTML) i dina brusordslistor.

Anmärkning

Språkbaserad stemming gäller inte när du specificerar det neutrala språket.

Ange ett icke-standard kolumnnivåspråk i en fulltextfråga

Som standard tolkar Full-Text Search i Database Engine frågetermerna genom att använda det språk som anges för varje kolumn i fulltextklausulen. Om du vill åsidosätta det här beteendet anger du ett nondefault-språk vid frågetillfället. För språk som stöds och vars resurser är installerade kan LANGUAGE <language_term> satsen i en CONTAINS-, CONTAINSTABLE-, FREETEXT- eller FREETEXTTABLE-fråga användas för att ange det språk som används för ordbrytning, stamning, tesaurusbearbetning och stoppordsbearbetning av frågans termer.

Relaterat innehåll

  • Uppdaterades senast