Normalización de cadenas con String.ToUpperInvariant()

Actualmente estoy almacenando versiones normalizadas de cadenas en mi base de datos de SQL Server en minúsculas. Por ejemplo, en mi tabla de usuarios, tengo un nombre de usuario y un campo LoweredUserName. Dependiendo del contexto, utilizo la función LOWER() de T-SQL o el método String.ToLower() de C# para generar la versión en minúscula del nombre de usuario para llenar el campo LoweredUserName. De acuerdo con Microsoft's guidelines y Visual Studio's code analysis rule CA1308, debería estar utilizando C# 's String.ToUpperInvariant() en lugar de ToLower(). Según Microsoft, este es un problema tanto de rendimiento como de globalización: la conversión a mayúsculas es segura, mientras que la conversión a minúsculas puede causar una pérdida de información (por ejemplo, the Turkish 'I' problem).Normalización de cadenas con String.ToUpperInvariant()

Si paso al uso de ToUpperInvariant para la normalización de cadenas, también tendré que cambiar el esquema de la base de datos, ya que mi esquema se basa en el marco Microsoft's ASP.NET Membership (ver this related question), que normaliza cadenas a minúsculas.

¿No se contradice Microsoft diciéndonos que usemos la normalización en mayúscula en C#, mientras que su propio código en las tablas y procedimientos de membresía está utilizando la normalización en minúsculas? ¿Debo cambiar todo a la normalización en mayúscula o simplemente continuar usando la normalización en minúsculas?

Fuente

2009-04-21 Kevin Albrecht

Para responder a su primera pregunta, sí Microsoft es un poco inconsistente. Para responder a su segunda pregunta, no cambie nada hasta que haya confirmado que esto está causando un cuello de botella en su aplicación.

Piense en cuánto avance puede hacer en su proyecto en lugar de perder el tiempo cambiando todo. Su tiempo de desarrollo es mucho más valioso que los ahorros que obtendría de dicho cambio.

Recuerde:

optimización prematura es la raíz de todo mal (o al menos la mayor parte de ella) en la programación. - Donald Knuth

Fuente

2009-04-21 17:38:03

Esto no es solo un problema de rendimiento, también es un problema de globalización. Según Microsoft, la conversión a mayúsculas es segura, mientras que la conversión a minúsculas puede causar una pérdida de información (por ejemplo, en el problema turco 'I'). –

@Kevin, el problema turco/azerí sin puntos I sigue siendo un caso especial cualquiera que sea el enfoque utilizado (mayúscula i a İ y yo a I), aunque la minúscula es ambigua para SS (debería ser ss o ß) pero eso también es imperfecto (algunas ortografías todavía mayúsculas ß a SZ). Aún así es mejor. Mejor aún es usar las reglas de plegado de mayúsculas y minúsculas de Unicode con un interruptor de Turkic para i e ı, pero aún así no será perfecto, eso solo puede ser por configuración regional :( –

Según CA1308, la razón para hacer esto es que algunos caracteres no pueden ser convertidos ida y vuelta de mayúsculas a minúsculas. Lo importante es que siempre se mueva en una dirección, por lo que si su estándar es moverse siempre a minúsculas, entonces no hay razón para cambiarlo.

Fuente

2009-04-21 17:44:09 JoshBerke

Me gusta este enfoque. Si se comienza desde cero, siguiendo la recomendación el estándar siempre es la mejor práctica a la luz de ninguna otra motivación para hacer lo contrario, pero cuando se trabaja en mantenimiento existente, a menudo es una locura cambiar porque así lo exige. Necesita evidencia contundente de que su proyecto se beneficiará del cambio antes de embarcarse en tal una revisión, ¿tal vez cuando empiece a procesar turco y encuentre un problema? –

Estoy totalmente de acuerdo, Jeff, hay algunas indicaciones que debe seguir y yo diría que vale la pena actualizar el código existente para seguir (asegúrese de disponer de su lector de datos para ejemplo). Sin embargo, esta no es una de esas reglas ni es una que esté cerca. – JoshBerke

-2

Continuar utilizando la normalización de minúsculas. Solo cambie para cumplir con los estándares de Microsoft si se desarrolla un problema importante.

Esto es desafortunado, pero vale la pena. Lamentablemente, los "estándares" de Microsoft tienden a ser poco considerados y algo menos que consistentes; La experiencia con ellos ha demostrado que, a menos que exista una razón de peso, lo mejor es simplemente seguir con lo que funciona mientras funciona. Tenga en cuenta que esto generalmente NO es cierto para las tecnologías que no son de Microsoft; pero la arbitrariedad de los "estándares" de Microsoft hace que valga la pena evitarlos.

Editar: Debería aclarar aquí; mi opinión de Microsoft es muy baja, de una larga experiencia con sus estándares. Como se señaló en los comentarios, no tengo referencias particulares para señalar "todos los demás que no sean Microsoft"; esto solo viene de mi experiencia personal. Su Kilometraje puede variar ampliamente. Esta respuesta se debe considerar realmente solo mi opinión. Perdón por no haber dejado eso más claro antes.

Fuente

2009-04-21 17:44:14

Creo que debes citar algunas fuentes antes de hacer afirmaciones de "todos menos Mi crosoft "cuando se trata de estándares. En los últimos años, Microsoft parece tener mucho cuidado al investigar las motivaciones detrás de sus estándares y, aunque su implementación de estándares web en IE ha estado lejos de ser ideal, los estándares que definen para que trabajemos dentro de sus productos a menudo son excelentes. Haga una copia de seguridad de sus declaraciones, para que no se interpreten como amargas opiniones. –

Estoy de acuerdo Jeff, sus estándares son muy consistentes con la adopción de sus estándares, pero esto es algo esperado, el código que se escribió antes de que se adoptara un estándar no se actualizará para ponerlo en práctica. Imagínense si hubieran cambiado todo sus espacios de nombre para reflejar su nuevo enfoque para elegir espacios de nombres y todos los desarrolladores que gritarían un sangriento asesinato. – JoshBerke

Tus puntos son buenos; De hecho, mi posición proviene de una opinión bastante amarga y de muchas y malas experiencias con Microsoft. Voy a actualizar para reflejar eso. –

Normalización de cadenas con String.ToUpperInvariant()

Respuesta

Cuestiones relacionadas