¿Hay una buena razón para usar mayúsculas para las palabras clave de SQL? [cerrado]

El valor predeterminado parece estar en mayúsculas, pero ¿hay realmente alguna razón para usar mayúsculas para las palabras clave? Comencé a usar mayúsculas porque solo intentaba hacer coincidir lo que SQL Server me da cada vez que intento crear algo, como un nuevo procedimiento almacenado. Pero luego, me sentí muy mal por mi dedo del bebé (quinto), que siempre necesita mantener presionado el Shiftbotón, así que dejé de usar mayúsculas. ¿Alguna razón por la que debería volver a mayúsculas?

Editar : Gracias por las respuestas chicos. Todavía no estaba programando en los días en que COBOL era el rey, así que no estaba al tanto de esto. Me quedaré con minúsculas de ahora en adelante.

Es solo una cuestión de estilo, probablemente originada en los días en que los editores no hacían la coloración del código.

Solía ​​preferir todas las mayúsculas, pero ahora me estoy inclinando hacia todas las minúsculas.

PERSONALMENTE, NO ME GUSTA MI SQL GRITANDO EN MÍ. Me recuerda BÁSICO O COBOL.

Así que prefiero mi minúscula T-SQL con nombres de objetos de base de datos MixedCase.

Es mucho más fácil de leer y destacan los literales y los comentarios.

SQL ES VIEJO. EL CASO SUPERIOR ESTÁ GRITANDO. Parece extraño y tal vez feo.

Aunque podría decirse que es cierto, ninguno de esos aborda las razones especiales del lenguaje SQL por las cuales las palabras clave en mayúsculas son una buena convención.

A diferencia de muchos lenguajes más nuevos, SQL tiene una gran cantidad de palabras clave y se basa en la capacidad del lector para distinguir las palabras clave de los identificadores para analizar mentalmente la sintaxis.

La respuesta directa a su pregunta, entonces, es más una respuesta a "¿por qué el lector de código SQL se beneficia tanto de las palabras clave mayúsculas, cuando eso no es tan cierto para la mayoría de los lenguajes modernos?":

• Confiar en mantener las palabras clave en la cabeza es razonable para muchos lenguajes modernos, pero no es razonable para SQL ; tiene demasiadas palabras clave y demasiadas variantes.

• Confiar en las señales de puntuación es razonable para la mayoría de los lenguajes modernos, pero no es razonable para SQL ; tiene muy pocos, en cambio depende del orden preciso de las palabras clave para indicar la sintaxis.

• Confiar en los marcadores automáticos para distinguir palabras clave es razonable para los idiomas modernos en los casos habituales, pero ignora la realidad de lo que los marcadores pueden lograr para SQL . La mayoría no cubre todas las palabras clave de todas las variantes de SQL, e independientemente, SQL se lee con frecuencia y de forma rutinaria en contextos en los que un resaltador no ayudará.

Estas son algunas de las razones, específicas de SQL, de que el lector de código SQL se sirve mejor estandarizando en mayúsculas para las palabras clave , y solo usando mayúsculas y minúsculas para identificadores.

Destacar a veces puede ayudar. Pero solo si el resaltador sabe que tienes SQL; y muy a menudo tenemos SQL en un contexto donde el editor / formateador no puede saber razonablemente que se trata de SQL. Los ejemplos incluyen consultas en línea, documentación del programador y cadenas de texto dentro del código de otro idioma. Lo mismo no es cierto con tanta frecuencia para lenguajes como Python o C ++; Sí, su código a veces aparece en esos lugares, pero no se hace de la forma habitual con el código SQL.

Además, el lector comúnmente usará un resaltador que solo conoce un subconjunto de las palabras clave que usa su implementación SQL específica. Muchas de las palabras clave menos comunes no se resaltarán, excepto por una que conozca íntimamente su variante SQL. Entonces, el lector, incluso si está usando un marcador, todavía necesita una forma más directa de distinguir las palabras clave en cualquier declaración SQL moderadamente compleja.

Por lo tanto, el lector con frecuencia, y el escritor no puede saber de antemano cuándo será, necesitará ayuda del contenido de la declaración SQL en sí, para saber qué pretende el escritor como una palabra clave y qué se pretende como un identificador. Por lo tanto, el contenido SQL en sí mismo necesita distinguir las palabras clave para el lector , y el uso de palabras clave en mayúsculas es la forma convencional y útil de hacerlo.

Los ejemplos de Gordon Bell no son exactamente correctos; en general, solo se resaltan las palabras clave, no toda la consulta. Su segundo ejemplo se vería así:

SELECT name, id, xtype, uid, info, status, 
base_schema_ver, replinfo, parent_obj, crdate, 
ftcatid, schema_ver, stats_schema_ver, type, 
userstat, sysstat, indexdel, refdate, version, 
deltrig, instrig, updtrig, seltrig, category, cache
FROM sysobjects
WHERE category = 0
AND xtype IN ('U', 'P', 'FN', 'IF', 'TF')
ORDER BY 1

Esto me parece mucho más fácil de leer, ya que las palabras clave se destacan más. Incluso con el resaltado de sintaxis, encuentro que el ejemplo no capitalizado es mucho más difícil de leer.

En mi empresa, vamos un poco más lejos con nuestro formato SQL.

SELECT      name, id, xtype, uid, info, status, 
            base_schema_ver, replinfo, parent_obj, crdate, 
            ftcatid, schema_ver, stats_schema_ver, type, 
            userstat, sysstat, indexdel, refdate, version, 
            deltrig, instrig, updtrig, seltrig, category, cache
FROM sysobjects
LEFT JOIN systhingies ON
    sysobjects.col1=systhingies.col2
WHERE category = 0
    AND xtype IN ('U', 'P', 'FN', 'IF', 'TF')
ORDER BY 1

Hubo un tiempo en que la mayoría de la gente no tenía la posibilidad de codificar nada más allá de las letras mayúsculas porque la codificación correspondiente (ASCII) NO FUE INVENTADA. SÓLO SEIS BITS DISPONIBLES . MIENTRAS QUE SQL ES MÁS RECIENTE, LAS LETRAS DE CASO INFERIOR NO FUERON PRÁCTICA COMÚN EN LA PROGRAMACIÓN AÚN.

TENGA EN CUENTA QUE ALGUNAS PERSONAS RECLAMAN QUE LA BASE DE DATOS TENDRÁ UN SENTIDO DE URGENCIA Y EJECUTARÁ SUS CONSULTAS MÁS RÁPIDO.

Menos del 10% de las letras en el texto que leemos son mayúsculas. Por lo tanto, nuestros cerebros están más interesados ​​en reconocer las letras minúsculas que las mayúsculas. Los estudios han demostrado que lleva más tiempo leer el texto en mayúsculas. Aquí hay solo un ejemplo:

http://www.guardian.co.uk/media/mind-your-language/2010/oct/04/new-york-street-signs-capitals

Creo que el ejemplo anterior enfatiza que incluso cuando se habla de solo una o dos palabras, hace la diferencia.

¡Es porque SQL es un lenguaje tan antiguo ( 1974 ) que cuando fue concebido, la mayoría de los teclados no tenían letras minúsculas! La documentación del lenguaje simplemente reflejaba la tecnología de la época.

La investigación ha demostrado que ALL CAPS es más difícil de leer, tanto que la Administración Federal de Carreteras de EE. UU. Ha ordenado el uso de letreros con mayúsculas y minúsculas en su Manual sobre dispositivos de control de tráfico uniforme, que establece:

Las letras de los nombres de lugares, calles y autopistas en las señales de guía de carreteras convencionales deben ser una combinación de letras minúsculas con letras mayúsculas iniciales.

The New York Post también publicó:

Los estudios han demostrado que es más difícil leer los signos de mayúsculas, y se ha demostrado que esos milisegundos adicionales gastados mirando lejos de la carretera aumentan la probabilidad de accidentes, especialmente entre los conductores mayores.

No hay buenas razones para usar letras mayúsculas, y buenas razones para no hacerlo.

Yo personalmente odio usar mayúsculas para las palabras clave de SQL. Me resulta más difícil de leer y absurdo en estos tiempos.

El lenguaje SQL se define como insensible a mayúsculas y minúsculas. ¡Quita el dedo de esa tecla de mayúsculas!

Las mayúsculas pueden proporcionar una ganancia en la visibilidad de palabras clave, pero puede compensar con resaltado de código y sangría.
Usamos minúsculas porque el editor de consultas y otras herramientas hacen maravillas al editar el código t-sql, y no vemos la necesidad de torturar el dedo meñique.

Mono, mono, hazlo por mí. Coincidencia de patrones: si lo hago de la forma en que lo he visto, la estructura de las cláusulas se alinea mentalmente más fácilmente.

Las mayúsculas son menos legibles. El bosquejo de todas las palabras tiene forma de cuadros; No hay descendientes ni ascendentes. FTW en minúsculas!

Lo encuentro más legible. Lo mismo para tener una nueva línea para el comienzo de cada cláusula y sangría entre cláusulas.

Pruebe un producto de formateo (uso SQL Prompt / SQL Refactor de Red Gate). Puede configurar cómo desea que funcione la capitalización, y su código siempre tendrá un formato consistente. Descansa el meñique y deja que la computadora haga el trabajo por ti.

Una de las razones para continuar usando mayúsculas es cuando usted (u otra persona) está viendo el código en algo como el bloc de notas, lo que hace que sea más fácil de leer. es decir, puede diferenciar fácilmente entre las "palabras clave" y los nombres de tabla, SP, udf, etc.

Aparte de la conformidad por conformidad de conformidad, no. Aunque es un tema muy subjetivo, prefiero usar mayúsculas y minúsculas para todos los SQL. El SQL es mucho más fácil de leer, y no se pierde nada en los IDE modernos donde las palabras clave están codificadas por colores de todos modos.

Intellisense / autocompletion en Microsoft SQL Server Management Studio permite mayúsculas o minúsculas para palabras reservadas, pero las llamadas en mayúsculas funcionan como MAX (), SUM ().

Aun así, el analizador todavía permite procesar versiones en minúsculas de max () y sum ().

Esto implica una ambivalencia con respecto a la naturaleza de la ejecución y, por lo tanto, es simplemente una cuestión de preferencia personal.

No me gusta nada escrito en mayúsculas (y odio escribir todo en mayúsculas aún más), pero no podía convencerme de ir en contra de la comunidad. Como de costumbre, Vim y sus paquetes asociados son la solución a tantos problemas:

http://www.vim.org/scripts/script.php?script_id=305

Simplemente escriba de forma normal y se capitalizarán automáticamente las palabras clave a medida que escribe. No he usado todos los encantamientos oscuros de SQL, pero todavía no me ha fallado.

Llamo a la mayoría de mi código mySQL desde PHP, y hago toda mi edición de PHP dentro de vim (o supongo que en este caso, VIM ;-). Ahora estoy seguro de que existen complementos para resaltar el código mySQL dentro de PHP, pero no lo he encontrado y no tengo tiempo para buscarlo. Por lo tanto, prefiero tener todo en mayúsculas. Encuentro esto:

if ( !$bla ) 
{
   echo "select something from something where something";
}

if ( !$beepboop ) 
{
   echo "create table if not exists loremIpsum;
}

$query = "
CREATE TABLE IF NOT EXISTS HISTORY
(
   ID INT NOT NULL AUTO_INCREMENT,
   INSERTDATE TIMESTAMP DEFAULT NOW(),
   ALTERDATE TIMESTAMP(8) DEFAULT NOW(),
   DELETEDATE TIMESTAMP(8),
   ALTERCOUNT INT DEFAULT 0,
   SELECTCOUNT INT DEFAULT 0,

   PRIMARY KEY(ID),
)ENGINE=InnoDB
";

mysqlQuery( $query, $con );

Me ayuda a distinguir entre PHP versus SQL mucho mejor que esto:

if ( !$bla ) 
{
   echo "select something from something where something";
}

if ( !$beepboop ) 
{
   echo "create table if not exists loremIpsum;
}

$query = "
create table if not exists history
(
   id int not null auto_increment,
   insertdate timestamp default now(),
   alterdate timestamp(8) default now(),
   deletedate timestamp(8),
   altercount int default 0,
   selectcount int default 0,

   primary key(id),
)engine=InnoDB
";

mysqlQuery( $query, $con );

Además, por alguna razón, odio mezclar allcaps con camel case, así:

CREATE TABLE IF NOT EXISTS history
(
   ID INT NOT NULL AUTO_INCREMENT,
   insertDate TIMESTAMP DEFAULT NOW(),
   alterDate TIMESTAMP(8) DEFAULT NOW(),
   deleteDate TIMESTAMP(8),
   alterCount INT DEFAULT 0,
   selectCount INT DEFAULT 0,

   PRIMARY KEY(ID),
)ENGINE=InnoDB

Eso IDme molesta. ¿Debería ser en su lugar id? o iD?