Estoy leyendo explicaciones contradictorias en las comparaciones de cadenas de Sql a Linq.Linq a Sql distinción insensible a mayúsculas y minúsculas
Cuando hago lo siguiente:
from p in db.People
where p.UserName=username
select p
nombre de usuario = "John"
puedo obtener el resultado correcto mayúsculas y minúsculas. ¿Linq está haciendo esto de manera predeterminada o está sucediendo esto en la base de datos SQL?
Creo que obtiene resultados contradictorios en función de a qué apunta su variable db y dónde se ejecuta realmente la comparación. Si puede, linq creará la consulta y la enviará al servidor SQL. Parece que usted podría forzar sensible a mayúsculas llamando
where p.UserName.ToLower()=username.ToLower()
Lo siento, pero este es un mal consejo. p.UserName.ToLower() = username.ToLower() se traducirá a una consulta SQL que forzará una exploración de tabla completa. Eso no importa si la tabla de "personas" es pequeña, pero si es una tabla grande, entonces no podrá usar ningún índice que pueda cubrir la columna 'nombre de usuario'. – KristoferA
Depende de la base de datos. SQL Server 2008 trata las cadenas como insensibles a mayúsculas y minúsculas, incluso cuando se usan en una expresión de índice. Linq no hace eso.
Lea on MSDN o this article.
La sensibilidad/insensibilidad de mayúsculas/minúsculas depende de la intercalación que utilice en su base de datos y/o las columnas implicadas (el valor predeterminado se establece cuando el servidor sql está instalado, pero puede anularse en varios lugares, hasta el nivel de la columna). – KristoferA
Su consulta de ejemplo se traducirá en algo más o menos así:
seleccione [t0] .col1, [t0] .col2, ..., [ t0] .coln de [esquema]. [la gente] donde [t0] .UserName = @ p0
... el valor de la variable de nombre de usuario se pasarán en la variable SQL @ P0. Como tal, la sensibilidad de mayúsculas y minúsculas, la sensibilidad de acentos, etc., se controla mediante la intercalación que ha configurado para usar la instancia/SQL/tabla/columna de SQL Server. Si no se especifica en ningún otro lugar, se utiliza la intercalación predeterminada de la instancia de base de datos o de base de datos, pero la intercalación se puede especificar hasta el nivel de columna.
La mayoría de las personas ejecuta SQL Server con intercalaciones que no distinguen entre mayúsculas y minúsculas (CI), pero como he dicho anteriormente, se puede anular en la base de datos, así que solo tiene que comprobar qué colación tiene allí.
Esto está en contraste con si haces lo mismo que con una consulta L2O (linq a objetos), en ese caso la distinción entre mayúsculas y minúsculas es la predeterminada y deberías hacer que sea insensible a mayúsculas/minúsculas al usar el string.equals override que le permiten especificar la cultura y/o la insensibilidad del caso ...
no usar una cadena. ¿Ignorar Ignorar tiene el mismo problema que usted comentó con mi resultado? ¿Forzar todos los registros para llegar al lado de linq para hacer la comparación? –
@Jeff, la referencia de string.equals fue solo una comparación entre cómo se comporta L2S y L2O, lo siento si no estaba claro en ese punto. Pero sí, si combinas los dos y haces la evaluación en el lado del cliente como una consulta L2O, no solo obtendría todos los registros sino que también los enviaría por cable. En otras palabras, usar la colación correcta es la clave aquí. El ejemplo de su respuesta todavía se evaluaría en la base de datos, pero con la sobrecarga adicional de un escaneo de tabla debido a la función de envoltorio de llamadas en el lado izquierdo donde predicado cláusula. – KristoferA
Gracias por la respuesta (di +1 cuando hice el comentario anterior) –
¿Echas en falta algunas citas? Cambiar el caso de los nombres de las variables no afecta los resultados. –
no es lo que quise decir ver más arriba – zsharp