it-swarm.com.de

Ignorieren Sie Akzente in "wo"

In unserer Datenbank haben wir mehrere Einträge mit caron/hatschek. Jetzt möchten unsere Benutzer Einträge einschließlich caron/hatschek finden, wenn sie nach Einträgen ohne suchen. Ich werde dies anhand eines einfachen Beispiels zeigen:

In unserer Datenbank haben wir den Eintrag (Kontakt mit Name)

Millière

dieser Name ist also in dem Land, in dem die Person lebt, korrekt.

In unserem Land haben wir keine Zeichen mit caron/hatschek, daher sucht unser Benutzer nach Milliere. Es werden keine Ergebnisse angezeigt, da è stimmt offensichtlich nicht mit e überein.

Ich habe keine Ahnung, wie dies als é, è, ê und viele weitere sind verfügbar (und dies ist nur ein Beispiel für den Buchstaben e...).

(Der andere Weg wäre viel einfacher, da ich einfach alle Buchstaben durch caron/hatschek durch den einfachen ersetzen könnte. Natürlich möchten unsere Benutzer die richtige Version des Namens in der Datenbank, nicht die verkrüppelte.)

18
lumo

Dieses Problem kann mit akzentunempfindliche Kollatierungen gelöst werden.

Ihre Datenbank verwendet wahrscheinlich eine AS-Kollatierung (Accent Sensitive), sodass standardmäßig nach der genauen Übereinstimmung einschließlich der Akzente gesucht wird.

Sie können die WHERE-Klausel anweisen, eine andere Kollatierung als den Datenbankstandard zu verwenden, indem Sie eine Kollatierung mit dem Vergleich angeben.

In this dbfiddle habe ich ein Beispiel mit den LATIN1-Kollatierungen erstellt, aber Sie können den gleichen Ansatz für die verwendete Kollatierung verwenden, indem Sie einfach AS in AI für die Kollatierung ändern, die Ihre Spalte derzeit verwendet.

Verwenden Sie die akzentunempfindliche Kollatierung, die der von der Spalte verwendeten Kollatierung entspricht. Wenn die Spalte beispielsweise SQL_Latin1_General_CP1_CI_AS Verwendet, verwenden Sie SQL_Latin1_General_CP1_CI_AI Und nicht Latin1_General_CI_AS Oder Latin1_General_100_CI_AS Oder eine der Variationen dieser beiden seit dem Verhalten des Nicht -SQL_-Kollatierungen unterscheiden sich in mehr als nur einer Akzentunempfindlichkeit, und dies wird von Benutzern möglicherweise nicht erwartet.

Sie können die aktuelle Sortierung in sys.columns Überprüfen.

CREATE TABLE testaccent (name nvarchar(50));
GO
INSERT INTO testaccent (name) VALUES ('Millière') , ('Milliere');
GO
-- returns Miliere
SELECT * FROM testaccent WHERE name = 'Milliere';

-- returns both
SELECT * FROM testaccent WHERE name='Milliere' COLLATE Latin1_General_CI_AI

--only returns Miliere
SELECT * FROM testaccent WHERE name='Milliere' COLLATE Latin1_General_CI_AS

Lesen Sie Verwenden von SQL Server-Kollatierungen , um weitere Informationen zu erhalten.

Andererseits möchten Sie wahrscheinlich, dass beim Sortieren diese Sortierung verwendet wird (wie peufe in den Kommentaren angegeben), um sicherzustellen, dass "é" mit "e" sortiert wird. Andernfalls wäre jemand, der die Ergebnisse in alphabetischer Reihenfolge durchblättert, überrascht, das "é" nicht dort zu finden, wo er es erwartet. Wenn Sie jedoch nur diese Abfrage berühren möchten, können Sie die Klausel COLLATE zur ORDER BY Auch.

Wie von Solomon Rutzky in den Kommentaren erwähnt, besteht eine andere Option darin, eine nicht persistierte berechnete Spalte zu erstellen, die einfach die Spalte "Name" wiederholt und den Akzent unempfindlich macht, wenn dies nur 1 oder einige Spalten betrifft Sortierung und indizieren Sie dann die berechnete Spalte. Dies vermeidet den Scan, der durch Ändern der Sortierung innerhalb der Abfrage verursacht wird. Dann muss die Abfrage nach der neuen Spalte filtern.

Etwas wie:

ALTER TABLE 
dbo.[table_name] ADD [SearchName] datatype_of_name_column 
AS ([Name] COLLATE LATIN1_GENERAL_100_CI_AI)); 

CREATE INDEX [IX_table_name_SearchName] 
ON dbo.[table_name] ([SearchName] ASC);

Sie können auch eine Ansicht erstellen, anstatt eine berechnete Spalte hinzuzufügen (wie jyao bevorzugt).