Confronto tra stringhe senza distinzione tra maiuscole e minuscole in LINQ-to-SQL

Ho letto che non è saggio usare ToUpper e ToLower per eseguire confronti di stringhe senza distinzione tra maiuscole e minuscole, ma non vedo alternative quando si tratta di LINQ-to-SQL. Gli argomenti ignoreCase e CompareOptions di String.Compare vengono ignorati da LINQ-to-SQL (se si utilizza un database con distinzione tra maiuscole e minuscole, si ottiene un confronto con distinzione tra maiuscole e minuscole anche se si richiede un confronto senza distinzione tra maiuscole e minuscole). ToLower o ToUpper è l'opzione migliore qui? Uno è migliore dell'altro? Pensavo di aver letto da qualche parte che ToUpper era migliore, ma non so se questo vale qui. (Sto facendo molte revisioni del codice e tutti usano ToLower.)

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

Questo si traduce in una query SQL che confronta semplicemente row.Name con "test" e non restituirà "Test" e "TEST" su un database sensibile al maiuscolo / minuscolo.

Come dici tu, ci sono alcune differenze importanti tra ToUpper e ToLower, e solo una è affidabile in modo affidabile quando stai provando a fare controlli di uguaglianza insensibili al caso.

Idealmente, il modo migliore per effettuare un controllo di uguaglianza senza distinzione tra maiuscole e minuscole sarebbe :

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

NOTA, TUTTAVIA che in questo caso non funziona ! Pertanto siamo bloccati con ToUppero ToLower.

Si noti l' ordinale IgnoreCase per renderlo di sicurezza di sicurezza. Ma esattamente il tipo di controllo case (in) sensibile che usi dipende da quali sono i tuoi scopi. Ma, in generale, utilizzare Equals per i controlli di uguaglianza e Compare durante l'ordinamento, quindi selezionare StringComparison giusto per il lavoro.

Michael Kaplan (un'autorità riconosciuta in materia di cultura e gestione dei personaggi come questo) ha post pertinenti su ToUpper vs. ToLower:

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

Dice "String.ToUpper - Usa ToUpper anziché ToLower e specifica InvariantCulture per raccogliere le regole di alloggiamento del sistema operativo "

Ho usato System.Data.Linq.SqlClient.SqlMethods.Like(row.Name, "test") nella mia query.

Ciò esegue un confronto senza distinzione tra maiuscole e minuscole.

L'ho provato usando l'espressione Lambda e ha funzionato.

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

Se si passa una stringa senza distinzione tra maiuscole e minuscole in LINQ-to-SQL, questa verrà passata invariata in SQL e il confronto avverrà nel database. Se si desidera eseguire confronti di stringhe senza distinzione tra maiuscole e minuscole nel database, è sufficiente creare un'espressione lambda che faccia il confronto e il provider LINQ-SQL tradurrà quell'espressione in una query SQL con la stringa intatta.

Ad esempio questa query LINQ:

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

viene tradotto nel seguente SQL dal provider LINQ-to-SQL:

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"

Come puoi vedere, il parametro stringa verrà confrontato in SQL, il che significa che le cose dovrebbero funzionare esattamente come ti aspetteresti.

Per eseguire le query da Linq a SQL con distinzione tra maiuscole e minuscole, dichiarare i campi 'stringa' con distinzione tra maiuscole e minuscole specificando il tipo di dati del server utilizzando uno dei seguenti;

varchar(4000) COLLATE SQL_Latin1_General_CP1_CS_AS 

o

nvarchar(Max) COLLATE SQL_Latin1_General_CP1_CS_AS

Nota: "CS" nei tipi di regole di confronto precedenti significa "Case sensitive".

Questo può essere inserito nel campo "Tipo di dati del server" quando si visualizza una proprietà utilizzando Visual Studio DBML Designer.

Per maggiori dettagli consultare http://yourdotnetdesignteam.blogspot.com/2010/06/case-sensitive-linq-to-sql-queries.html

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

Il seguente approccio in 2 fasi funziona per me (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);
}

A volte il valore archiviato nel database può contenere spazi, pertanto l'esecuzione potrebbe non riuscire

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

La soluzione a questi problemi è quella di rimuovere lo spazio, quindi convertire il suo caso e selezionare in questo modo

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

Nota in questo caso

customname è un valore da abbinare al valore del database

UsersTBs è di classe

il titolo è la colonna del database

Ricorda che c'è una differenza tra se la query funziona e se funziona in modo efficiente ! Un'istruzione LINQ viene convertita in T-SQL quando la destinazione dell'istruzione è SQL Server, quindi è necessario pensare al T-SQL che verrebbe prodotto.

L'uso di String.Equals molto probabilmente (suppongo) riporterà tutte le righe da SQL Server e quindi farà il confronto in .NET, poiché è un'espressione .NET che non può essere tradotta in T-SQL.

In altre parole, l'uso di un'espressione aumenterà l'accesso ai dati e rimuoverà la capacità di utilizzare gli indici. Funzionerà su piccoli tavoli e non noterai la differenza. Su un grande tavolo potrebbe funzionare molto male.

Questo è uno dei problemi che esiste con LINQ; la gente non pensa più a come le dichiarazioni che scriveranno saranno soddisfatte.

In questo caso non c'è modo di fare ciò che vuoi senza usare un'espressione, nemmeno in T-SQL. Pertanto potresti non essere in grado di farlo in modo più efficiente. Anche la risposta T-SQL fornita sopra (utilizzando variabili con regole di confronto) molto probabilmente comporterà l'ignoramento degli indici, ma se si tratta di una tabella di grandi dimensioni vale la pena eseguire l'istruzione e guardare il piano di esecuzione per vedere se è stato utilizzato un indice .