Comparação entre cadeias sem distinção entre maiúsculas e minúsculas no LINQ-to-SQL

Li que não é aconselhável usar o ToUpper e o ToLower para realizar comparações de seqüências que não diferenciam maiúsculas de minúsculas, mas não vejo alternativa quando se trata de LINQ-to-SQL. Os argumentos ignoreCase e CompareOptions de String.Compare são ignorados pelo LINQ-to-SQL (se você estiver usando um banco de dados com distinção entre maiúsculas e minúsculas, você obtém uma comparação com distinção entre maiúsculas e minúsculas, mesmo que solicite uma comparação sem distinção entre maiúsculas e minúsculas). ToLower ou ToUpper é a melhor opção aqui? Um é melhor que o outro? Pensei ter lido em algum lugar que o ToUpper era melhor, mas não sei se isso se aplica aqui. (Estou fazendo muitas revisões de código e todo mundo está usando o ToLower.)

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

Isso se traduz em uma consulta SQL que simplesmente compara row.Name com "test" e não retornará "Test" e "TEST" em um banco de dados com distinção entre maiúsculas e minúsculas.

Como você diz, existem algumas diferenças importantes entre o ToUpper e o ToLower, e apenas uma é confiável quando você está tentando fazer verificações de igualdade sem distinção entre maiúsculas e minúsculas.

Idealmente, a melhor maneira de fazer uma verificação de igualdade que não diferencia maiúsculas de minúsculas seria :

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

NOTA, contudo, que isso não funciona neste caso! Portanto, estamos presos a ToUpperou ToLower.

Observe o Ordinal IgnoreCase para torná-lo seguro. Mas exatamente o tipo de verificação sensível a maiúsculas e minúsculas que você usa depende de quais são seus objetivos. Mas, em geral, use Equals para verificações de igualdade e Compare ao classificar e, em seguida, escolha a StringComparison correta para o trabalho.

Michael Kaplan (uma autoridade reconhecida em cultura e manipulação de personagens como essa) tem posts relevantes no ToUpper vs. ToLower:

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

Ele diz "String.ToUpper - use ToUpper em vez de ToLower e especifique InvariantCulture para obter as regras de uso do sistema operacional "

Eu usei System.Data.Linq.SqlClient.SqlMethods.Like(row.Name, "test") na minha consulta.

Isso realiza uma comparação que não diferencia maiúsculas de minúsculas.

Eu tentei isso usando a expressão Lambda, e funcionou.

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

Se você passar uma string que não diferencia maiúsculas de minúsculas para o LINQ-to-SQL, ela será passada para o SQL inalterada e a comparação ocorrerá no banco de dados. Se você deseja fazer comparações de strings sem distinção entre maiúsculas e minúsculas no banco de dados, tudo o que você precisa fazer é criar uma expressão lambda que faça a comparação e o provedor LINQ-to-SQL converterá essa expressão em uma consulta SQL com a string intacta.

Por exemplo, esta consulta LINQ:

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

é traduzido para o seguinte SQL pelo provedor LINQ-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"

Como você pode ver, o parâmetro string será comparado no SQL, o que significa que as coisas devem funcionar da maneira que você espera.

Para executar consultas Linq a Sql com distinção entre maiúsculas e minúsculas, declare que os campos 'string' diferenciam maiúsculas de minúsculas, especificando o tipo de dados do servidor usando um dos seguintes;

varchar(4000) COLLATE SQL_Latin1_General_CP1_CS_AS 

ou

nvarchar(Max) COLLATE SQL_Latin1_General_CP1_CS_AS

Nota: O 'CS' nos tipos de agrupamento acima significa 'Distinção entre maiúsculas e minúsculas'.

Isso pode ser inserido no campo "Tipo de dados do servidor" ao exibir uma propriedade usando o Visual Studio DBML Designer.

Para obter mais detalhes, consulte http://yourdotnetdesignteam.blogspot.com/2010/06/case-sensitive-linq-to-sql-queries.html

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

A seguinte abordagem em duas etapas funciona para mim (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);
}

Às vezes, o valor armazenado no banco de dados pode conter espaços, portanto, a execução pode falhar

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

A solução para esses problemas é remover espaço, converter sua caixa e selecionar assim

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

Observe neste caso

nome personalizado é o valor que corresponde ao valor do banco de dados

UsersTBs é classe

title é a coluna Banco de Dados

Lembre-se de que existe uma diferença entre se a consulta funciona e se funciona com eficiência ! Uma instrução LINQ é convertida em T-SQL quando o destino da instrução é SQL Server, portanto, é necessário pensar no T-SQL que seria produzido.

É provável que o uso de String.Equals (suponho) traga de volta todas as linhas do SQL Server e faça a comparação no .NET, porque é uma expressão do .NET que não pode ser convertida em T-SQL.

Em outras palavras, o uso de uma expressão aumentará seu acesso a dados e removerá sua capacidade de usar índices. Funcionará em pequenas mesas e você não notará a diferença. Em uma mesa grande, poderia ter um desempenho muito ruim.

Esse é um dos problemas que existem com o LINQ; as pessoas não pensam mais em como as declarações que escrevem serão cumpridas.

Nesse caso, não há como fazer o que você deseja sem usar uma expressão - nem mesmo no T-SQL. Portanto, talvez você não consiga fazer isso com mais eficiência. Mesmo a resposta T-SQL fornecida acima (usando variáveis ​​com intercalação) provavelmente resultará em índices sendo ignorados, mas se for uma tabela grande, vale a pena executar a instrução e examinar o plano de execução para verificar se um índice foi usado. .