2009-12-05 5 views
5

Ich lese widersprüchliche Erklärungen zu Linq zu Sql Zeichenfolge Vergleiche.Linq zu Sql case insensitive Gleichheit

Wenn ich Folgendes tun:

from p in db.People 
    where p.UserName=username 
    select p 

username = "jOHn"

ich die richtige Groß- und Kleinschreibung Ergebnis. Führt Linq das standardmäßig aus oder geschieht dies in der SQL-Datenbank?

+0

Fehlt Ihnen ein paar Zitate? Das Ändern der Groß-/Kleinschreibung der Variablennamen wirkt sich nicht auf die Ergebnisse aus. –

+0

das ist nicht das, was ich meinte, siehe oben – zsharp

Antwort

4

Ich denke, Sie erhalten widersprüchliche Ergebnisse basierend auf was Ihre Datenbank-Variable zeigt und wo der Vergleich tatsächlich ausgeführt wird. Wenn dies möglich ist, erstellt linq die Abfrage und sendet sie an den SQL-Server. Es scheint, wie Sie Groß- und Kleinschreibung von

Aufruf
where p.UserName.ToLower()=username.ToLower() 
+1

Sorry, aber das ist ein schlechter Rat. p.UserName.ToLower() = username.ToLower() übersetzt in eine SQL-Abfrage, die einen vollständigen Tabellenscan erzwingt. Das spielt keine Rolle, wenn die Tabelle "people" klein ist, aber wenn es sich um eine große Tabelle handelt, kann sie keinen Index verwenden, der die Spalte "username" abdecken könnte. – KristoferA

1

Es hängt von der Datenbank ab. SQL Server 2008 behandelt Zeichenfolgen unabhängig von Groß- und Kleinschreibung, auch wenn sie in einem Indexausdruck verwendet werden. Linq macht das nicht.

Lesen Sie on MSDN oder this article.

+2

Groß-/Kleinschreibung hängt davon ab, welche Kollatierung Sie in Ihrer Datenbank und/oder den beteiligten Spalten verwenden (Standard ist gesetzt, wenn SQL Server installiert ist, aber an mehreren Stellen außer Kraft gesetzt werden kann) die Spaltenebene). – KristoferA

3

Ihre Beispielabfrage ungefähr so ​​zu etwas zwingen könnte, wird übersetzen:

select [t0] .col1 [t0] .col2, ..., [ t0] .coln von [Schema]. [People] wo [t0] .UserName = @ p0

... der Wert in den Benutzername Variable wird in dem @ p0 sQL-Variable übergeben werden. Daher wird die Groß-/Kleinschreibung, Akzentempfindlichkeit usw. von der Sortierung gesteuert, die Sie für die Verwendung Ihrer SQL Server-Instanz/db/table/column eingerichtet haben. Falls nicht anders angegeben, wird die Standardsortierung der DBs oder DB-Instanzen verwendet, aber die Sortierung kann bis auf Spaltenebene angegeben werden.

Die meisten Leute führen SQL Server mit case-insensitiven (CI) Kollatierungen, aber wie ich oben gesagt habe, kann es in der DB überschrieben werden, so dass Sie nur überprüfen müssen, welche Kollatierung Sie dort haben.

Dies steht im Gegensatz dazu, wenn Sie dasselbe tun wie eine L2O-Abfrage (linq to objects). In diesem Fall ist die Groß-/Kleinschreibung die Standardeinstellung und Sie müssen die Groß-/Kleinschreibung mithilfe der Zeichenfolge string.equals außer Kraft setzen Damit können Sie Kultur und/oder Groß-/Kleinschreibung angeben ...

+0

würde nicht mit einer string.equals override haben Sie das gleiche Problem, das Sie mit meinem Ergebnis kommentiert? Erzwingen, dass alle Datensätze zur Linq-Seite kommen, um den Vergleich durchzuführen? –

+0

@Jeff, Die string.equals-Referenz war nur ein Vergleich zwischen L2S und L2O, tut mir leid, wenn ich in diesem Punkt nicht klar war. Aber ja, wenn Sie die beiden kombinieren und die Auswertung auf der Client-Seite als L2O-Abfrage durchführen würden, würde es nicht nur alle Datensätze erhalten, sondern diese auch über die Leitung senden. Mit anderen Worten, die richtige Sortierung ist hier der Schlüssel. Das Beispiel aus Ihrer Antwort würde immer noch in der Datenbank ausgewertet werden, aber mit dem zusätzlichen Overhead eines Tabellenscan aufgrund des Funktionsaufruf-Wrappers auf der linken Seite, wo das Klauselprädikat. – KristoferA

+0

Danke für die Antwort (ich gab +1, wenn ich den früheren Kommentar machte) –