¿Hay beneficios para una base de datos sensible a mayúsculas y minúsculas?

Question

Acabamos de 'migrar' una base de datos SQL Server 2005 de DEVEL a TEST. De alguna manera, durante el proceso de migración, el DB cambió de mayúsculas y minúsculas a sensible, por lo que la mayoría de las consultas SQL se rompieron espectacularmente.

Lo que me gustaría saber es: ¿hay algún beneficio claro en tener un esquema sensible a las mayúsculas y minúsculas?

NOTA: Con esto quiero decir nombres de tabla, nombres de columna, nombres de procedimiento almacenado etc. Y no me refiero a los que se almacenan realmente los datos en las tablas.

En la primera inspección, no puedo encontrar una razón válida que ofrezca beneficios sobre la insensibilidad de mayúsculas y minúsculas.

Answer 1

Acabo de descubrir por qué lo hacemos sensible a mayúsculas y minúsculas. Es para garantizar que cuando lo implementemos en el sitio del cliente, nuestro DB funcione sin importar si el SQL Server del cliente está configurado con mayúsculas y minúsculas o no.

Esa es una respuesta que no esperaba.

Answer 2

No todas las secciones de Unicode tienen un biyectiva entre caracteres en mayúsculas y minúsculas - o incluso dos series de casos.

En esas regiones, "insensibilidad a mayúsculas y minúsculas" es un poco sin sentido, y probablemente engañoso.

Eso es todo lo que se me ocurre por ahora; en el conjunto ASCII, a menos que quieras que Foo y Foo sean diferentes, no veo el punto.

Answer 3

La insensibilidad de mayúsculas y minúsculas es un regalo del cielo cuando hay desarrolladores que no siguen ningún tipo de convenciones cuando escriben SQL o provienen de lenguajes de desarrollo donde la insensibilidad de mayúsculas y minúsculas es la norma, como VB.

En términos generales se me hace más fácil tratar con las bases de datos donde no hay posibilidad de que la ID, ID, e Id son campos distintos.

Aparte de una preferencia personal por la tortura, le recomiendo encarecidamente que permanezca insensible a las mayúsculas y minúsculas.

La única base de datos en la que trabajé que se configuró para la distinción entre mayúsculas y minúsculas fue Great Plains. Encontré que tenía que recordar que cada cascarón de sus nombres de esquema era doloroso. No he tenido el privilegio de trabajar con versiones más recientes.

A menos que haya cambiado y si mi memoria no me falla, la naturaleza de mayúsculas y minúsculas que está hablando de se determina en tiempo de instalación y se aplica a todas las bases de datos. Fue el caso de la instalación de SQL Server que ejecutó la base de datos de Great Plains. Mencioné que todas las bases de datos de esa instalación distinguen entre mayúsculas y minúsculas.

Answer 4

Realmente no puedo pensar en ningún buen motivo Los identificadores de SQL deben distinguir entre mayúsculas y minúsculas. Puedo pensar en uno malo uno, es el que da MySQL de por qué sus nombres de tabla son sensibles a mayúsculas y minúsculas. Cada tabla es un archivo en disco, su sistema de archivos distingue entre mayúsculas y minúsculas y los desarrolladores de MySQL se olvidó de table_file = lc(table_name). Esto es muy divertido cuando mueve un esquema MySQL a un sistema de archivos que no distingue entre mayúsculas y minúsculas.

Puedo pensar en una razón importante por la cual no deberían ser sensibles a mayúsculas y minúsculas.

Algún autor de esquema va a ser inteligente y decidirá que this_table significa obviamente algo diferente de This_Table y crea esas dos tablas (o columnas). También podría escribir "insertar errores aquí" en ese punto del esquema.

también, casos y la insensibilidad le permite ser más expresivo en su SQL para enfatizar las tablas y columnas vs comandos sin tener que rendir a lo que el autor esquema decidió hacer.

SELECT this, that FROM Table; 

Answer 5

La mayoría de los idiomas por ahí entre mayúsculas y minúsculas, al igual que la mayoría de los algoritmos de comparación, la mayoría de los sistemas de archivos, etc. insensibilidad caso es para los usuarios perezosos. Aunque tiende a hacer que las cosas sean más fáciles de escribir, y conduce a muchas variantes de los mismos nombres que difieren solo por caso.

En lo personal, entre (MiTabla, mitabla, myTable, MITABLA, Mytable, Mytable, Mytable), me favor gustaría ver una versión universal.

Answer 6

Soporte para Sybase Advantage Database Server y utiliza un formato de archivo plano que permite DBF así como también nuestro propio formato ADT. El caso donde veo que la sensibilidad de mayúsculas y minúsculas es un problema es cuando usamos nuestra versión Linux del servidor. Linux es un SO sensible a las mayúsculas, por lo que tenemos una opción en nuestro db para minúsculas de todas las llamadas. Esto requiere que los archivos de la tabla sean minúsculas.

Answer 7

Me gusta la distinción entre mayúsculas y minúsculas, sobre todo porque eso es a lo que estoy acostumbrado por la programación en Perl (y en la mayoría de los demás idiomas también). Me gusta utilizar StudlyCaps para nombres de tablas y todas las minúsculas con guiones bajos para columnas.

Por supuesto, muchas bases de datos le permiten citar nombres para hacer cumplir la carcasa, como hace Postgres. Eso parece ser un enfoque razonable también.

Answer 8

Estoy bastante seguro de que la especificación SQL requiere plegado de mayúsculas y minúsculas (que es lo mismo que la insensibilidad) para los identificadores. PostgreSQL se pliega hacia abajo, ORACLE se pliega hacia arriba.