Vergleich von Zeichenfolgen ohne Berücksichtigung der Groß- und Kleinschreibung in LINQ-to-SQL

Ich habe gelesen, dass es unklug ist, ToUpper und ToLower zu verwenden, um Zeichenfolgenvergleiche ohne Berücksichtigung der Groß- und Kleinschreibung durchzuführen, aber ich sehe keine Alternative, wenn es um LINQ-to-SQL geht. Die Argumente ignoreCase und CompareOptions von String.Compare werden von LINQ-to-SQL ignoriert (wenn Sie eine Datenbank verwenden, bei der zwischen Groß- und Kleinschreibung unterschieden wird, erhalten Sie einen Vergleich zwischen Groß- und Kleinschreibung, auch wenn Sie nach einem Vergleich ohne Berücksichtigung von Groß- und Kleinschreibung fragen). Ist ToLower oder ToUpper hier die beste Option? Ist einer besser als der andere? Ich dachte, ich hätte irgendwo gelesen, dass ToUpper besser ist, aber ich weiß nicht, ob das hier zutrifft. (Ich mache viele Codeüberprüfungen und jeder verwendet ToLower.)

Dim s = From row In context.Table Where String.Compare(row.Name, "test", StringComparison.InvariantCultureIgnoreCase) = 0

Dies führt zu einer SQL-Abfrage, die row.Name einfach mit "test" vergleicht und in einer Datenbank mit Groß- und Kleinschreibung nicht "Test" und "TEST" zurückgibt.

Wie Sie sagen, gibt es einige wichtige Unterschiede zwischen ToUpper und ToLower, und nur einer ist zuverlässig genau, wenn Sie versuchen, Gleichheitsprüfungen ohne Berücksichtigung der Groß- und Kleinschreibung durchzuführen.

Im Idealfall ist der beste Weg, eine Gleichstellungsprüfung ohne Berücksichtigung der Groß- und Kleinschreibung durchzuführen, folgende :

String.Equals(row.Name, "test", StringComparison.OrdinalIgnoreCase)

HINWEIS, dass dies in diesem Fall jedoch nicht funktioniert ! Deshalb stecken wir mit ToUpperoder fest ToLower.

Beachten Sie den Ordinal IgnoreCase, um die Sicherheit zu gewährleisten. Die genaue Art der (in) sensiblen Prüfung, die Sie verwenden, hängt jedoch von Ihren Zwecken ab. Verwenden Sie im Allgemeinen "Gleich" für Gleichheitsprüfungen und "Vergleichen", wenn Sie sortieren, und wählen Sie dann den richtigen StringComparison für den Job aus.

Michael Kaplan (eine anerkannte Autorität für Kultur und Umgang mit Charakteren wie diese) hat relevante Beiträge zu ToUpper vs. ToLower:

• http://www.siao2.com/2007/10/01/5218976.aspx
• http://www.siao2.com/2005/03/10/391564.aspx

Er sagt "String.ToUpper - Verwenden Sie ToUpper anstelle von ToLower und geben Sie InvariantCulture an, um die OS-Gehäuseregeln zu übernehmen. "

Ich habe System.Data.Linq.SqlClient.SqlMethods.Like(row.Name, "test") in meiner Abfrage verwendet.

Dies führt einen Vergleich ohne Berücksichtigung der Groß- und Kleinschreibung durch.

Ich habe es mit dem Lambda-Ausdruck versucht und es hat funktioniert.

List<MyList>.Any (x => (String.Equals(x.Name, name, StringComparison.OrdinalIgnoreCase)) && (x.Type == qbType) );

Wenn Sie eine Zeichenfolge, bei der die Groß- und Kleinschreibung nicht berücksichtigt wird, an LINQ-to-SQL übergeben, wird diese unverändert an SQL übergeben, und der Vergleich wird in der Datenbank durchgeführt. Wenn Sie Zeichenfolgenvergleiche in der Datenbank ohne Berücksichtigung der Groß- und Kleinschreibung durchführen möchten, müssen Sie lediglich einen Lambda-Ausdruck erstellen, der den Vergleich durchführt, und der LINQ-zu-SQL-Anbieter übersetzt diesen Ausdruck in eine SQL-Abfrage mit intakter Zeichenfolge.

Zum Beispiel diese LINQ-Abfrage:

from user in Users
where user.Email == "foo@bar.com"
select user

wird vom LINQ-to-SQL-Anbieter in das folgende SQL übersetzt:

SELECT [t0].[Email]
FROM [User] AS [t0]
WHERE [t0].[Email] = @p0
-- note that "@p0" is defined as nvarchar(11)
-- and is passed my value of "foo@bar.com"

Wie Sie sehen können, wird der Zeichenfolgenparameter in SQL verglichen, was bedeutet, dass die Dinge genau so funktionieren sollten, wie Sie es erwarten würden.

Um zwischen Groß- und Kleinschreibung unterscheidende Linq-zu-SQL-Abfragen durchzuführen, deklarieren Sie 'String'-Felder als Groß- und Kleinschreibung, indem Sie den Server-Datentyp mithilfe einer der folgenden Optionen angeben.

varchar(4000) COLLATE SQL_Latin1_General_CP1_CS_AS 

oder

nvarchar(Max) COLLATE SQL_Latin1_General_CP1_CS_AS

Hinweis: Das 'CS' in den obigen Sortierungstypen bedeutet 'Groß- und Kleinschreibung beachten'.

Dies kann in das Feld "Serverdatentyp" eingegeben werden, wenn eine Eigenschaft mit Visual Studio DBML Designer angezeigt wird.

Weitere Informationen finden Sie unter http://yourdotnetdesignteam.blogspot.com/2010/06/case-sensitive-linq-to-sql-queries.html

where row.name.StartsWith(q, true, System.Globalization.CultureInfo.CurrentCulture)

Der folgende zweistufige Ansatz funktioniert für mich (VS2010, ASP.NET MVC3, SQL Server 2008, Linq to SQL):

result = entRepos.FindAllEntities()
    .Where(e => e.EntitySearchText.Contains(item));

if (caseSensitive)
{
    result = result
        .Where(e => e.EntitySearchText.IndexOf(item, System.StringComparison.CurrentCulture) >= 0);
}

Manchmal kann der in der Datenbank gespeicherte Wert Leerzeichen enthalten, sodass die Ausführung fehlschlagen kann

String.Equals(row.Name, "test", StringComparison.OrdinalIgnoreCase)

Die Lösung für dieses Problem besteht darin, Leerzeichen zu entfernen, das Gehäuse zu konvertieren und dann wie folgt auszuwählen

 return db.UsersTBs.Where(x => x.title.ToString().ToLower().Replace(" ",string.Empty).Equals(customname.ToLower())).FirstOrDefault();

Beachten Sie in diesem Fall

Benutzerdefinierter Name ist ein Wert, der mit dem Datenbankwert übereinstimmt

UsersTBs ist eine Klasse

Titel ist die Spalte Datenbank

Denken Sie daran, dass es einen Unterschied gibt, ob die Abfrage funktioniert und ob sie effizient funktioniert ! Eine LINQ-Anweisung wird in T-SQL konvertiert, wenn das Ziel der Anweisung SQL Server ist. Sie müssen also über das erzeugte T-SQL nachdenken.

Die Verwendung von String.Equals bringt höchstwahrscheinlich (ich vermute) alle Zeilen von SQL Server zurück und führt dann den Vergleich in .NET durch, da es sich um einen .NET-Ausdruck handelt, der nicht in T-SQL übersetzt werden kann.

Mit anderen Worten, die Verwendung eines Ausdrucks erhöht Ihren Datenzugriff und verhindert, dass Sie Indizes verwenden können. Es funktioniert auf kleinen Tischen und Sie werden den Unterschied nicht bemerken. Auf einem großen Tisch könnte es sehr schlecht abschneiden.

Dies ist eines der Probleme, die bei LINQ bestehen. Menschen denken nicht mehr darüber nach, wie die Aussagen, die sie schreiben, erfüllt werden.

In diesem Fall gibt es keine Möglichkeit, ohne Verwendung eines Ausdrucks das zu tun, was Sie möchten - auch nicht in T-SQL. Daher können Sie dies möglicherweise nicht effizienter durchführen. Selbst die oben angegebene T-SQL-Antwort (unter Verwendung von Variablen mit Sortierung) führt höchstwahrscheinlich dazu, dass Indizes ignoriert werden. Wenn es sich jedoch um eine große Tabelle handelt, lohnt es sich, die Anweisung auszuführen und den Ausführungsplan zu überprüfen, um festzustellen, ob ein Index verwendet wurde .