sql-server - propio - sql distingue entre mayúsculas y minúsculas
¿Hay beneficios para una base de datos sensible a mayúsculas y minúsculas? (8)
Acabamos de ''migrar'' una base de datos de 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 tablas, nombres de columnas, nombres de procesos almacenados, etc. NO me estoy refiriendo a los datos realmente almacenados en las tablas.
En la primera inspección, no puedo encontrar una razón válida que ofrezca beneficios por sobre la insensibilidad del caso.
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.
Apoyo el servidor de bases de datos Sybase Advantage y utiliza un formato de archivo plano que permite DBF así como nuestro propio formato ADT patentado. 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.
La insensibilidad a las mayúsculas y minúsculas es un regalo del cielo cuando tienes desarrolladores que no siguen ningún tipo de convenciones cuando escriben SQL o provienen de lenguajes de desarrollo donde la insensibilidad a mayúsculas y minúsculas es la norma, como VB.
En términos generales, me resulta más fácil tratar con bases de datos donde no existe la posibilidad de que ID, ID e Id sean campos distintos.
Aparte de una preferencia personal por la tortura, le recomendaría encarecidamente que permanezca insensible a las mayúsculas y minúsculas.
La única base de datos en la que trabajé que se creó para la distinción de casos 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 funciona, la naturaleza de la distinción entre mayúsculas y minúsculas de la que habla está determinada en el momento de la 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.
La mayoría de los idiomas que existen distinguen entre mayúsculas y minúsculas, como la mayoría de los algoritmos de comparación, la mayoría de los sistemas de archivos, etc. La insensibilidad a las mayúsculas y minúsculas es para usuarios vagos. 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.
Personalmente, entre (MyTable, mytable, myTable, MYTABLE, MYTable, myTABLE, MyTaBlE), me gustaría ver una versión universal.
No todas las secciones de Unicode tienen un mapeo biyectivo entre mayúsculas y minúsculas, o incluso dos conjuntos 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 puedo pensar por ahora; en el conjunto ASCII, a menos que quieras que Foo y Foo sean diferentes, no veo el punto.
Realmente no puedo pensar en ninguna buena razón para que los identificadores de SQL sean sensibles a mayúsculas y minúsculas. Puedo pensar en uno malo , es el que da MySQL de por qué sus nombres de tabla son sensibles a las 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 olvidaron 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 gran razón por la cual no deberían ser sensibles a mayúsculas y minúsculas.
Algún autor de esquema será inteligente y decidirá que this_table obviamente significa algo diferente de This_Table y This_Table esas dos tablas (o columnas). También podría escribir " insertar errores aquí " en ese punto del esquema.
Además, la insensibilidad a las mayúsculas y minúsculas le permite ser más expresivo en su SQL para enfatizar las tablas y columnas en comparación con los comandos sin tener que ceñirse a lo que el autor del esquema decidió hacer.
SELECT this, that FROM Table;
Estoy bastante seguro de que la especificación SQL requiere plegado de casos (que es efectivamente lo mismo que la insensibilidad) para los identificadores. PostgreSQL se pliega hacia abajo, ORACLE se pliega hacia arriba.
Me gusta la distinción entre mayúsculas y minúsculas, sobre todo porque eso es a lo que estoy acostumbrado al programar 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 lo hace Postgres. Eso parece ser un enfoque razonable también.